REFATORAÇÃO DA CAMADA DE APRESENTAÇÃO DO FRAMEWORK DE PREÇO DE VENDA (FRAMEMK)

Transcrição

1 UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ COORDENAÇÃO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS RENATO RAMOS REFATORAÇÃO DA CAMADA DE APRESENTAÇÃO DO FRAMEWORK DE PREÇO DE VENDA (FRAMEMK) TRABALHO DE CONCLUSÃO DE CURSO PONTA GROSSA 2011

2 RENATO RAMOS REFATORAÇÃO DA CAMADA DE APRESENTAÇÃO DO FRAMEWORK DE PREÇO DE VENDA (FRAMEMK) Trabalho de conclusão de curso de graduação, apresentado à disciplina Trabalho de Diplomação, do curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Coordenação de Análise e Desenvolvimento de Sistemas COADS da Universidade Tecnológica Federal do Paraná UTFPR, como requisito parcial para a obtenção do título de Tecnólogo. Orientador: Prof.ª Dr.ª Simone Nasser Matos. PONTA GROSSA 2011

3

4 AGRADECIMENTOS Agradeço primeiramente a Deus pela dádiva de estar vivo e ter saúde, para enfrentar e superar os desafios que aparecerem. A minha Mãe Regina Maria Moreira pelo apoio e dedicação em todos estes anos, e por me ensinar a superar os obstáculos da vida sempre com respeito, honestidade e dignidade. A minha esposa Elaine de Freitas Ramos pelo seu companheirismo, amor e compreensão. Por sempre estar presente nos momentos bons e ruins, me apoiar e incentivar em todos os momentos, provando seu amor em nossa união. A minha orientadora no Trabalho de Conclusão de Curso, Professora Doutora Simone Nasser Matos, pela atenção dada durante todo o desenvolvimento deste trabalho. Por sua dedicação, profissionalismo e disposição de sua parte em todos os momentos que precisei, e pelos conhecimentos ensinados que tornaram este trabalho possível. Agradeço aos professores participantes da Banca, pela sua presença e disposição na avaliação deste trabalho. Agradeço também a todos os professores da UTFPR pelos conhecimentos ensinados, que foram de extrema importância para atingir o objetivo deste trabalho. Agradeço a Universidade Tecnológica Federal do Paraná pelo excelente Curso de Graduação em Análise e Desenvolvimento de Sistemas, pelo qual formam profissionais preparados e com conhecimentos necessários para o mercado de trabalho, sempre valorizando a qualidade e excelência em todos os pontos.

5 RESUMO RAMOS, Renato. Refatoração da Camada de Apresentação do Framework de Preço de Venda (FRAMEMK) f. Trabalho de Conclusão de Curso Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, Universidade Tecnológica Federal do Paraná. Ponta Grossa, O framework de preço de preço de venda que está sendo desenvolvido pelo grupo de pesquisa em Engenharia de Software encontra-se disponível somente em uma plataforma Desktop. Neste tipo de plataforma o usuário terá que realizar várias configurações para conseguir executá-lo. Este trabalho propõe a refatoração da camada de apresentação da aplicação em Desktop. Com a refatoração desta camada para um ambiente Web, o framework será disponibilizado para acesso de qualquer usuário pela Internet. Para o processo de refatoração foram utilizados os frameworks Struts e o Tiles. O Struts permitiu a integração da camada de apresentação com as camadas de regra de negócio e persistência. O Tiles foi usado para melhor divisão dos pontos comuns e específicos na camada de apresentação. Como o aplicativo será hospedado em um servidor Web já preparado para executálo, evita-se que usuário tenha que possuir conhecimentos mais técnicos para instalálo, por exemplo, a instalação do Firebird, da Máquina Virtual Java (JVM), entre outras configurações que surgirem. Palavras-chave: Preço de venda. Framework de domínio. Struts. Tiles.

6 ABSTRACT RAMOS, Renato. View Layer Refactoring of the Sale Price Framework (Framemk) f. TD Systems Analysis And Development Technology, Technological University of Paraná. Ponta Grossa, The sale price framework that is being developed by the research group in Software Engineering is available only in a desktop platform. In this kind of platform the user should apply different settings in order to run the application. This work proposes a refactoring of the view layer of desktop application. With the refactoring to a Web environment, the framework will be available for users from any Internet browser. The refactoring processes that have been used are frameworks named: Struts and Tiles. Struts allowed integrating the view layer with business rule and persistence layers. The Tiles were used to divide of frozen and hot spots in the view layer. Due the application to be web, the user does not need knowledge technical details, for instance: Firebird, the Java Virtual Machine (JVM), among others settings. Keywords: Domain Framework. Sale Price. Struts. Tiles.

7 LISTA DE SIGLAS ABC ASF ASL HTML HTTP GPES JSP Activity-Based Costing Apache Software Foundation Apache Software License HyperText Markup Language HyperText Transfer Protocol Grupo de Pesquisa e Engenharia de Software JavaServer Pages SEBRAE-PR Serviço Brasileiro de Apoio às Micro e Pequenas Empresas - Paraná UTFPR XML Universidade Tecnológica Federal do Paraná Extensible Markup Language

8 LISTA DE FIGURAS Figura 1 Exemplo de arquitetura de uma aplicação Struts Figura 2 Pacotes divididos por camadas Figura 3 Tela de Cadastro de Atributos do Método ABC Figura 4 Tela de Cadastro de Atributos do Método Sebrae Figura 5 Tela de Cadastro de Atributos do Método Custo Pleno Figura 6 Pacote View - Camada de apresentação Figura 7 Menu principal de acesso aos métodos de custeio Figura 8 Tela de acesso aos subframeworks após selecionado o Método ABC Figura 9 Tela de Busca do Método ABC - Subframework Attributes Figura 10 Tela Alimentar Sistema do Método ABC Figura 11 Atualização da Tela Alimentar Sistema do Método ABC Figura 12 Realização do cálculo pelo Método ABC Figura 13 Pacote BusinessRule Camada de Regra de Negócio Figura 14 Pacote Persistence.DAO Camada de Persistência Figura 15 Pacote Persistence.DAO.Firebird Camada de Persistência Figura 16 Processos de refatoração da camada de apresentação do Framemk Figura 17 Página CommonWindowAdd.jsp Figura 18 Estrutura de páginas com elementos comuns Primeira iteração Figura 19 Uso da tag <logic:iterate> na página windowaddfullcost.jsp Figura 20 Página windowaddsebrae.jsp Figura 21 Parte do conteúdo do documento tiles-defs-common.xml Figura 22 Parte do conteúdo do documento tiles-defs-specific.xml Figura 23 Definition.windowAddAbc - Subframeworks Attibutes Figura 24 Parte do documento struts-config.xml Definição dos ActionMappings 45 Figura 25 Parte código-fonte da classe WindowAddAbcAction.java Figura 26 Mapeamento para Cadastro de Atributos Figura 27 Definiton para o Cadastro de Atributos Método ABC Figura 28 Página de layout WindowCommonAdd.jsp Cadastro de Atributos Figura 29 Definitions:.windowAddAbc,.windowAddFullCost e.windowaddsebrae Figura 30 Classe WindowAddFullCostController Figura 31 Página windowaddfullcost.jsp Figura 32 Tela Inicial do Framemk Figura 33 Tela Principal do Método ABC Figura 34 Tela Subframework Calculation Método ABC... 55

9 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS Objetivo Geral Objetivos Específicos PROBLEMA ORGANIZAÇÃO DO TRABALHO FRAMEWORKS MÉTODOS DE IDENTIFICAÇÃO DOS FROZEN E HOT SPOTS CLASSIFICAÇÃO DE FRAMEWORKS QUANTO AO REUSO TIPOS DE FRAMEWORKS STRUTS Visão Geral sobre o Struts Composição Arquitetural do Struts Importância do Uso do Framework Struts Integração do Struts com o Framework Tiles FRAMEWORK DE PREÇO DE VENDA (FRAMEMK) IMPORTÂNCIA DA FORMAÇÃO DO PREÇO DE VENDA CARACTERÍSTICAS DO FRAMEMK ESTRUTURA IMPLEMENTAÇÃO REFATORAÇÃO DA CAMADA DE VISÃO DO FRAMEWORK DE PREÇO DE VENDA PROCESSO PARA REFATORAÇÃO PROCESSO DE REFATORAÇÃO DO FRAMEMK CRIAÇÃO DA CAMADA VIEW BASEADA EM STRUTS Criar as interfaces Web Primeira iteração Segunda iteração Aplicar o Tiles Criar as Actions RESULTADOS PROTÓTIPOS ANALISE QUALITATIVA DO PROCESSO DE REFATORAÇÃO DA CAMADA VIEW CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS... 62

10 10 1 INTRODUÇÃO O Grupo de Pesquisa em Engenharia de Software (GPES, 2011) produziu um aplicativo Desktop no domínio de preço de venda. Os membros do grupo verificaram que este tipo de aplicação dificulta a instalação do programa por usuários leigos, pois estes necessitam conhecer algumas regras técnicas para efetuarem o uso do programa. Entre as regras encontram-se: a necessidade de conhecimento para a instalação e configuração do SGDB Firebird, instalação da Máquina Virtual Java (JVM), além da necessidade do download e instalação do aplicativo em cada computador onde o programa for utilizado. Para resolver o problema da instalação do Framemk, realizou-se o processo de refatoração que permite a transformação do software sem modificar seu comportamento (KERIEVSKY, 2008, p. 35) ou segundo (FOWLER, 2004, p. 52), ou seja, uma alteração feita na estrutura interna do software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado sem alterar seu comportamento observável. O aplicativo desenvolvido foi construído com as características de um framework. Um framework é um conjunto de classes abstratas que interagem entre si, e como resultado de seu uso obtém-se uma aplicação semi-completa reutilizável (JOHNSON, 1997, p ). Esta mesma ideia pode ainda ser aplicada para diversos domínios de problemas. Frameworks de aplicação são utilizados para resolver problemas internos de desenvolvimento, e independem do domínio onde serão endereçados, como exemplo, o Struts (HUSTED et al., 2004). Frameworks de suporte são utilizados para o desenvolvimento de integração com sistemas de baixo nível, como drivers de dispositivos. Por fim, frameworks de domínio são utilizados no desenvolvimento de soluções para um domínio de problema em particular, como exemplos, Framemk (Framework de Formação de Preço de Venda), jogos, engenharia financeira, entre outros. Neste trabalho estudaram-se dois tipos de frameworks, a saber, de aplicação e de domínio. Os frameworks de aplicação estudados foram o Struts e o Tiles, e o de domínio foi o Framemk.

11 11 O processo de refatoração foi realizado por duas etapas principais: análise detalha do Framework de Preço de Venda para Desktop e a geração do sistema para o ambiente Web. Somente na segunda etapa utilizou-se o framework de aplicação Struts para a integração da camada de apresentação com as camadas de regra de negócio e persistência. Na camada de apresentação usou-se o Tiles para melhor separar os pontos comuns e os específicos entre as aplicações-exemplo, a saber, os métodos de formação de preço de venda. Desta forma, criou-se um aplicativo Web em que o usuário necessita apenas saber o endereço eletrônico para usá-lo. 1.1 OBJETIVOS O objetivo geral e os específicos serão descritos nas Subseções e respectivamente Objetivo Geral Refatorar a camada de apresentação do framework de domínio, Framemk, com a utilização de frameworks de aplicação, Struts e Tiles, permitindo com isto sua disponibilização em um ambiente Web Objetivos Específicos Analisar as classes da camada de apresentação do Framemk. Estudar o framework de aplicação Struts. Estudar o framework de apresentação Tiles. Refatorar a camada de apresentação do Framemk com utilização do Struts e o Tiles.

12 PROBLEMA O Framemk é um framework de formação de preço de venda, o qual contempla três diferentes métodos de custeio: Full Cost (Custo Pleno), Activity- Based Costing (Custeio Baseado em Atividade) e SEBRAE-PR. Estes métodos são formados por três subframeworks distintos: Attributes, FoodSystem, e Calculation (CAPELLER; ANDRADE, 2010). O Framemk atualmente roda em uma plataforma Desktop, necessitando assim, que para utilizá-lo seja necessária a execução de bytecodes Java e a instalação local do sistema gerenciador de banco de dados Firebird (CAPELLER; ANDRADE, 2010). Além disto, no sistema operacional onde for executado o Framemk, também é necessário ter uma Máquina Virtual Java (JVM) instalada e configurada corretamente. Tudo isto torna o uso e a distribuição do Framemk mais custosa e menos atrativa por grande parte dos usuários. Devido as dificuldades técnicas de instalação do Framemk, já citadas anteriormente, se o Framemk pudesse ser disponibilizado para utilização através de um ambiente Web, estes problemas seriam resolvidos. Por este motivo, a camada de apresentação do Framemk deverá ser refatorada, possibilitando ao final do processo empregado, sua utilização através de um ambiente Web. Com isso, um maior número de pessoas poderá utilizá-lo. A arquitetura de software do Framemk é formada por diversos padrões de projetos, entre os principais tem-se, o DAO Factory, Decorator e Model-View- Controller (MVC). A utilização destes padrões auxilia o desenvolvimento ágil e na reutilização de software, além de outras características da engenharia de software. Com a utilização do padrão MVC as responsabilidades são devidamente separas em camadas: apresentação, regra de negócio e persistência. Este trabalho tenta responder à seguinte pergunta: É possível realizar a refatoração da camada de apresentação de uma aplicação baseada em camadas e em uma plataforma Desktop para uma plataforma Web sem alterar as camadas de regras de negócio e persistência?

13 ORGANIZAÇÃO DO TRABALHO Este trabalho está divido em seis capítulos. O capítulo 2 apresenta o que são frameworks e sobre os métodos de identificação dos pontos comuns e específicos dos frameworks, da sua classificação quanto ao reuso e classificação quanto aos tipos de frameworks. Por fim, são citados e comentados alguns detalhes importantes sobre os frameworks Struts e Tiles e a importância deles neste trabalho. O capítulo 3 descreve brevemente sobre a formação de preço de venda e sua importância no mercado atual, bem como, uma apresentação geral do Framemk. O capítulo 4 relata sobre o processo de refatoração com a utilização dos frameworks Struts e Tiles para refatoração da camada de apresentação do Framemk. O capítulo 5 mostra os protótipos obtidos após o processo de refatoração da camada de apresentação do Framemk e realiza uma análise qualitativa sobre este processo. E, por fim, o capítulo 6 apresenta as conclusões do trabalho e sugestões para trabalhos futuros.

14 14 2 FRAMEWORKS Esse capítulo tem como objetivo descrever uma apresentação geral sobre frameworks. A Seção 2.1 apresenta os métodos de identificação dos comuns e específicos. A Seção 2.2 descreve a classificação de frameworks quanto ao reuso. A Seção 2.3 relata os tipos de frameworks existentes. A Seção 2.4 narra sobre o framework de aplicação Struts. A Subseção descreve um breve histórico do Struts, bem como, sobre sua evolução arquitetural. A Subseção descreve como é uma arquitetura de uma aplicação construída com o Struts. A Subseção descreve sobre a importância do Struts para este Trabalho. Por fim, a Subseção narra sobre a integração entre o Struts e o Tiles. 2.1 MÉTODOS DE IDENTIFICAÇÃO DOS FROZEN E HOT SPOTS Um framework é um conjunto de subsistemas, subframeworks e componentes interagindo e colaborando de forma a produzir um projeto geral para um domínio particular (MATOS, 2008). Um subsistema é um conjunto de classes interagindo e colaborando para executar uma função. Um subframework representa uma parte reutilizável de um subsistema ou um conjunto deles que pode ser reusada em uma nova aplicação-exemplo. Um componente é o resultado da transformação de um subframework ou de um subsistema que irá executar uma função bem definida em um projeto executável, permitindo ao desenvolvedor alterar somente o que for flexível. A parte central do projeto de frameworks de domínio está em determinar quais pontos devem ser classificados como comuns (frozen spots) ou específicos (hot spots) (PREE, 1995). Os frozen spots representam as partes estáveis ou comuns, que não se alteram de uma aplicação-exemplo para outra em um determinado domínio. Já os hots spots se referem às partes flexíveis ou específicas, as quais podem sofrer alterações de uma aplicação-exemplo para outra em um determinado domínio (MATOS, 2008). Identificar estes pontos exige certo trabalho e em muitas vezes o processo é bastante complexo. Na literatura existem diversos estudos para obtenção dos pontos

15 15 comuns e específicos. Dentre estes têm-se as abordagens de: Pree (1999), Schmid (1999), Froehlich et al. (1997, 1999), Roberts e Johnson (1998), Bosh et al. (1999) e a de Matos (MATOS, 2008). As abordagens de Pree (1999), Schmid (1999), Roberts e Johnson (1998, 1998) iniciam a construção do framework através de modelos de aplicações particulares e posteriormente incluem os pontos de flexibilidade. Froehlich (1997, 1999) descreve que a separação dos pontos flexíveis é parte resultante do conhecimento e experiência do desenvolvedor sobre o domínio do estudo abordado. Bosh et al. (1999) direciona a separação dos pontos flexíveis no início do projeto de construção do framework, onde é realizada uma análise e só então é dado continuidade ao projeto. Matos (2008) refere-se a separação dos pontos de estabilidade e flexibilidade, através do conjunto de responsabilidades, obtidos nos casos de uso de cada aplicação-exemplo. Este processo serve como base para a separação antecipada dos pontos de flexibilidade e estabilidade das classes. Com isto é possível um ganho de tempo no processo de desenvolvimento de frameworks de domínio. 2.2 CLASSIFICAÇÃO DE FRAMEWORKS QUANTO AO REUSO Os frameworks são classificados quanto ao reuso em três diferentes tipos: caixa-branca, caixa-preta e caixa-cinza (YASSIN; FAYAD, 2000). No framework de caixa-branca o reuso acontece por meio do mecanismo da herança e implementação de métodos. Subclasses são criadas através de classes abstratas pertencentes ao framework. Através destas subclasses são criadas as aplicações específicas. Neste tipo de reuso é necessário saber como o framework é formado e como ele funciona internamente para poder utilizar o mecanismo de herança da orientação à objetos, estendendo as classes abstratas nas classes da aplicação específica. Em um framework de caixa-preta o reuso acontece por meio da composição, ou seja, as diversas classes concretas são combinadas para se obter a aplicação

16 16 específica desejada, não sendo necessário conhecer a implementação interna das classes que serão utilizadas na composição das novas responsabilidades. Por fim, o framework de caixa-cinza é considerado um híbrido entre o caixabranca e caixa-preta. Sua utilização pode ser feita pelo mecanismo da herança ou pela composição, isto o torna um produto melhorado e de mais fácil utilização. 2.3 TIPOS DE FRAMEWORKS Entre os tipos de frameworks encontrados tem-se: Frameworks de aplicação, de suporte e de domínio (TALIGENT, 1994). Framework de aplicação ou vertical encapsulam conhecimentos para basicamente resolver problemas internos no desenvolvimento de software (CARNEIRO, 2003), por exemplo, o Struts (HUSTED et al., 2004). Framework de suporte provê serviços no nível de sistema operacional, tais como: a disponibilização de acesso e controle de arquivos. Framework de domínio ou horizontal encapsulam conhecimentos aplicáveis a um domínio particular de problema, como aplicações desenvolvidas para usuários (CARNEIRO, 2003). Alguns exemplos de frameworks de aplicações são: controle de otimização de vendas e controle de custos e telecomunicações. Ressalta-se que neste trabalho o framework de aplicação, Struts, será utilizado com o objetivo de facilitar a implementação da camada da apresentação de um framework de domínio, a saber, o Framemk (Framework de Formação de Preço de Venda) que está sendo desenvolvido pelo Grupo de Pesquisa em Engenharia de Software (GPES) da Universidade Tecnológica Federal do Paraná - Campus Ponta Grossa (GPES, 2011). A seguir detalha-se o funcionamento do framework Struts e no Capítulo 3 descreve-se a arquitetura do framework de domínio Framemk. 2.4 STRUTS O Struts é um framework de aplicação e atualmente é um dos mais utilizados para o desenvolvimento Web (HUSTED et al., 2004, p. 5).

17 17 A base de código inicial do Struts foi desenvolvida em 2001, pelo arquiteto de software Craig McClanahan. Este framework atualmente é mantido pela Apache Software Foundation (ASF) como parte do projeto Jakarta, e conta com milhares de colaboradores e desenvolvedores (HUSTED et al., 2004, p. 4-5). Ele reúne diversas tecnologias Java, todas incorporadas ao framework, podendo estas serem utilizadas na sua totalidade ou parcialidade. Entre as tecnologias citadas tem-se: JavaServer Pages (JSP), JavaBeans, servlets Java, além de templates que podem ser utilizados para auxiliar na apresentação dos resultados passados para camada de apresentação da aplicação, como exemplo, o Tiles que será relatado na Seção O Struts...encoraja as arquiteturas das aplicação baseadas na abordagem Modelo2, uma variação do clássico paradigma de projeto Model-View-Controller (MVC) (HUSTED et al., 2004, p. 38). Como demais vantagens têm-se que o framework Struts está disponível para o público sem taxas. Os projetos criados com o Struts podem ser distribuídos livremente sem nenhuma burocracia e não há restrições quantas alterações ou inclusões da arquitetura do framework (APACHE SOFTWARE FOUNDATION, 2010) Visão Geral sobre o Struts Após o lançamento das especificações do JavaServer Pages (versões 0.91 e 0.92), os desenvolvedores tinham dois estilos de construções básicas para as aplicações criadas em JSP. O primeiro estilo foi conhecido como Modelo 1, que se caracterizava pelo envio de formulários que voltavam para o servlet ou página JSP (HUSTED et al., 2004, p. 40). A construção do formulário e a validação quase sempre eram realizadas juntas, misturando assim a apresentação com a regra de negócio e a validação. Este modelo foi utilizado por programadores com pouca experiência, e em caso de projetos pequenos, os quais os esforços para se separar as responsabilidade era dispensável. O segundo estilo conhecido é o Modelo 2, que funciona da seguinte maneira: o formulário é enviado para um controlador, este o repassava para um componente

18 18 específico para tratar com a regra de negócio, por exemplo, validações de CPF, então este componente interage com o banco de dados, caso necessário. Em seguida, ocorre o retorno da seguinte forma: o resultado da consulta ao banco de dados é devolvido para o controlador, que delega a criação da página de resposta para um componente de apresentação, o qual cria à resposta a solicitação do usuário, efetuada através do formulário (HUSTED et al., 2004, p ). O termo Modelo 2 desapareceu nas últimas versões da especificação JSP, e seu uso é mais comum entre os desenvolvedores Java, sendo atualmente mais conhecido pelos demais como o modelo Model-View-Controller (MVC) (HUSTED et al., 2004, p. 13) Composição Arquitetural do Struts Da mesma maneira como são construídos os prédios e casas, através de bases sólidas que separam as partes uma das outras, os desenvolvedores do Struts também criaram uma arquitetura parecida. O Struts é formado por um controlador central que interliga as camadas de apresentação e de regra de negócio. Ele funciona como um roteador entre as camadas citadas, fazendo com que todas as requisições sejam enviadas e devolvidas de forma correta, e que seja possível também desviar o controle quando necessário para um recurso diferente, como exemplo, página de tratamento de exceções (HUSTED et al., 2004, p. 28,55). A Figura 1 ilustra um exemplo de arquitetura de uma aplicação Struts. Figura 1 Exemplo de arquitetura de uma aplicação Struts Fonte: HUSTED et al. (2004, p. 15).

19 Importância do Uso do Framework Struts O Struts é um framework de aplicação e auxilia os desenvolvedores a criarem soluções Web, com o objetivo de resolver questões internas no desenvolvimento de aplicativos para um determinado domínio. Como os frameworks encapsulam e separam os pontos comuns dos pontos específicos, o desenvolvedor se preocupa apenas com a parte específica da sua aplicação. Outro ponto importante é que se podem aproveitar todos os recursos, padrões de projetos e outros componentes especializados disponibilizados pelo framework, que auxiliam no desenvolvimento de forma mais ágil e permitem o reuso de software. O Struts, neste trabalho, será usado para a refatoração do framework de domínio, o Framemk (GPES, 2011). Esta utilização permitirá que os esforços sejam concentrados na solução do problema de refatoração da camada de apresentação do Framemk, deixando para o Struts o trabalho de utilização de padrões de projetos necessários na codificação e divisão em camadas do projeto Web Integração do Struts com o Framework Tiles O Tiles é considerado um framework de apresentação, formado pela ideia de utilização de templates. Pode ser utilizado para a reusabilidade de componentes que formam a camada de apresentação de um projeto. Sua tecnologia é independente da utilização com o framework Struts, porém para que isto seja possível deve-se utilizar o Tiles versão 2.0 ou superior (APACHE TILES - HOME, 2011). O Tiles integra-se facilmente ao framework Struts, e seu aprendizado é fácil, por este motivo será utilizado neste projeto. Juntos o Struts e o Tiles formam uma combinação poderosa para desenvolver projetos Web (HUSTED et al., 2004, p. 312). Através do recurso disponibilizado pelo Tiles, os Definitions (Definições), é possível definir grande parte da estrutura de apresentação em um documento XML, permitindo assim maior facilidade de manutenção e até mesmo o uso de mecanismo de herança, utilizado em linguagens orientadas a objetos (HUSTED et al., 2004, p. 317, , 341).

20 20 3 FRAMEWORK DE PREÇO DE VENDA (FRAMEMK) Esse capítulo tem como objetivo descrever uma apresentação geral sobre o Framework de Formação de Preço de Venda, a saber, Framemk. A Seção 3.1 apresenta a importância da definição de preço de venda no mercado competitivo atual. A Seção 3.2 descreve as principais características do Framemk. A Seção 3.3 relata como está estruturado o Framemk. Por fim, a Seção 3.4, explica como o Framemk foi implementado na arquitetura Desktop, dando ênfase à camada de apresentação, foco deste trabalho. 3.1 IMPORTÂNCIA DA FORMAÇÃO DO PREÇO DE VENDA No mercado competitivo as empresas enfrentam diversos problemas, sendo a formação do preço de vendas um dos principais. Vários métodos foram desenvolvidos para solucionar este problema, em que cada um possui suas próprias características. A princípio os administradores utilizavam cálculos manuais, o que demandava tempo. Atualmente existem diversos softwares capazes de calcular preços de venda, porém geralmente são programas proprietários e implementam poucos métodos (CAPELLER; ANDRADE, 2010, p. 20). Conforme Bornia (2002) preço de venda é o valor atribuído a um produto ou serviço, cujo valor deve ser suficiente para cobrir todas as despesas (fixas e variáveis) e o custo que do que está sendo vendido, gerando ainda assim, uma margem de lucro para investimentos posteriores. Para o sucesso de uma empresa ser alcançado, é preciso que ela estabeleça os preços de seus produtos e serviços. O preço estabelecido deve ser suficiente para cobrir todas as despesas fixas e variáveis, somando aos seus custos diretos e indiretos, e acrescidos do lucro a ser atingido, levando em consideração o preço praticado pela concorrência (BORNIA, 2002).

21 CARACTERÍSTICAS DO FRAMEMK O Framemk (Framework de Formação de Preço de Venda) é um framework de domínio que contempla três diferentes métodos de cálculo de formação de preço de venda: Activity Based Costing (Custeio Baseado em Atividades), SEBRAE-PR e Full Cost (Custo Pleno) (CAPELLER; ANDRADE, 2010, p. 19, 95, 125). Consideramse os métodos de preço de vendas citados anteriormente, como aplicações-exemplo do domínio de formação de preço de venda. O Framemk é composto por um conjunto de subframeworks que une as características comuns dos três métodos de preço de venda citados e deixa a parte específica de cada método para implementação pelo desenvolvedor, sendo classificado quanto ao reuso como de caixa-branca e quanto ao tipo considera-se como um framework de domínio. Os pontos comuns ou estabilidade e os específicos ou de flexibilidade do Framemk foram separados após análise das aplicações-exemplo, ou seja, os métodos de preço de venda. Cada método possui características próprias, o que necessitou análise antes da construção de seu modelo arquitetural (CAPELLER; ANDRADE, 2010, p. 19). 3.3 ESTRUTURA Atualmente o Framemk possui três subframeworks desenvolvidos, os quais contemplam os três métodos citados anteriormente, são eles: Attributes, FoodSystem e Calculation (CAPELLER; ANDRADE, 2010, p. 19, 95, 125). Todos os subframeworks foram desenvolvidos em plataforma Desktop, através da linguagem Java. Para utilizar o Framemk é necessário baixar o aplicativo e seguir as instruções de instalação disponíveis no sítio do GPES (GPES, 2011). O Framemk necessita também do gerenciador de banco de dados Firebird para que possa ser executado corretamente. A arquitetura de software do Framemk está dividida em camadas e utiliza diversos padrões de projetos e meta padrões (CAPELLER; ANDRADE, 2010, p ).

22 22 A divisão em camadas proporciona a separação da lógica de negócio da lógica de apresentação, facilitando assim os testes e manutenções de forma isolada. Para a camada de persistência foi utilizado o padrão de projeto DAOFactory, permitindo a redução e centralização das classes de persistência. Já para o desenvolvimento da camada de apresentação foi utilizado o padrão de projeto Decorator descrito em Capeller e Andrade (2010, p. 60). A Figura 2 mostra uma apresentação geral dos pacotes referentes a divisão do sistema em camadas. Figura 2 Pacotes divididos por camadas Fonte: Capeller e Andrade (2010, p. 61). Conforme mostra a Figura 2, os pacotes por camada são: Camada de regra de negócio: Pacote BusinessRule - possui as regras de negócio utilizadas pelos métodos de custeio. Camada de persistência: Pacotes Persistence.DAO e Persistence.DAO.Firebird - possuem as classes que trabalham com a persistência dos dados utilizados. Camada de apresentação: Pacote View - possui classes que realizam a interação do usuário com o sistema. O pacote VO possui os objetos de valores, que são transportados entre as camadas citadas anteriormente.

23 IMPLEMENTAÇÃO Como grande parte das telas possuem características comuns para cada um dos subframeworks, utilizou-se o padrão de projetos Decorator no desenvolvimento da camada de apresentação do Framemk (CAPELLER; ANDRADE, 2010, p. 60). O padrão de projeto Decorator possibilita que partes flexíveis sejam incluídas em tempo de execução, para um determinado objeto, permitindo assim mais flexibilidade na utilização da herança para reutilização das partes estáveis de cada funcionalidade (SILVA, 2010). Como exemplo, pode-se citar a tela de cadastro do subframework Attributes, onde o campo Nome é comum para qualquer um dos métodos selecionados. O mesmo ocorre para os botões Salvar e Fechar. Os campos específicos são criados dinamicamente com a utilização do padrão de projeto Decorator (CAPELLER; ANDRADE, 2010, p. 60). As Figuras 3, 4 e 5 mostram o padrão de projeto Decorator aplicado na prática, e também exibem os elementos específicos criados em tempo de execução para cada um dos métodos de custeio. Estes exemplos foram capturados da execução do cadastro de atributos dos métodos: ABC, SEBRAE-PR e Custo Pleno. Figura 3 Tela de Cadastro de Atributos do Método ABC Fonte: Capeller e Andrade (2010, p. 98).

24 24 Figura 4 Tela de Cadastro de Atributos do Método Sebrae Fonte: Capeller e Andrade (2010, p. 98). Figura 5 Tela de Cadastro de Atributos do Método Custo Pleno Fonte: Capeller e Andrade (2010, p. 99). As demais telas do Framemk também utilizam o padrão de projeto Decorator para adição de novas responsabilidades em tempo de execução, por isso não serão explicadas em mais detalhes. A Figura 6 mostra o pacote View com parte das classes pelo qual é composto. As classes que contém os elementos comuns são nomeadas com a palavra CommonWindow prefixada da funcionalidade ou subframework a qual

25 25 estes elementos comuns pertencem, por exemplo, CommonWindowFoodSystem.java. Esta classe é utilizada na construção dos elementos comuns para o subframework FoodSystem. Já os elementos específicos foram colocados nas classes nomeadas palavra Window prefixada do subframework mais o método de custeio no qual irão adicionar as especialidades, por exemplo, WindowCalculateAbc.java. Esta classe possui os elementos específicos para o subframework Calculation utilizado pelo Método ABC. WindowFind e WindowAdd são interfaces necessárias aos objetos que são criados dinamicamente. Outras classes como a DecoratorAdd, mantém referência para o objeto WindowAdd (CAPELLER; ANDRADE, 2010, p. 61). Figura 6 Pacote View - Camada de apresentação Fonte: Capeller e Andrade (2010).

26 26 A Figura 7 ilustra a interface gráfica do menu principal do sistema, em que o usuário poderá selecionar qual o método de custeio deseja utilizar. Figura 7 Menu principal de acesso aos métodos de custeio Fonte: Capeller e Andrade (2010). A Figura 8 exibe um exemplo de acesso aos subframeworks para o Método ABC. Entres os subframeworks exibidos tem-se: Attributes (Atributo), FoodSystem (Alimentar Sistema), Production Line (Linha de Produção), Product (Produto) e Activity (Atividade). O subframework Calculation (Calculo) é acessado através do subframework FoodSystem. Dos subframeworks citados anteriormente apenas o Attributes, FoodSystem e Calculation foram implementados (CAPELLER; ANDRADE, 2010, p. 19, 95, 125). Figura 8 Tela de acesso aos subframeworks após selecionado o Método ABC Fonte: Capeller e Andrade (2010). A Figura 9 mostra a tela de busca dos atributos cadastrados para o Método ABC. Nela além realizar a busca de atributos o usuário pode também cadastrar, editar ou desativar um atributo.

27 27 Figura 9 Tela de Busca do Método ABC - Subframework Attributes Fonte: Capeller e Andrade (2010, p. 96). A Figura 10 mostra a tela Alimentar Sistema para o Método ABC. É necessário selecionar uma linha de produção para que a tabela de produtos seja atualizada. Em seguida o usuário poderá atualizar os valores dos produtos listados. Estes valores serão utilizados no cálculo, se selecionado a opção Calcular. Figura 10 Tela Alimentar Sistema do Método ABC Fonte: Capeller e Andrade (2010, p. 101).

28 28 A Figura 11 mostra a tela Alimentar Sistema para o mesmo método, depois de selecionado uma linha de produção (CAPELLER; ANDRADE, 2010, p ). Pressionando-se o botão Calcular, conforme mostrado na Figura 11, a tela da Figura 12 será exibida. Figura 11 Atualização da Tela Alimentar Sistema do Método ABC Fonte: Capeller e Andrade (2010, p. 102). A tela da Figura 12 pertence ao subframework Calculation, ela exibe um cálculo efetuado com o Método ABC. Para que o cálculo seja efetuado, deve-se primeiramente informar a linha de produção. Em seguida, devem-se informar os números produzidos, para os produtos listados. Por fim, pressiona-se o botão Calcular (CAPELLER; ANDRADE, 2010, p ). Figura 12 Realização do cálculo pelo Método ABC Fonte: Capeller e Andrade (2010, p. 107).

29 29 Para os demais métodos de custeio, Método SEBRAE-PR e Método Baseado no Custo Pleno, as telas seguem o mesmo padrão de visualização, sendo que apenas são adicionados os pontos flexíveis para cada um dos subframeworks do método de custeio selecionado. A Figura 13 mostra o pacote BusinessRule, que contém as classes da camada de regra de negócio, e as Figuras 14 e 15 mostram os pacotes Persistence.DAO e Persistence.DAO.Firebird, que contém as classes da camada de persistência. Figura 13 Pacote BusinessRule Camada de Regra de Negócio Fonte: Capeller e Andrade (2010). Figura 14 Pacote Persistence.DAO Camada de Persistência Fonte: Capeller e Andrade (2010).

30 30 Figura 15 Pacote Persistence.DAO.Firebird Camada de Persistência Fonte: Capeller e Andrade (2010). A implementação da camada de negócio e de persistência não serão explicada em detalhes, pois o objetivo principal deste trabalho é a refatoração da camada de apresentação. Para mais detalhes sobre a implementação destas camadas deverá ser consultado o trabalho de Capeller e Andrade (2010).

31 31 4 REFATORAÇÃO DA CAMADA DE VISÃO DO FRAMEWORK DE PREÇO DE VENDA Esse capítulo tem como objetivo descrever como foi efetuado a refatoração da camada de apresentação do Framemk. A Seção 4.1 apresenta os processos envolvidos para a realização da refatoração de um projeto e de um modo geral descreve brevemente sobre ferramentas de refatoração, e por fim, o processo utilizado na refatoração da camada de apresentação do Framemk. A Seção 4.2 detalha as atividades necessárias para a refatoração da camada de apresentação do Framemk, atingindo o objetivo principal deste trabalho. 4.1 PROCESSO PARA REFATORAÇÃO Refatoração de software é a transformação do software sem modificar seu comportamento (KERIEVSKY, 2008, p. 35) ou segundo Fowler (2004, p. 52) uma alteração feita na estrutura interna do software para torná-lo mais fácil de ser entendido e menos custoso de ser modificado sem alterar seu comportamento observável. Muitas são as razões da necessidade de se refatorar um código, entre elas: tornar mais fácil a adição de código novo, melhorar o projeto de código existente, obter um melhor entendimento de código, dividir para conquistar, entre outras. Ao refatorar pode-se estar apenas removendo código duplicado, melhorando a codificação de forma a tornar o código mais claro de ser entendido, ou até mesmo, substituindo a lógica utilizada por outra mais eficaz, para executar uma mesma responsabilidade. A refatoração pode ser executada em uma única ou em várias etapas. Sendo mais aconselhável e seguro que ela seja feita em pequenos passos (KERIEVSKY, 2008, p. 35, 41-42, 44-47). O processo de refatoração pode ser tão simples como renomear uma variável, que levaria alguns segundos, como levar dias ou meses, como por exemplo, a transformação de um projeto para diferentes arquiteturas (KERIEVSKY, 2008, p. 35). Para auxiliar neste processo, alguns desenvolvedores utilizam ferramentas automatizadas de refatoração.

32 32 Na literatura alguns pioneiros em desenvolvimento de ferramentas são: William Opdyke, Ralph Johnson, John Brant e Don Roberts. Na década de 90, John Brant e Don Roberts criaram uma ferramenta de refatoração automatizada para Smaltalk (KERIEVSKY, 2008, p ). Com isto outras ferramentas foram surgindo e sendo integradas aos Ambientes de Desenvolvimentos Integrados (IDEs), possibilitando que projetos fossem transformados mais facilmente com a utilização destas ferramentas (KERIEVSKY, 2008, p ). Atualmente a maioria das IDEs de desenvolvimento possuem alguma ferramenta de refatoração disponível para efetuar, por exemplo, remoção de código, renomear métodos, encapsular métodos, entre outros tipos de refatoração, sendo que em alguns momentos a ferramenta necessita da intervenção do usuário para confirmar o processo. Tomar uma decisão errada pode trazer resultados indesejados, ou mesmo, mudar as funcionalidades do projeto que está sendo refatorado. A escolha da utilização ou não de ferramentas automatizadas é algo muito particular, e deve ser decidido com cuidado, pois uma ferramenta automatizada não garante que códigos desnecessários sejam inseridos no conteúdo refatorado, e como já citado anteriormente, refatorar também é melhorar códigos, a lógica utilizada e dividir para conquistar entre outras soluções PROCESSO DE REFATORAÇÃO DO FRAMEMK Na refatoração da camada de apresentação do Framemk, utilizaram-se apenas as ferramentas de refatoração automatizadas da IDE Eclipse, por exemplo, a opção Encapsular Campos, utilizada na criação dos ActionsForms do projeto com o Struts. Para testes das telas refatoradas foi utilizado o próprio navegador Web, em que foram verificadas se as funcionalidades explícitas foram mantidas. O processo de refatoração adotado neste trabalho foi dividido em duas etapas principais. A primeira consistiu em uma análise detalhada do Framework de Formação de Preço de Venda para Desktop. A segunda etapa foi formada por um conjunto de atividades que permitiram a geração do sistema para o ambiente Web, que utiliza como entrada o estudo

33 33 realizado na primeira etapa e constitui-se de um processo iterativo. As etapas com suas respectivas atividades estão ilustradas na Figura 16. Figura 16 Processos de refatoração da camada de apresentação do Framemk Fonte: Autoria Própria. Figura 16. A seguir descrevem-se brevemente cada uma das atividades ilustradas na Atividades da primeira etapa: I. Rodar o programa no IDE Netbeans: Nesta etapa, efetuou-se o download do aplicativo desenvolvido por Capeller e Andrade (2010) e que foi descrito no Capítulo 3. Logo após, executou-se o aplicativo em que nenhum problema foi detectado, ou seja, não houve necessidade de nenhuma alteração do programa. II. Analisar o sistema: Ao executar o aplicativo procurou-se nesta etapa identificar o relacionamento entre os objetos, ou seja, escolheu-se um método inicial para análise, por exemplo, ABC, e compreendeu-se seu código para melhor entendimento dos relacionamentos.

34 34 III. Importar o projeto para o IDE Eclipse: Como este trabalho tem como o objetivo refatorar a camada de apresentação, nesta etapa, importaram-se os pacotes de regra de negócio e de persistência da versão Desktop. Para importação foi necessário criar um projeto Web no Eclipse e copiou-se os pacotes BusinessRule, Persistence.DAO e Persistence.DAO.Firebird para o pacote src, gerado pelo ambiente Eclipse. Estes pacotes foram ilustrados nas Figuras 13 a 15. IV. Configurar o Struts para o projeto importado: Neste momento configurou-se o framework Struts seguindo as recomendações descritas em Struts em Ação (HUSTED et al., 2004, p ). Atividades da segunda etapa: I. Criar as Interfaces Web: A partir da etapa de análise do sistema, foi possível criar cada página JSP seguindo a definição de framework, em que se procurou separar os elementos comuns dos específicos. II. Aplicar o Tiles: Esta etapa permitiu a geração de conteúdo dinâmico das informações apresentadas pela interface Web, efetuadas na etapa Criar as Interfaces Web. III. Criar as Actions: Esta etapa permitiu a criação da camada de controle necessário para o relacionamento com a camada de regra de negócio, que na aplicação Desktop pertencia ao pacote View. Isto permitiu separar corretamente as camadas, não misturando regra de negócio com a apresentação na aplicação Web. Como o foco principal deste trabalho é o processo de refatoração, detalha-se na seção seguinte cada uma das atividades da segunda etapa. 4.2 CRIAÇÃO DA CAMADA VIEW BASEADA EM STRUTS Conforme informado na Seção 4.1, o objetivo principal deste trabalho é a refatoração da camada de apresentação para o ambiente Web do Framemk. As subseções da Seção 4.2 detalham o processo de refatoração efetuado para atingir o objetivo descrito.

35 Criar as interfaces Web Concluídas as atividades da primeira etapa, foi possível dar início a construção das páginas JSP. A construção das páginas foi realizada de forma iterativa. Na primeira iteração foram criadas apenas as páginas que iriam conter os pontos comuns, baseados no processo de análise realizado na atividade II da primeira etapa, Subseção 4.1.1, e da validação destes pontos com os encontrados no trabalho de Capeller e Andrade (2010, p ). Para cada página comum, realizou-se a marcação onde os pontos específicos necessários seriam incluídos dinamicamente com o auxílio do framework Tiles. Estas marcações são conhecidas como blocos, conforme os termos utilizados pelo framework Tiles (HUSTED et al., 2004, p. 312). Na segunda iteração foram criadas as páginas com o conteúdo dos pontos específicos, separados pelo mesmo processo de análise realizado na primeira iteração. As classes refatoradas nas iterações citadas anteriormente foram as classes do pacote View, obtidas através da atividade I da primeira etapa do processo de refatoração deste trabalho. Foram reaproveitadas em sua integra as camadas de regra de negócio e persistência, sendo que os pacotes pertencentes a estas camadas foram copiados para o pacote de fontes do projeto Web. As classes do pacote de apresentação estavam codificadas para plataforma Desktop, sendo assim foram refatoradas para a plataforma Web Primeira iteração Para a nomenclatura das páginas que possuíam os pontos comuns, seguiuse o mesmo padrão utilizado para as classes de pontos comuns do pacote View, ilustrado na Figura 6 da Seção 3.4. Por exemplo, a classe CommonWindowAdd.java do pacote View, após refatorada ficou nomeada como CommonWindowAdd.jsp. Lembrando que para o projeto Web passou a ser uma página JSP.

36 36 A Figura 17 mostra parte do conteúdo da página CommonWindowAdd.jsp. A página CommonWindowAdd.jsp possui os pontos comuns para o cadastro de atributos pertencente ao subframework Attributes. Figura 17 Página CommonWindowAdd.jsp Fonte: Autoria Própria. Na Figura 17 a parte indicada como Pontos específicos, será preenchida em tempo de execução pelo framework Tiles. Estes pontos foram marcados através de algumas tags do Tiles, por exemplo, a tag <tiles: insert>, ou mesmo, a tag <tiles: get>. Mais detalhes sobre o Tiles será explicado na atividade Aplicar o Tiles, Subseção As demais classes separadas como pertencentes à pontos comuns foram refatoradas pelo mesmo processo utilizado com a classe CommonWindowAdd.java, por esta razão não serão detalhadas neste trabalho.

37 37 A Figura 18 mostra a estrutura de páginas com pontos comuns, após a primeira iteração ter sido realizada. Figura 18 Estrutura de páginas com elementos comuns Primeira iteração Fonte: Autoria Própria Segunda iteração Na segunda iteração foram refatorados os pontos específicos da camada de apresentação, na qual foram criadas as páginas que possuem conteúdo dinâmico, para posteriormente serem inseridos dinamicamente nos blocos com as tags do framework Tiles. Existem várias maneiras de se implementar o conteúdo dinâmico ao conteúdo HTML, entre elas, a inserção de scriptles Java, utilização de taglibs JSP, utilização de taglibs personalizadas do framework Struts, inclusão de páginas com o uso de templates com o Tiles, ou mesmo o uso em conjunto destas técnicas (HUSTED et al., 2004, p ). Ao construir conteúdo dinâmico deve-se evitar a mistura da lógica de negócio com as tags HTML, pois caso contrário podem ocorrer alguns problemas, por exemplo, tornar as páginas difíceis de manter, de reutilizar e dificultar o trabalho dos Designers. Como já citado, o Struts possui um conjunto de tags personalizadas que podem ser utilizadas para resolver estes problemas (HUSTED et al., 2004, p ). As tags do Struts, assim como as taglibs JSP, funcionam de maneira similar as marcações HTML, porém possuem códigos encapsulados que executam diversas funções internas para representar uma funcionalidade desejada.

38 38 O desenvolvedor somente precisa saber qual das taglibs utilizar para determinada situação. Por exemplo, pode-se utilizar a taglib <logic:iterate> para realizar uma iteração de mapas e matrizes, porém não há necessidade de se preocupar com seu funcionamento interno, ficando isto como responsabilidade do framework (HUSTED et al., 2004, p. 271, ). A Figura 19 mostra o conteúdo da página windowaddfullcost.jsp, onde vêse o uso da tag <logic:iterate>. O conteúdo da página windowaddfullcost.jsp é inserido em tempo de execução no Pontos específicos (Bloco Tiles), ilustrado na Figura 17. Figura 19 Uso da tag <logic:iterate> na página windowaddfullcost.jsp Fonte: Autoria Própria. Conforme o exemplo mostrado através das Figuras 17 e 19, quando utilizado o Método Custo Pleno e selecionado a interação Cadastro de Atributo, o ponto específico para o subframework Attributes será inserido dinamicamente. A maneira pela qual o Tiles sabe qual página será inserida para um determinado bloco será discutido na Subseção 4.2.2, Aplicar o Tiles.

39 39 A Figura 20 mostra a página windowaddsebrae.jsp que é utilizada quando o Cadastro de Atributos é realizado através do Método SEBRAE-PR. Figura 20 Página windowaddsebrae.jsp Fonte: Autoria Própria. As demais classes separadas como pertencentes à pontos específicos, foram refatoradas pelo mesmo processo utilizado com a classe windowaddfullcost.java e windowaddsebrae.jsp, por esta razão não serão detalhadas neste trabalho Aplicar o Tiles Após a atividade Criar as Interfaces Web ter sido concluída, como resultado obteve-se as páginas com os pontos comuns e específicos. Como foi visto nesta atividade, as páginas com pontos comuns possuem blocos onde o conteúdo dinâmico será incluso. É nesta parte que o Tiles entra para auxiliar o desenvolvimento de conteúdo dinâmico e reutilização de layouts. O Tiles possui um recurso chamado Definitions (Definições), pelo qual é possível reutilizar uma página de layout, definindo assim o conteúdo específico em tempo de execução (HUSTED et al., 2004, p. 320).

40 40 Os Definitions podem ser criados a partir de um arquivo JSP ou descritos em um documento XML. Com a utilização da configuração através de um documento XML fica mais fácil gerenciar os layouts dos projetos criados (HUSTED et al., 2004, p. 317, ). Neste trabalho foram codificados os Definitions em arquivos XML. As Definições criadas nestes arquivos são transformadas em objetos que são instanciados quando a aplicação é carregada. O Tiles e o Struts tratam os Definitions como objetos. Sendo assim, uma definição pode herdar e até mesmo sobrescrever os elementos da definição pai, assim como ocorre na herança em orientação a objetos (HUSTED et al., 2004, p. 317). Para facilitar o gerenciamento dos Definitions criados com o Tiles, eles foram separados em dois arquivos XML diferentes: tiles-defs-common.xml e tiles-defsspecific.xml. A Figura 21 ilustra parte do documento tiles-defs-common.xml, onde contém os Definitions para os pontos comuns do projeto Web do Framemk. Figura 21 Parte do conteúdo do documento tiles-defs-common.xml Fonte: Autoria Própria.