MTRICAS PARA AVALIAO DO GRAU DE QUANTIFICAO DE SISTEMAS ORIENTADOS POR ASPECTOS Jaqueline Faria de Oliveira Belo Horizonte 2010 Jaqueline Faria de Oliveira MTRICAS PARA AVALIAO DO GRAU DE QUANTIFICAO DE SISTEMAS ORIENTADOS POR ASPECTOS Dissertao apresentada ao Programa de Ps-Graduao em Informtica como requisito parcial para obteno do Grau de Mestre em Informtica pela Pontifcia Universidade Catlica de Minas Gerais. Orientador: Prof. Dr. Marco Tlio de Oliveira Valente Co-orientador: Prof. Dr. Humberto Torres Marques Neto Belo Horizonte 2010
FICHA CATALOGRFICA
Elaborada pela Biblioteca da Pontifcia Universidade Catlica de Minas Gerais
Oliveira, Jaqueline Faria de O48m Mtricas para avaliao do grau de quantificao de sistemas orientados por aspectos / Jaqueline Faria de Oliveira. Belo Horizonte, 2010. 98f. : il.
Orientador: Marco Tlio de Oliveira Valente Co-orientador: Humberto Torres Marques Neto Dissertao (Mestrado) Pontifcia Universidade Catlica de Minas Gerais. Programa de Ps-graduao em Informtica. Bibliografia.
1. Engenharia de software Teses. 2. Software - Medio. 3. Programao (Computao). I. Valente, Marco Tlio de Oliveira. II. Marques Neto, Humberto Torres III. Pontifcia Universidade Catlica de Minas Gerais. IV. Ttulo.
CDU: 681.3.03 Bibliotecrio: Fernando A. Dias CRB6/1084 minha famlia e amigos. Sem estes nenhum objetivo pode ser alcanado. AGRADECIMENTOS Agradeo primeiramente a Deus por ser o meu guia em todos os momentos, prin- cipalmente naqueles em que pensei em desistir. Agradeo a minha famlia por terem me ensinado o valor das pessoas, do conhe- cimento e das conquistas. Sinceros agradecimentos aos meus pais e minhas irms, Joice e Tania, por me apoiarem em todas as minhas iniciativas, pela pacincia, pelo grande incentivo, e pela compreenso nos momentos em que estive ausente. Ao meu namorado Mateus, que me apoiou nos momentos mais difceis e compreendeu sempre minhas faltas. Agradeo aos amigos que me apoiaram e ajudaram, direta e indiretamente nesta caminhada. Aos professores Raquel Mini, Clodoveu Davis, Ana Maria e Zenilton Kleber por compartilharem seus conhecimentos nas disciplinas que tive oportunidade de cursar. Giovanna, secretria acadmica, pela presteza e ateno especial que d a cada aluno. Aos colegas do mestrado um agradecimento especial, pois o apoio destes foi fundamental para que eu pudesse seguir em frente nesse projeto. Agradeo FAPEMIG pelo incentivo para concluso deste trabalho. Agradeo a Csar Couto, pelo apoio para o desenvolvimento desta pesquisa, sua participao foi muito importante para a concluso deste trabalho. Agradeo ao meu co-orientador Humberto Torres, pelo apoio didtico e especial- mente motivacional para a concluso desta dissertao, por ter se esforado juntamente comigo para a concluso desta etapa de minha vida. Finalmente agradeo ao meu professor e orientador Marco Tlio, pelo conhecimento compartilhado e pelo grande exemplo de prossional da educao e pesquisador. Qualquer agradecimento seria pouco perto da sua dedicao, apoio, disponibilidade e compreenso. Meus sinceros agradecimentos por essa lio de vida. Muito obrigada a todos! RESUMO A refatorao de sistemas orientados por aspectos projetada para separar e mo- dularizar interesses transversais e reduzir o espalhamento e entrelaamento de cdigo. No entanto, estes resultados no so sempre alcanados. Pesquisas sobre a avaliao da refatorao de sistemas orientados por aspectos so baseadas na aplicao de mtricas de software. Essas mtricas geralmente medem atributos do software j refatorado, o que implica na necessidade de realizar a refatorao antes de conseguir qualquer resultado signicativo. Neste trabalho, defendemos a utilizao da quanticao como um fator de medio para avaliar a refatorao do interesse para aspectos. A refatorao indicada quando interesses transversais possuem um alto grau de quanticao, ou seja, quando diversas chamadas do interesse podem ser modularizadas por um nmero pequeno de advices. Para isso, propomos duas novas mtricas para avaliar o grau de quanticao dos interesses que sero refatorados para aspectos. A mtrica Quantication Degree (QD) que mede o grau de quanticao do interesse transversal, e a mtrica Scattering Reduction (SR), que por sua vez mede a reduo do espalhamento de cdigo. Ambas as mtricas so calculadas com base no cdigo fonte original, permitindo aos engenheiros de software uma avaliao do resultado da refatorao antes de qualquer alterao estrutural do sistema. As mtricas propostas so descritas formalmente e so apresentados exemplos de sua aplicao em estudos de caso que utilizam sistemas reais. Ns tambm propomos nesta pesquisa o projeto e a implementao da ferramenta ConcernMetrics. Esta ferramenta usada para automatizar o clculo das mtricas pro- postas nesta dissertao, QD e SR. A ferramenta ConcernMetrics tambm calcula mtri- cas de separao de interesses j difundidas para avaliao de sistemas orientados por aspectos. Estes clculos so feitos diretamente no cdigo orientado por objetos de um sistema existente, ou seja, antes de interesses transversais serem extrados para aspectos. So apresentados resultados da utilizao da ferramenta ConcernsMetrics em sistemas reais. Nossos resultados mostram que as mtricas QD e SR calculam efetivamente o grau de quanticao de interesses transversais antes da refatorao do sistema. Ressaltamos tambm que a ferramenta ConcernMetrics, desenvolvida ao longo deste trabalho, facilita o clculo das mtricas propostas. Palavras-chave: Programao orientada por aspectos. AspectJ. Quanticao. Separao de Interesses. Mtricas. Refatorao. ABSTRACT Refactoring of aspect-oriented systems is designed to separate and modularize the crosscutting concerns and reduce the spreading and interlacing of code. However, these results are not always achieved. The research on evaluation of the refactoring aspect- oriented systems are based on the application of software metrics. These metrics usually measure attributes of software already refactored, which implies the need to perform refactoring before achieving any signicant result. In this work, we advocated the use of quantication as a factor of measurement for assessing the interests of refactoring to aspects. Refactoring is indicated when crosscut- ting concerns have a high degree of quantication, ie, when several calls of concern can be modularized by a small number of advices. For this, we propose two new metrics to evaluate the degree of quantication of interests that will be refactored to aspects. The metric Quantication Degree (QD), which measures the degree of quantication of cross- cutting interest, and the metric Scattering Reduction (SR), which in turn measures the reduction of the spreading code. Both metrics are calculated based on the original source code, allowing software engineers to evaluate the result of refactoring before any struc- tural change in the system. The proposed metrics are formally described and presented examples of its application in case studies using real systems. We also present this research work the design and the implementation of the Con- cernMetrics. This tool is used to automate the calculation of the metrics proposed in this dissertation, QD and SR. The ConcernMetrics also calculates metrics of separation of concerns already widespread for evaluation of aspect-oriented systems. These calcu- lations are done directly on the object-oriented code of an existing system, ie, before being extracted crosscutting concerns to aspects. We present the results of using the tool ConcernsMetrics with real systems. Our results show that the metrics QD and SR calculate eectively the degree of quantication of crosscutting concerns before the refactoring of the system. We also emphasize that the tool ConcernMetrics developed throughout this paper facilitates the calculation of the metrics proposed. Key-words: Aspect-oriented programming. AspectJ. Quantication. Separation of Concerns. Metrics. Refactoring. LISTA DE FIGURAS FIGURA 1 Exemplo de requisito transversal espalhado por diversos mdulos (LAD- DAD, 2003). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 FIGURA 2 Exemplo de requisito transversal entrelaado ao cdigo fonte do inte- resse funcional (LADDAD, 2003). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 FIGURA 3 Concern Maps da ferramenta ConcernMapper. . . . . . . . . . . . . . . . . . . . . . 41 FIGURA 4 Ferramenta ConcernMorph (FIGUEIREDO; WHITTLE; GARCIA, 2009). 42 FIGURA 5 Chamada do interesse transversal transaction de JAccounting. . . . . . 46 FIGURA 6 Aspecto com modularizao do interesse transaction em JAccounting. 47 FIGURA 7 Chamada do interesse transversal Logging de JSpider. . . . . . . . . . . . . . . 47 FIGURA 8 Exemplo da descrio do pointcut e implementao do advice em JSpi- der . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 FIGURA 9 Modelo de Concerns do interesse transversal transaction do estudo de caso JAccounting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 FIGURA 10 Modelo de Concerns do interesse transversal logging do estudo de caso JSpider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 FIGURA 11 Valores de QD assumidos para concerns mapeados para 20 join point shadows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 FIGURA 12 Exemplos de chamadas do interesse Ponto no sistema Gracos. . . . . 55 FIGURA 13 Identicao dos mtodos dos interesses a partir da viso da ferramenta ConcernMapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 FIGURA 14 Ferramenta ConcernMetrics: Modelo de Concerns do interesse trans- versal logging do sistema JSpider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 FIGURA 15 Diagrama de sequncia da ferramenta ConcernMetrics. . . . . . . . . . . . . . 61 FIGURA 16 Ferramenta ConcernMetrics: apresentao do resultado do clculo das mtricas para o interesse transversal logging do sistema JSpider. . . . . . . 62 FIGURA 17 Interface ClassVisitor do framework ASM (BRUNETON; LENGLET; COUPAYE, 2002). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 FIGURA 18 Diagrama de classes da ferramenta ConcernMetrics. . . . . . . . . . . . . . . . . 64 FIGURA 19 Exemplo de chamadas do interesse transversal log. . . . . . . . . . . . . . . . . . 65 FIGURA 20 Exemplo de interesses transversais do sistema JSpider. . . . . . . . . . . . . . 66 FIGURA 21 Exemplo de chamada de interesses transversais chamados em sequn- cia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 FIGURA 22 Exemplo de chamada de interesse transversal do sistema JSpider. . . 68 FIGURA 23 Modelo de Concerns do interesse transversal transaction do sistema JAccounting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 FIGURA 24 Chamadas consecutivas de debug em JSpider. . . . . . . . . . . . . . . . . . . . . . . 79 FIGURA 25 Modelo de Concerns do sistema JHotDraw. . . . . . . . . . . . . . . . . . . . . . . . . 82 LISTA DE TABELAS TABELA 1 Informaes sobre verso orientada por aspectos dos sistemas JAc- counting e JSpider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 TABELA 2 Resultado da aplicao das mtricas CLC, CDO e CDC na verso orientada por objetos e orientada por aspectos dos sistemas JAccounting e JSpider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 TABELA 3 Clculo de QD e SR para os interesses setX(int x) e SetY(int y). 55 TABELA 4 Comparao de valores de QD e SR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 TABELA 5 Valores de QD e SR para o sistema JAccounting. . . . . . . . . . . . . . . . . . . 72 TABELA 6 Valores de QD e SR para o sistema JSpider. . . . . . . . . . . . . . . . . . . . . . . . 73 TABELA 7 Valores de QD e SR para o sistema JHotDraw. . . . . . . . . . . . . . . . . . . . . 74 TABELA 8 Valores de SR e QD para o interesse transversal transaction de JAc- counting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 TABELA 9 Valores de CDC e CDO para o interesse transversal transaction de JAccounting do cdigo fonte orientado por objetos. . . . . . . . . . . . . . . . . . . . 77 TABELA 10 Valores de CDC e CDO para o interesse transversal transaction de JAccounting do cdigo fonte orientado por aspectos. . . . . . . . . . . . . . . . . . 77 TABELA 11 Clculo de QD e SR para o interesse transversal logging do sistema JSpider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 TABELA 12 Mtrica CDC para o interesse logging nas verses orientadas por objetos e orientadas por aspectos do sistema JSpider, bem como estimativa para essas mtricas produzida pela ferramenta ConcernMetrics (CM). . . . . . 80 TABELA 13 Mtrica CDO para o interesse logging calculado a partir do cdigo ori- entado por objetos e do cdigo orientado por aspectos do sistema JSpider, bem como estimativa para essas mtricas produzida pela ferramenta Con- cernMetrics(CM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 TABELA 14 Resultado de QD e SR para JHotDraw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 TABELA 15 Resultado de CDC e CDO para os interesses transversais de JHotDraw do cdigo fonte orientado por objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 TABELA 16 Resultado de CDC e CDO para os interesses transversais de JHotDraw do cdigo fonte orientado por aspectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 LISTA DE SIGLAS AIF - Attribute Inheritance Factor AST - Abstract Syntax Tree BAC - Basic and Advanced Dynamic Crosscuts CAE - Coupling on Advice Execution CBC - Coupling Between Components CBO - Coupling Between Objet Classes CDA - Crosscutting Degree of an Aspect CDC - Concern Diusion over Components CDO - Concern Diusion over Operations CF - Coupling Factor CFA - Coupling on Field Access CIA - Classes, Interfaces, and Aspects CIM - Coupling on Intercepted Modules CLC - Concern Lines of Code CMC - Coupling on Method Call CRR - Code Replication Reduction CS - Class Size DIT - Depth of the Inheritance Tree DOSC - Degree of Scattering Across Classes DOSM - Degree of Scattering Across Methods GUI - Graphical User Interface HHC - Heterogeneous and Homogeneous Crosscuts JPS - join point shadows LCOM - Lack of Cohesion in Methods LCOO - Lack of Cohesion in Operations LOC - Lines of Code MIF - Method Inheritance Factor NOA - Number of Operations Added by a Subclass NOC - Number of Children NOO - Number of Operations Overridden by a Subclass POA - Programao Orientada por Aspectos POO - Programao Orientada por Objetos QD - Quantication Degree RFC - Response For a Class RFM - Response For a Module SDC - Static and Dynamic Crosscuts SI - Specialization Index SR - Scattering Reduction WMC - Weighted Methods per Class WOC - Weighted Operations per Component SUMRIO 1 INTRODUO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3 Estrutura da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2 REVISO DA LITERATURA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1 Programao Orientada por Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Mtricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Mtricas de Software Orientado por Objetos . . . . . . . . . . . . . . . . . . . 29 2.5 Mtricas de Software Orientado por Aspectos . . . . . . . . . . . . . . . . . . 33 2.6 Avaliaes em Projetos Orientados por Aspectos . . . . . . . . . . . . . . . . 38 2.7 Ferramentas de Automao de Clculo de Mtricas . . . . . . . . . . . . . 41 2.8 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3 MTRICAS PARA AVALIAO DO GRAU DE QUANTIFICAO 44 3.1 Avaliaes Quantitativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2 Denies das Mtricas de Avaliao do Grau de Quanticao . . . 50 3.2.1 Modelo de Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.2.2 Formalizao das Mtricas de Quanticao . . . . . . . . . . . . . . . . 52 3.3 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4 FERRAMENTA CONCERNMETRICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2 Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2.2 Anlise do Cdigo Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.3 Algoritmos de Deciso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3 Limitaes da Ferramenta ConcernMetrics . . . . . . . . . . . . . . . . . . . 69 4.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5 AVALIAES DO GRAU DE QUANTIFICAO. . . . . . . . . . . . . . . . . . 71 5.1 Avaliao Manual das Mtricas QD e SR . . . . . . . . . . . . . . . . . . . . . 71 5.1.1 Exemplo 1 - JAccounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.1.2 Exemplo 2 - JSpider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.1.3 Exemplo 3 - JHotDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.2 Avaliao da Ferramenta ConcernMetrics . . . . . . . . . . . . . . . . . . . . 75 5.2.1 Exemplo 1 - JAccounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2 Exemplo 2 - JSpider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.2.3 Exemplo 3 - JHotDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2.4 Anlise ConcernMetrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6 CONCLUSES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.1 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.2 Comparao com Outros Trabalhos . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2.1 Mtricas de Software Orientado por Aspectos . . . . . . . . . . . . . . . 91 6.2.2 Avaliaes Orientadas por Aspectos . . . . . . . . . . . . . . . . . . . . . . . 92 6.2.3 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 17 1 INTRODUO 1.1 Motivao O paradigma de programao orientada por aspectos (POA) tem se tornado a tecnologia mais difundida para modularizao de interesses transversais. Esses interesses normalmente encontram-se espalhados e entrelaados no cdigo fonte, que por sua vez podem ocasionar problemas de reutilizao, modularizao, extensibilidade, entre outros. POA estende paradigmas de programao tradicionais, como a procedural e orientada por objetos, possibilitando abstraes no comportamento do sistema. Essas abstraes podem ocorrer de duas formas, por meio da transversalidade esttica que permite alteraes na hierarquia de classes e introduo de mtodos e atributos em classes atravs de declaraes inter-tipo, e da transversalidade dinmica que permite a alterao no comportamento de um programa em pontos especcos (LADDAD, 2003). A linguagem AspectJ um bom exemplo de linguagem orientada por aspectos, sendo na atualidade a mais madura. AspectJ estende Java com a incluso de novas abstraes da linguagem, incluindo join points, pointcuts, advices e aspectos (KICZALES et al., 2001). Como vantagens da POA podem-se citar a modularizao de requisitos transver- sais, reutilizao, extensibilidade, facilidade de manuteno e reduo do espalhamento e entrelaamento de cdigo (KICZALES; HILSDALE, 2001; KICZALES et al., 1997; IRWIN et al., 1997; SOMMERVILLE, 2006). Com o intuito de validar esses benefcios em sistemas reais e ainda estudar outras vantagens e desvantagens na utilizao de aspectos, diver- sos estudos foram feitos (EADDY et al., 2008; FIGUEIREDO et al., 2009; FILHO et al., 2006; APEL, 2010; GARCIA et al., 2007; STEIMANN, 2006). Atributos como tamanho, comple- xidade, acoplamento, coeso, herana, entre outros, amplamente estudados a partir da aplicao de mtricas de software orientadas por objetos, so foco tambm de estudos atu- ais relacionados a sistemas orientados por aspectos (SANTANNA et al., 2003; CECCATO; TONELLA, 2004; APEL, 2010; EADDY et al., 2008). Nestes utilizam-se ainda as medi- das de espalhamento e entrelaamento de cdigo, separao de interesses e quanticao. Dentre esses atributos medidos em sistemas orientados por aspectos, vericado que a 18 noo de quanticao (FILMAN; FRIEDMAN, 2005) pouco explorada, argumenta-se que um dos usos mais favorveis dos aspectos acontece quando o seu cdigo estende ampla- mente declaraes quanticadas, ou seja, declaraes que tm efeito em diversos pontos do cdigo. Quando isso acontece, os aspectos contribuem para a separao de interesses, uma vez que o cdigo pode ser connado em um nico bloco de cdigo. As avaliaes em sistemas orientados por aspectos, conforme ocorre nos sistemas dos demais paradigmas de programao, so normalmente feitas utilizando-se mtricas de software, as quais consistem no processo de medio de atributos do sistema. A utilizao de mtricas na engenharia de software, embora possam prover informaes importantes para medio e controle, no um processo amplamente difundido (FENTON; NEIL, 1999). Esse fato pode ser atribudo diculdade da aplicao de mtricas em sistemas muito grandes, ou o fato dos processos de medio nas instituies no serem maduros, alm disso o alto custo dos programas de mtricas tambm pode ser um fator dicultador (KANER; MEMBER; BOND, 2004). Em geral, trabalhos na rea de mtricas de software para sistemas orientados por aspectos medem caractersticas especcas do cdigo fonte j refatorado para aspectos, dessa forma necessria a implementao dos aspectos para posterior avaliao. Por exemplo, as mtricas de separao de interesses Concern Diusion over Operations (CDO) e Concern Diusion over Components (CDC) (GARCIA et al., 2005; SANTANNA et al., 2003; GREENWOOD et al., 2007), do uma noo da importncia e impacto dos aspectos no sistema, porm seu clculo feito com base no cdigo fonte orientado por aspectos. Alguns trabalhos propem o renamento das mtricas CK (CHIDAMBER; KEMERER, 1994), para avaliao de projetos orientados por aspectos, como os trabalhos de SantAnna et al. (2003) e Ceccato e Tonella (2004). Outros trabalhos fazem novas propostas de mtricas para avaliao de aspectos como o trabalho de Apel (2010), esses tambm se baseiam na anlise do cdigo orientado por aspectos. Essas mtricas apresentam vantagens e limitaes diversas, porm nenhum con- junto de mtricas consegue atender a todos os atributos necessrios para a avaliao e previso do resultado da refatorao de sistemas para aspectos. O conceito de atributos necessrios para uma avaliao e previso de software muito complexo e obedece a di- versos fatores, conforme cada sistema e tecnologia, esse fato tambm se aplica avaliao de softwares orientados por aspectos. As mtricas propem-se, em sua maioria, a medir atributos estticos baseadas nos produtos de software, cdigo fonte, projeto, diagramas e etc. Outra caracterstica observada nas mtricas existentes o fato de serem normal- 19 mente mtricas avaliativas, ou seja, avaliam atributos j existentes baseados em artefatos estticos, no caso de sistemas orientados por aspectos o cdigo fonte j refatorado o prin- cipal artefato. As mtricas atuais para sistemas orientados por aspectos, em sua maioria, no provem informaes de previso, ou seja, no possibilitam a estimativa prvia de determinados comportamentos ou resultados da refatorao do sistema baseados em um conjunto de informaes existentes. A carncia de mtricas para previso de sistemas orientados por aspectos tem tornado difcil a avaliao da refatorao de um sistema previamente implementao dos interesses utilizando-se aspectos, e essa diculdade aumenta conforme o tamanho do sistema. De acordo com pesquisas, no so identicadas mtricas que possibilitem a avaliao prvia da refatorao para aspectos baseada no cdigo fonte original do sistema. 1.2 Objetivos Denir mtricas para avaliao do grau de quanticao de requisitos transversais com o intuito de prover uma medida para avaliao da refatorao de um sistema para aspectos. Possibilitar aos mantenedores de software decidirem, de uma forma economica- mente efetiva, se vale a pena usar aspectos em seus sistemas atravs destas mtricas. Os objetivos especcos desta pesquisa so detalhados a seguir: Denir a mtrica Quantication Degree (QD) para avaliao do grau de quanti- cao de requisitos transversais, e a submtrica Scattering Reduction (SR) com o intuito de medir a reduo do espalhamento de um interesse no sistema. Essas mtricas tm o objetivo de inferir o grau de quanticao dos interesses transversais do sistema relativos a uma possvel modularizao destes atravs de aspectos, para serem utilizados como fatores de avaliao da refatorao para aspectos do sistema. Projetar e implementar a ferramenta ConcernMetrics para apoio no processo de clculo das mtricas de quanticao denidas. A ferramenta ConcernMetrics ir possibilitar a identicao e avaliao de requisitos transversais, criao de um Mo- delo de Concerns e efetuar o clculo das mtricas de quanticao QD e SR. Dever ainda calcular mtricas conhecidas de separao de interesses CDC e CDO para o cdigo orientado por objetos e estimar o valor dessas mtricas caso o sistema venha a ser migrado para aspectos. Esses clculos sero feitos automaticamente sem nenhuma alterao no sistema e baseado em informaes coletadas diretamente 20 do cdigo fonte orginal. Essa ferramenta deve ser utilizada no ambiente de desen- volvimento Eclipse e avalia projetos desenvolvidos na linguagem Java. Com o apoio das mtricas QD e SR e da ferramenta ConcernMetrics, ser feita uma anlise quantitativa em trs sistemas de mdio porte. Esta anlise ser feita atravs do resultado do clculo das mtricas QD e SR utilizando-se a ferramenta ConcernMetrics, baseada no cdigo orientado por objetos. Esses mesmos clculos sero feitos manualmente diretamente no cdigo fonte j refatorado para aspectos. Os resultados sero comparados gerando uma relao entre o grau de quanticao dos sistemas e o resultado da refatorao para aspectos. Os resultados obtidos nesta pesquisa podem ser teis aos mantenedores de software para a identicao e modelagem de interesses transversais, para uma medida quantitativa dos requisitos transversais do sistema, assim como a medida da reduo do espalhamento do interesse transversal atravs de aspectos. As informaes obtidas atravs das mtricas propostas podero ser utilizadas como fatores para tomada de decises quando se avalia a refatorao de um sistema para aspectos. 1.3 Estrutura da Dissertao Nesta seo, apresenta-se a organizao do contedo desta dissertao. No Cap- tulo 2, realiza-se uma reviso da literatura diretamente relacionada ao desenvolvimento desta dissertao. Essa reviso inclui Desenvolvimento Orientado por Aspectos, Conceitos gerais de Mtricas de Software, Mtricas de Software Orientado por Objetos e por Aspec- tos, Avaliaes de Sistemas Orientados por Aspectos e Ferramentas para Automatizao do Clculo de Mtricas de Software. No Captulo 3 so denidas as mtricas QD e SR, que so a proposta desta disser- tao. Inicialmente apresentado um estudo quantitativo de sistemas refatorados para aspectos, a seguir as denies formais das mtricas QD e SR e nalmente exemplos da aplicao dessas mtricas. No Captulo 4 detalhado o projeto e implementao da ferramenta Concern- Metrics, como interface, leitura do cdigo fonte e algoritmos de deciso. Essa ferramenta possibilita a montagem do Modelo de Concerns, e baseado neste modelo, efetua os cl- culos das mtricas QD e SR. Alm disso, calcula as mtricas CDC e CDO para o cdigo orientado por objetos e estima o valor dessas mtricas caso o sistema seja refatorado para aspectos. 21 No Captulo 5 feita uma avaliao manual da aplicao das mtricas QD e SR em sistemas reais analisando seus resultados e os comparando com resultados desses mesmos sistemas j em uma verso orientada por aspectos. Ainda nesse captulo so apresentados estudos da utilizao da ferramenta ConcernMetrics em sistemas reais, e comparados os resultados obtidos pela ferramenta com resultados calculados manualmente nos cdigos orientados por objetos e orientados por aspectos para esses sistemas. No Captulo 6 ser apresentada a concluso desta dissertao, onde so apresenta- das as principais contribuies, comparaes com trabalhos relacionados e ainda algumas propostas para trabalhos futuros com o intuito de dar continuidade pesquisa desen- volvida. 22 2 REVISO DA LITERATURA Neste captulo, sero apresentados os principais conceitos, tecnologias e trabalhos relacionados ao tema desta dissertao. Na Seo 2.1, apresentado o paradigma de programao orientada por aspectos, na Seo 2.2 so descritos os principais conceitos da linguagem de programao AspectJ, na Seo 2.3 so apresentados os conceitos gerais de Mtricas de Software, na Seo 2.4 e 2.5 so descritas respectivamente Mtricas de Software Orientado por Objetos e Mtricas de Software Orientado por Aspectos, na Seo 2.6 so expostos alguns estudos de avaliao de software orientado por aspectos e na Seo 2.7 sero apresentadas ferramentas de automao de clculo de mtricas de software. Por m, na Seo 2.8, so apresentadas as consideraes nais da Reviso da Literatura. 2.1 Programao Orientada por Aspectos O paradigma de programao orientada por objetos (POO) permite modelar um software conforme a viso do homem sobre o mundo, por meio de objetos que podemos categorizar, descrever, organizar, manipular e relacionar (PRESSMAN, 2005). Segundo Pressman (2005), o paradigma de POO muito mais que um paradigma de programao, uma viso completa de engenharia de software, que traz como principais vantagens a possibilidade de reutilizao, agilidade de desenvolvimento, a manutenabilidade e quali- dade do software. Por meio do paradigma de POO, possvel implementar os requisitos funcionais e no funcionais de um sistema. Os requisitos funcionais so os servios que o sistema deve oferecer, como deve reagir a entradas e sadas especcas. Os requisitos no funcionais so restries sobre os servios ou funes oferecidas pelo sistema, como segurana, performance, log, entre outros (SOMMERVILLE, 2006). A POO apresenta grande eccia para a implementao da maioria dos requisitos funcionais utilizando classes, mtodos e atributos. Porm, nem sempre consegue imple- mentar com sucesso requisitos no-funcionais e at alguns requisitos funcionais especcos, porque esses so requisitos transversais, ou seja, esto distribudos por diversas classes 23 do sistema, ocasionando o espalhamento e entrelaamento do cdigo (KICZALES et al., 1997; SOMMERVILLE, 2006). Um requisito se encontra espalhado pelo cdigo do sistema quando sua implementao est distribuda em diversos pontos, podendo ocorrer quando h diversas chamadas praticamente idnticas ou h a implementao em diversos pontos do mesmo interesse. Um requisito se encontra entrelaado quando o cdigo do requi- sito transversal est implementado juntamente com o cdigo fonte do requisito funcional (LADDAD, 2003; KICZALES et al., 1997; SOMMERVILLE, 2006). Esses interesses, por estarem espalhados ou entrelaados pelas classes, podem oca- sionar diversas implicaes durante o desenvolvimento, manuteno e evoluo do sistema (KICZALES et al., 1997). Como exemplos pode-se citar a diculdade de rastreamento de interesses, baixa produtividade, baixo grau de reso, baixa qualidade interna com baixa coeso modular, alto grau de acoplamento de mdulos e tambm baixa extensibilidade (TIRELO et al., 2004; EADDY et al., 2008), alm de que, conforme o estudo de Eaddy et al. (2008), pode proporcionar uma abertura a gerao de defeitos no projeto. A Figura 1 representa os requisitos transversais espalhados e, na Figura 2, os requisitos transversais entrelaados pelos mdulos do sistema. Figura 1: Exemplo de requisito transversal espalhado por diversos mdulos (LADDAD, 2003). A programao orientada por aspectos (POA), proposta por Kiczales e Hilsdale 24 Figura 2: Exemplo de requisito transversal entrelaado ao cdigo fonte do interesse funcional (LADDAD, 2003). (2001), Kiczales et al. (1997), surgiu com o intuito de atender a necessidade de mo- dularizao dos requisitos que no sejam adequadamente implementados por linguagens orientadas por objetos (MENDHEKAR; KICZALES; LAMPING, 1997). O paradigma de POA prope que o desenvolvimento de software orientado por aspectos torne possvel imple- mentar interesses, tanto transversais quanto no-transversais, de forma modularizada, ou seja, possvel retirar a chamada do interesse do cdigo base e conn-lo em uma nica unidade chamada aspecto (KICZALES et al., 1997; SOMMERVILLE, 2006). A POA traz como principais vantagens a modularizao de requisitos transversais, reutilizao e extensibi- lidade de cdigo, facilidade de manuteno e reduo do espalhamento e entrelaamento de cdigo (KICZALES et al., 1997; IRWIN et al., 1997; SOMMERVILLE, 2006). A implementao de interesses transversais atravs de aspectos pode ocorrer de duas formas: (1) Static crosscutting ou transversalidade esttica, que permite alteraes na hierarquia de classes e introduo de mtodos e atributos em classes por meio de declaraes inter-tipo (inter-type declarations); e (2) Dynamic crosscutting ou transver- salidade dinmica, que possibilita a alterao no comportamento de um programa em pontos especcos de sua execuo (LADDAD, 2003). 25 A POA utiliza-se de uma unidade de modularizao aspectos para connar os interesses transversais, os pontos especcos onde os interesses transversais devem ser introduzidos so chamados de join points. Os join point shadows, ou sombra de ponto de juno, correspondem estaticamente ao trecho de cdigo responsvel pela ativao de um ponto de juno (HILSDALE; HUGUNIN, 2004). Os pointcuts, por sua vez contm as regras para agrupar as chamadas dos join points, o cdigo do interesse transversal que deve ser inserido em cada join point est implementado nos advices, estes podem ser inseridos antes (before), durante (around) ou depois (after) dos join points (LADDAD, 2003; SOM- MERVILLE, 2006; TIRELO et al., 2004). O compilador de aspectos denominado weaver, este tem por funo realizar o processo de costura de cdigo (weaving), introduzindo o cdigo dos interesses nos join points especicados (LADDAD, 2003; SOMMERVILLE, 2006; TIRELO et al., 2004). 2.2 AspectJ AspectJ uma linguagem de programao orientada por aspectos proposta nos trabalho de Kiczales e Hilsdale (2001) e Kiczales et al. (1997), atualmente a mais uti- lizada na implementao de programao orientada por aspectos em Java (APEL, 2010; GRADECKI; LESIECKI, 2003). AspectJ permite a implementao de requisitos transversais por meio da transversalidade esttica e dinmica (LADDAD, 2003). A transversalidade esttica em AspectJ tratada por meio da clusula declare parents, que possibilita a introduo de membros em classes e interfaces ou a alterao de uma hierarquia de classes, entre outras alteraes nos componentes estticos do pro- grama. AspectJ porm tem um foco maior no tratamento da transversalidade dinmica, sendo que a partir desta possvel a exposio de pontos de um programa que podem ser interceptados e a denio de quais aes sero associadas a esse ponto (LADDAD, 2003). Assim como o foco desta dissertao, as demais informaes sobre AspectJ sero referentes ao tratamento da transversalidade dinmica. Em AspectJ possvel selecionar os pontos de juno relativos aos eventos de execuo utilizando-se o operador execution e chamadas de mtodos atravs do operador call, mais a parametrizao da assinatura do mtodo em ambos os casos. No caso de tratamento de chamadas de construtores utiliza-se, alm do operador call, tambm o operador new no lugar do nome do mtodo e sem tipo de retorno (GRADECKI; LESIECKI, 2003; LADDAD, 2003). Por exemplo, o pointcut para interceptar as chamadas do mtodo f(int) da classe Point ter a construo call(void Point.f(int)), a interceptao 26 do construtor da classe Point ter a construo call(Point.new(int)) (TIRELO et al., 2004). Os pontos de juno, responsveis por leitura e escrita de atributos da classe, possi- bilitam a captura destes atravs dos operadores get para leitura e set para escrita, ambos parametrizados com a assinatura do campo (TIRELO et al., 2004; GRADECKI; LESIECKI, 2003; LADDAD, 2003). Por exemplo, a construo get(Point.x) representa os acessos de leitura do campo x da classe Point, assim como a construo set(Point.x) representa os acessos de escrita do campo x (TIRELO et al., 2004). A interceptao de tratadores de excees a partir de aspectos se d atravs do operador handler, o qual permite denir join points que tratam a execuo dos blocos catch (GRADECKI; LESIECKI, 2003; LADDAD, 2003). Como exemplo podemos citar o tratamento da exceo NumberFormatException a qual ser denido atravs do operador handler(NumberFormatException) (TIRELO et al., 2004). Aps a denio dos pontos de juno sero inseridos nesses pontos os advices, estes denem como interferir nos join points atravs de before, after e around, e qual o cdigo do interesse que deve ser executado. Uma regra before executada imediatamente antes da execuo do join point e a regra after executada imediatamente aps, a regra around dene uma execuo que ser executada no lugar do join point, podendo denir se a execuo continuar normalmente ou no (GRADECKI; LESIECKI, 2003; LADDAD, 2003). Com AspectJ possvel modularizar os requisitos transversais de sistemas Java atravs de aspectos, porm AspectJ d somente as ferramentas para essa implementao. Os arquitetos de software e programadores precisam conhecer tanto da linguagem quanto do sistema para tomar as decises inerentes a quais requisitos devem ser modularizados, quais requisitos sero implementados por um mesmo advice e at que ponto a refatorao desse interesse transversal apresenta vantagens ao sistema como um todo, ou seja, necessrio o conhecimento tcnico aliado a uma anlise e deciso de projeto para um bom resultado da refatorao para aspectos de um software. 2.3 Mtricas de Software Medio um processo imprescindvel para o controle e avaliao de projetos em todas as reas, na engenharia de software esse processo tambm no diferente (PRESS- MAN, 2005), principalmente com a crescente necessidade de melhoria e controle constante dos projetos de software. Segundo Park, Goethert e Florac (1996), as quatro razes 27 para medir software so caracterizar, avaliar, prever e melhorar. Conforme Fenton e Neil (1999), o foco da medio fornecer informaes para apoiar gerencialmente a tomada de deciso durante o processo de desenvolvimento, possibilitar a melhoria contnua, auxiliar na estimativa, controle de qualidade e avaliao do software (PRESSMAN, 2005). Porm, mesmo sendo to importante e tendo uma gama de estudos na rea, as mtricas de software no so efetivamente utilizadas (FENTON; NEIL, 1999). Isso talvez se justique porque em muitas empresas os processos no so organizados ou no esto maduros o bastante para fazer o uso de medies (SOMMERVILLE, 2006). Quando a medio feita nem sempre seguem boas prticas de medio, o que pode impactar no resultado nal, alm disso, mtricas sero sempre uma sobrecarga em projetos de software, essa sobrecarga est em torno de 4 a 8% do projeto (HALL; FENTON, 1997). Segundo Kaner, Member e Bond (2004), pode-se interpretar esses fatos como prova da imaturidade e falta de prossionalismo do campo ou da resistncia ao alto custo dos programas de mtricas. Em outros casos porm, os programas de mtricas so rejeitados, porque sua aplicao pode trazer resultados negativos ao invs de positivos ao projeto, isso ocorre porque muitas vezes nos projetos de software no se sabe ao certo o que medir e se o que est sendo medido o que se deseja realmente. O processo de medio se preocupa em atribuir um valor numrico ou simblico para algum atributo de um produto de software ou um processo de software de acordo com regras claramente denidas (SOMMERVILLE, 2006; FENTON, 1994). A partir da coleta desses valores possvel aplicar mtricas, processo que, simplicando, consiste em relacionar esses valores para gerar resultados. As mtricas de software podem ser tanto de controle, que so normalmente associ- adas com os processos de software, como por exemplo o esforo mdio e tempo necessrio para reparar defeitos relatados, ou mtricas de previso, que so associadas a produtos de software, por exemplo a complexidade de um mdulo e o nmero de atributos (SOM- MERVILLE, 2006). As mtricas de previso que esto diretamente relacionadas com as caractersticas do software em si so as mtricas de produtos. Estas se dividem em: (i) mtricas dinmicas, que so coletadas durante a execuo do software, como por exem- plo a quantidade de erros gerados, nmero de acessos, processamento, etc; (ii) mtricas estticas, que so coletadas diretamente no sistema, como o projeto, cdigo fonte ou documentao (SOMMERVILLE, 2006). Para um processo de medio no existem regras pr-denidas, porm alguns es- tudos sobre o assunto foram feitos com o intuito de estabelecer conceitos para direcionar 28 (PARK; GOETHERT; FLORAC, 1996), analisar (EJIOGU, 1991), caracterizar (ROCHE, 1994) e denir (EJIOGU, 1991) o processo de medio, formulao e anlise da medio. Em seu estudo sobre Mtricas de Software e Princpios de Medio, Roche (1994) dene al- guns princpios para medio de software. Conforme esse estudo, um processo de medio pode se dividir em (1) formulao da medio, (2) coleta e (3) anlise dos dados, (4) interpretao dos resultados e (5) feedback dos resultados encontrados. H ainda alguns processos denidos para garantir a validao de mtricas de soft- ware, pois mtricas so teis apenas se forem caracterizadas efetivamente e validadas de forma que seu valor seja aprovado (PRESSMAN, 2005). Desta forma devem aderir cincia da medio para que ganhem ampla aceitao e validade (FENTON; NEIL, 1999). Para uma eciente formulao de mtricas, Roche (1994) dene alguns princpios: (1) Os objetivos da medio devem ser estabelecidos antes da coleta de dados, (2) a denio da mtrica deve ser clara e inequvoca, (3) mtricas devem ser construdas dentro do domnio da aplicao e (4) mtricas para serem ecientes devem ser adaptadas para determinados produtos e processos. Com o intuito de validar mtricas, existem atributos que essas devem possuir, conforme os estudos de Pressman (2005) e Ejiogu (1991): (1) Uma mtrica deve ser simples e computvel. (2) Uma mtrica deve ser consistente no uso de unidades e dimenses e deve sempre estar dentro de um intervalo signicativo, por exemplo seu valor deve estar dentro do intervalo 0 e 1 . (3) Uma mtrica deve ter caractersticas empricas e intuitivas, por exemplo seu valor deve aumentar ou diminuir de acordo com a presena maior ou menor do atributo que est sendo avaliado pela mtrica. (4) Uma mtrica deve ser amplamente avaliada para ento ser publicada e utilizada para tomar decises. (5) Uma mtrica deve medir o fator de interesse independente de outros fatores . (6) Uma mtrica deve ser independente da linguagem de programao. As caractersticas citadas atendem a formulao, caracterizao e validao das mtricas, mas segundo Pressman (2005) a coleta e anlise so as atividades que guiam o processo de medio. Para direcionar a essas duas atividades, Roche (1994) sugere algumas diretrizes: (1) Sempre que possvel a coleta de dados e anlise devem ser auto- matizadas; (2) tcnicas estatsticas vlidas devem ser aplicadas para estabelecer relaes entre os atributos internos do produto e as caractersticas externas de qualidade; (3) deve- se garantir a independncia dos fatores utilizados na formulao da mtrica; (4) diretrizes e recomendaes interpretativas devem ser estabelecidas para cada mtrica; (5) mtricas exigem validaes de construo adequadas e deve seguir um mtodo cientco. 29 Em alguns casos, mtricas de software no satisfazem todos os atributos citados nesta seo, porm, no se deve rejeitar essas mtricas porque no atendem a um ou dois atributos, anal podem oferecer entendimento til e valor importante (PRESSMAN, 2005). Dessa forma, conclui-se que os conceitos apresentados direcionam a denio e anlise de mtricas de software, sendo na maioria das vezes atendidos pelas mtricas, mas a anlise de qualidade desta mtrica deve ser feita tambm a partir de sua aplicabilidade no mundo real e resultados gerados. O foco desta dissertao baseado em mtricas de produtos de software, mais es- pecicamente mtricas estticas, visto que as mtricas propostas tm por interesse prover resultados para ajudar na avaliao da refatorao de sistemas orientados por objetos para aspectos, com base no cdigo original fonte do sistema. Para isso foram utilizadas as teorias de mtricas estticas, pois avaliam o cdigo fonte diretamente, seus mtodos e atributos. Alm disso, as diretrizes propostas nesta seo sero utilizadas como guia para a proposta das mtricas, assim como fatores para a avaliao de sua ecincia. 2.4 Mtricas de Software Orientado por Objetos Os objetivos de uma mtrica de software no diferem conforme seu paradigma de programao, as mtricas de softwares convencionais tm o intuito de avaliar a qualidade, eccia e melhoria contnua do software (PRESSMAN, 2005). Ao se comparar as mtricas de softwares convencionais e softwares orientados por objetos, possvel assimilar algumas medidas que so comuns entre elas, por exemplo medida de tamanho e complexidade, porm como isso medido em cada tipo de software que difere as mtricas. Alm disso, h caractersticas que so medidas especcas para projetos orientados por objetos, as quais no se aplicam ou no esto presente nos demais paradigmas. Conforme Pressman (2005), softwares orientados por objetos so fundamental- mente diferentes de softwares desenvolvidos partir dos demais paradigmas de progra- mao, por essa razo, as mtricas devem ser ajustadas para atender a caractersticas dis- tintas como: (1) Localizao: em softwares convencionais esto em mtodos procedurais, em softwares orientados por objetos esto em classes ou objetos; (2) Encapsulamento: em softwares convencionais se encontram em sub-programas, funes, entre outros, em soft- wares orientados por objetos o encapsulamento envolve as responsabilidades de uma classe incluindo atributos e operaes; (3) Ocultao de Informaes: caracterstica presente so- mente em projetos orientados por objetos, onde possvel ocultar informaes dentro de uma classe que no sero acessadas pelos demais objetos do sistema; (4) Herana: em 30 geral herana no suportada por linguagens convencionais, na linguagem orientada por objetos porm, uma caracterstica fundamental; (5) Abstrao: caracterstica tambm predominante das linguagens orientadas por objetos. As mtricas podem ser especializadas no projeto, gerncia, em nvel de classes e testes do software orientado por objetos (PRESSMAN, 2005), porm o foco desta disser- tao a avaliao dos interesses transversais espalhados e entrelaados pelo sistema, sendo assim, o detalhamento de mtricas de software ser focado em mtricas especcas de classe. Os conjuntos de mtricas de classe mais amplamente referenciados, segundo Pressman (2005), so o conjunto de mtricas CK proposto por Chidamber e Kemerer (1994), o conjunto de mtricas MOOD proposto por Harrison, Counsell e Nithi (1998) e o conjunto de mtricas de Lorenz e Kidd denido por Lorenz e Kidd (1994). O conjunto de mtricas CK, so aplicadas nas classes e tm por objetivo avaliar ca- ractersticas fundamentais de sistemas orientados por objetos como complexidade, coeso e acoplamento (CHIDAMBER; KEMERER, 1994). A mtrica Weighted Methods per Class (WMC), ou mtodos ponderados por classe, do conjunto de mtricas CK, conta os mtodos e sua complexidade (CHIDAMBER; KE- MERER, 1994), obtendo o valor para a complexidade dos mtodos de um sistema, assim como uma medida de tamanho da classe (PRESSMAN, 2005). A mtrica Depth of the Inheritance Tree (DIT), ou tamanho da rvore de herana, mede o comprimento da rvore de herana da raiz at o n folha de maior tamanho. Pode-se considerar que, quanto maior o valor de DIT, maior ser a diculdade de prever o comportamento das classes herdeiras e maior ser complexidade do sistema (CHIDAMBER; KEMERER, 1994). A mtrica Number of Children (NOC), ou nmero de lhos, uma mtrica que conta o nmero de classes lhas que herdem imediatamente de uma determinada classe, ou seja, somente as classes lhas no nvel abaixo na hierarquia de classes. Essa mtrica tem o intuito de medir o grau de reutilizao de uma classe (CHIDAMBER; KEMERER, 1994). A medida de acoplamento de classes para um sistema, do conjunto de mtricas CK, feita a partir da mtrica Coupling Between Objet Classes (CBO), ou acoplamento entre as classes de objetos. A mtrica CBO avalia o acoplamento de uma classe, onde uma classe A est acoplada a uma classe B quando a classe A utiliza mtodos ou variveis da classe B (CHIDAMBER; KEMERER, 1994). 31 A mtrica Response For a Class (RFC), ou resposta de uma classe, mede a com- plexidade de uma classe, que aumenta proporcionalmente ao valor de RFC. A mtrica RFC conta o nmero de mtodos do conjunto resposta de uma classe, sendo que o con- junto resposta de uma classe um conjunto de mtodos que podem potencialmente ser executados em resposta a uma mensagem recebida por um objeto da classe (CHIDAMBER; KEMERER, 1994). Uma medida de coeso por sua vez feita com a mtrica Lack of Cohesion in Methods (LCOM), ou falta de coeso em mtodos. A mtrica LCOM avalia a similaridade entre mtodos de uma classe, onde similaridade entre dois mtodos o acesso aos mesmos atributos da classe. Quanto maior a similaridade entre mtodos maior ser a coeso da classe e menor ser o valor de LCOM (CHIDAMBER; KEMERER, 1994). As mtricas MOOD um conjunto de mtricas para sistemas orientados por objetos criado por Harrison, Counsell e Nithi (1998). Estas mtricas se baseiam nos mtodos e atributos da classe, e tm como objetivo principal medir a herana e acoplamento. O conjunto de mtricas MOOD mede o fator de acoplamento para mtodos e atri- butos de um sistema atravs da mtrica Coupling Factor (CF), ou fator de acoplamento. A mtrica CF calculada considerando todos os possveis conjuntos de pares de classes, isso feito combinando todas as possveis duplas de classes e vericando se esto rela- cionadas, esse relacionamento pode ser pela passagem de parmetros ou por referncia direta de um atributo ou mtodo de uma classe por outra (HARRISON; COUNSELL; NITHI, 1998). O clculo para herana de mtodos e atributos de uma classe feita por meio das mtricas Method Inheritance Factor (MIF), ou fator de herana de mtodos, e Attribute Inheritance Factor (AIF), ou fator de herana de atributos. Para o clculo de MIF, conta-se em todas as classes de um sistema, a quantidade de mtodos que so herdados. Esse total ser dividido pelo total de mtodos do sistema. Para clculo de AIF a regra semelhante a MIF, porm deve-se contar os atributos, no os mtodos de uma classe. As mtricas MIF e AIF denem um percentual de mtodos e atributos herdados no sistema (HARRISON; COUNSELL; NITHI, 1998; PRESSMAN, 2005). O conjunto de mtricas de Lorenz e Kidd foi proposto por Lorenz e Kidd (1994). Eles propuseram algumas mtricas baseadas em classes divididas entre as categorias: (1) tamanho: baseada na contagem de atributos e operaes da classe individualmente e na mdia para um valor do sistema como um todo; (2) herana: avaliao de como as operaes so reutilizadas atravs da hierarquia de classe; (3) caractersticas internas: 32 avaliao de coeso; e (4) caractersticas externas: acoplamento e reutilizao (PRESSMAN, 2005). Conforme Lorenz e Kidd (1994), o tamanho de uma classe medido a partir da mtrica Class Size (CS). Essa mtrica conta o nmero total de operaes e nmero de atributos que so encapsulados dentro de uma classe. Grandes valores de CS podem signicar que uma classe possui grande responsabilidade, o que pode ocasionar baixa reusabilidade, alta complexidade de implementao, manuteno e testes (PRESSMAN, 2005). A mtrica proposta por Lorenz e Kidd (1994) para a medida de herana da classe a mtrica Number of Operations Overridden by a Subclass (NOO), ou nmero de operaes substitudas por uma subclasse, ou seja, uma subclasse substitui uma operao herdada por uma especializao da operao. Altos valores de NOO podem indicar problema de modelagem, fraca hierarquia de classes e diculdade de manuteno e testes do software (PRESSMAN, 2005). A mtrica Number of Operations Added by a Subclass (NOA), ou nmero de ope- raes adicionadas por uma subclasse, mede a especializao de subclasses. calculada a partir do nmero de operaes privadas e atributos adicionados subclasse com o intuito de especializ-la (LORENZ; KIDD, 1994). Quando so identicados altos valores de NOA, pode signicar o afastamento da abstrao da superclasse (PRESSMAN, 2005). A mtrica Specialization Index (SI), ou ndice de especializao, uma mtrica para prover um ndice do grau de especializao das subclasses do sistema, ou seja, mede individualmente o valor de NOO de cada uma das subclasses. Para sua medida feito o clculo de NOO multiplicado pelo nvel da rvore hierrquica onde se encontra a subclasse, o resultado dividido pelo nmero total de mtodos da classe. Atravs das mtricas para software orientado por objetos apresentadas, possvel se obter uma medida direta de tamanho para um sistema a partir do clculo das mtricas WMC e CS por exemplo, outras calculam valores relacionados a herana de classes como DIT, NOC, MIF, AIF, NOO e NOA, assim como provem valores relacionados ao acopla- mento e coeso, entre outros clculos proporcionados pelas mtricas. A partir desses valores, pode-se obter respostas caractersticas que so relacionadas a outros fatores como por exemplo complexidade, diculdade de manuteno, testes e reutilizao. Como exemplo pode-se citar a medida de complexidade, que em geral no uma medida exata, caso um sistema apresente altos valores de WMC que conta o nmero de 33 mtodos e sua complexidade e altos valores para mtricas de herana de classes como por exemplo DIT e NOC pode-se presumir que o sistema apresenta alta complexidade, o que ocasionar diretamente diculdade de manuteno e testes. Outro exemplo o clculo de mtricas de acoplamento como CF e CBO, que, se apresentarem altos valores, repre- sentam um alto acoplamento no sistema que pode ocasionar diculdade de reutilizao e problemas na modelagem. Para se obter resultados renados em sistemas orientados por objetos necessria a avaliao de uma ou mais mtricas e uma anlise em conjunto de fatores que os ocasionem. 2.5 Mtricas de Software Orientado por Aspectos As mesmas mtricas que foram desenvolvidas para sistemas orientados por objetos, nem sempre podem ser aplicadas a sistemas orientados por aspectos, devido arquitetura e s necessidades de medio diferenciadas. Isso no quer dizer, porm, que as mtricas de software orientado por objetos no possam ser aplicadas, algumas at em sua forma original e outras sofrendo pequenas adaptaes, em sistemas orientados por aspectos. Alm disso, vm sendo propostas diversas mtricas especcas para medio de softwares orientados por aspectos, algumas delas so apresentadas nesta seo. No seu estudo sobre o reso e manuteno de softwares orientados por aspectos, SantAnna et al. (2003) denem um quadro para avaliar a reutilizao e manuteno de software atravs de um conjunto de mtricas e de um modelo de qualidade. As mtricas so centradas na separao de interesses e avaliao de demais atributos como acoplamento, coeso e tamanho. Neste estudo, SantAnna et al. (2003) propuseram os seguintes requisitos que uma mtrica adequada para software orientado por aspectos deve satisfazer: (1) medir atribu- tos de software conhecidos como separao de interesses, acoplamento, coeso e tamanho; (2) basear-se tanto quanto possvel em mtricas tradicionais e mtricas de software orien- tado por aspectos; (3) capturar diferentes dimenses de acoplamento e coeso de software orientada por aspectos; e (4) apoiar a identicao das vantagens e desvantagens na uti- lizao de aspectos em um projeto de software, quando comparado com uma soluo orientada por objetos para o mesmo problema. Baseado nesses princpios, o trabalho de SantAnna et al. (2003) propem algumas mtricas novas e adaptam mtricas tradicionais de software orientado por objetos para software orientado por aspectos. As mtricas propostas por SantAnna et al. (2003) para separao de interesses 34 so Concern Diusion over Operations (CDO), ou difuso de interesses sobre operaes, que se baseia na medida de operaes (mtodos e advices) e Concern Diusion over Components (CDC), ou difuso de interesses sobre componentes, que se baseia na medida de componentes (classes e aspectos). A mtrica CDO conta o nmero de operaes cuja nalidade principal contribuir para a implementao de um interesse e conta o nmero de mtodos e advices que os acessem por meio de chamadas de mtodos ou utilizando- os como parmetros formais, tipos de retorno, declaraes e variveis locais. A mtrica CDC, por sua vez, conta o nmero de componentes cujo objetivo principal contribuir para a implementao de um interesse e o nmero de classes e aspectos que os acessem. A partir de CDC e CDO, possvel desenhar um mapa de componentes (classes e aspectos) e operaes (mtodos, atributos e advices) que um interesse transversal inuencia no sistema como um todo. A mtrica Coupling Between Components (CBC), ou acoplamento entre compo- nentes (SANTANNA et al., 2003), foi derivada da mtrica CBO do conjunto de mtricas CK (CHIDAMBER; KEMERER, 1994). O clculo de CBC feito vericando-se o acoplamento entre componentes, sendo que um componente (classe ou aspecto) A est acoplado a outro componente (classe ou aspecto) B se A utiliza mtodos, advices ou atributos de B. Essa mtrica foi adaptada para medir todas as variaes de acoplamento possveis em sistemas orientados por aspectos (SANTANNA et al., 2003). Outra mtrica de acoplamento derivada das mtricas CK a mtrica Depth of Inheritance Tree (DIT), que mede o comprimento mximo de um n para a raiz da rvore, contando quo baixo a hierarquia de herana de uma classe ou aspecto declarada. A partir da medida do tamanho da rvore de herana do sistema, medido o acoplamento e a complexidade do sistema. A mtrica LCOM, do conjunto de mtricas CK (CHIDAMBER; KEMERER, 1994), foi estendida por SantAnna et al. (2003) para utilizao em sistemas orientados por aspectos, resultou na mtrica Lack of Cohesion in Operations (LCOO), e prope uma medida similar a LCOM, a medida de falta de coeso entre operaes (mtodos e advices) do aspecto. Quanto maior o valor de LCOO, menor ser a coeso. Dessa forma, quanto mais altos valores de LCOO, maior ser a diculdade para reutilizao e manuteno. A mtrica Weighted Operations per Component (WOC), ou operaes ponderadas por componente, estende a mtrica WMC do conjunto de mtricas CK (CHIDAMBER; KEMERER, 1994). Semelhante a WMC, WOC conta os mtodos e advices e sua comple- xidade para os aspectos do sistema. Consequentemente, altos valores de WOC signicam maior complexidade do sistema. 35 Em outro estudo, Garcia et al. (2005) denem a mtrica Concern Lines of Code (CLC), ou linhas de cdigo do interesse, que tem por objetivo medir as linhas de cdigo de um determinado interesse no cdigo fonte orientado por aspectos e orientado por objetos. A mtrica CLC conta o nmero de linhas de cdigo cujo objetivo principal contribuir para a implementao de um interesse, mas desconsiderando comentrios, linhas em branco e chamadas de import. Na verso orientada por objetos, CLC conta a chamada de mtodos que contm os interesses transversais em questo. Na verso orientada por aspectos, porm, a contagem do aspecto criado para implementar o interesse transversal, incluindo a descrio do pointcut, a assinatura, advice e o cdigo de implementao do interesse. No trabalho de Ceccato e Tonella (2004), foi apresentado um estudo onde as mtri- cas CK foram renadas para que essas sejam utilizadas em sistemas orientados por aspec- tos. Conforme o estudo, algumas mtricas do conjunto de mtricas CK podem facilmente ser adaptadas para utilizao em sistemas orientados por aspectos, por exemplo, adap- tando as medidas das mtricas de classes e mtodos para aspectos e advices. Outras porm, precisam de um maior renamento, por exemplo a mtrica CBO, que mede o acoplamento, foi renada em 2 mtricas orientadas por aspectos. Outras duas novas mtricas de acoplamento foram criadas para atender a todas as formas de acoplamento com aspectos e uma nova mtrica foi proposta para medir o grau de transversalidade de um aspecto. A mtrica DIT, que mede a complexidade de uma classe a partir da medida do tamanho da sua rvore hierrquica, foi renada para considerar tambm aspectos que possam impactar na hierarquia desta classe por meio de chamadas de inter-tipos, con- siderando os aspectos tambm quando o clculo de DIT feito (CECCATO; TONELLA, 2004). No seu estudo, SantAnna et al. (2003) tambm criaram uma variao da mtrica DIT para medio de software orientado por aspectos. A diferena destas duas mtricas que a mtrica DIT proposta por SantAnna et al. (2003), mede onde o aspecto se encon- tra na rvore de herana, enquanto a mtrica DIT de Ceccato e Tonella (2004), prope a medida de possveis alteraes na rvore hierrquica atravs de inter-tipos. A mtrica RFC do conjunto de mtricas CK (CHIDAMBER; KEMERER, 1994), tam- bm foi renada para sistemas orientados por aspectos por meio da mtrica Response For a Module (RFM), ou resposta de um mdulo. Similar mtrica RFC, a mtrica RFM mede o nmero de mtodos e advices que potencialmente sero executados como resposta de um mdulo (CECCATO; TONELLA, 2004). 36 A mtrica CBO foi renada em duas novas mtricas, Coupling on Method Call (CMC), ou acoplamento em chamadas de mtodos, e Coupling on Field Access (CFA), ou acoplamento em acesso a atributos. A mtrica CMC conta o nmero de mdulos ou interfaces que declarem mtodos que possam ser interceptados por aspectos, e CFA considera os atributos ao invs de mtodos (CECCATO; TONELLA, 2004). Duas novas mtricas de acoplamento foram denidas, Coupling on Advice Execu- tion (CAE), ou acoplamento na execuo de advice, e Coupling on Intercepted Modules (CIM), ou acoplamento na interceptao de mdulos. A mtrica CAE conta o nmero de aspectos que contm advices que possivelmente sero chamados por execues do sis- tema, CIM por sua vez conta o nmero de mdulos e interfaces que esto explicitamente declarados nos pointcuts para serem interceptados (CECCATO; TONELLA, 2004). A mtrica Crosscutting Degree of an Aspect (CDA), ou grau de transversalidade de um aspecto, conta o nmero de mdulos afetados pelos pointcuts e pela introduo de um determinado aspecto (CECCATO; TONELLA, 2004). A partir da medida de CDA pode-se estimar o impacto global que tem um aspecto sobre os outros mdulos. Foram propostas duas novas mtricas de separao de interesses para sistemas orientados por aspectos por Eaddy et al. (2008), (1) Degree of Scattering Across Classes (DOSC), ou grau de disperso entre classes, e (2) Degree of Scattering Across Methods (DOSM), ou grau de disperso entre mtodos. A mtrica DOSC calcula o grau em que o cdigo do interesse est distribudo entre as classes. Quando o valor de DOSC igual a 0 (zero) todo o cdigo est em uma classe, quando o valor igual a 1 (um) o cdigo dividido igualmente entre todas as classes. A mtrica DOSM calcula o grau em que o cdigo do interesse distribudo atravs de mtodos, varia de 0-1, semelhante ao DOSC. Outro estudo feito para propor mtricas para sistemas orientados por aspectos foi feito por Apel (2010). Neste trabalho foram propostas cinco mtricas para tratar aspectos divididos pelos seguintes grupos: homogneo e heterogneo, esttico e dinmico, e bsico e avanado. A mtrica Classes, Interfaces, and Aspects (CIA) conta as classes, interfaces e aspectos de um programa. Pode ser utilizada para avaliar se um aspecto implementa uma parte signicante de um sistema. Quanto maior a quantidade de aspectos, maior ser considerada sua importncia no sistema. A m de denir quais interesses so homogneos ou heterogneos, Apel (2010) prope a mtrica Heterogeneous and Homogeneous Crosscuts (HHC), ou transversalidade 37 heterognea e homognea. Com HHC, feita uma anlise de cada parte de um advice e declarao inter-tipo, se o nmero de join points que ele impacta for maior que 1 (um) ento considerado homogneo, caso contrrio, ele heterogneo. A mtrica Code Replication Reduction (CRR), ou reduo de replicao de cdigo, tem por interesse quanticar o benefcio da reduo do nmero de linhas de cdigo (APEL, 2010). A mtrica CRR conta o nmero de linhas de cdigo que podem ser reduzidos por meio da implementao de aspectos. Para o seu clculo feita a multiplicao do nmero de linhas dos advices homogneos e declaraes de inter-tipos pelo nmero de join points afetados (menos um). Esse valor denido para todo o sistema e medido no cdigo fonte orientado por objetos, calculando dessa forma a quantidade de linhas que sero reduzidas por meio de aspectos. A mtrica Static and Dynamic Crosscuts (SDC), ou interesses dinmicos e estti- cos, conta o nmero de linhas de cdigo, ou Lines of Code (LOC), de declaraes de inter-tipos e advices. Esse total comparado com o nmero de linhas do cdigo fonte original (APEL, 2010). A mtrica SDC mostra at que ponto aspectos estendem o cdigo dinmico do programa, o que no pode ser bem expresso em linguagens orientadas por objetos. Para denir um interesse bsico ou avanado, Apel (2010) prope a mtrica Basic and Advanced Dynamic Crosscuts (BAC), ou interesses dinmicos bsicos ou avanados. A mtrica BAC avalia as linhas de cdigo associadas a partes de um advice bsico ou avanado. Foi considerado um advice avanado se o pointcut envolve mais do que sim- plesmente uma combinao de execuo (ou call) e argumentos. Em seu trabalho, SantAnna et al. (2003) propem duas mtricas de separao de interesses, CDO e CDC. Essas provem informaes importantes para modularizao dos interesses transversais, possibilitando o mapeamento de classes, aspectos, mtodos, atributos e advices que um interesse transversal impacta. Nesse trabalho o clculo das mtricas foi feito em projetos j refatorados para aspectos, mas sua aplicao tambm pode ser feita em sistemas orientados por objetos puramente, porm avaliando somente classes, mtodos e atributos, que pode traar um mapeamento da importncia do interesse antes de sua refatorao para aspectos. Nos trabalhos de SantAnna et al. (2003) e Ceccato e Tonella (2004), foram es- tendidas algumas mtricas CK para sistemas orientados por aspectos. No contexto do trabalho de SantAnna et al. (2003), que visa a reutilizao e manuteno de sistemas orientados por aspectos, aplicar essas mtricas em cdigo j refatorados para aspectos 38 justicvel. Porm, vale ressaltar que as mtricas propostas provem informaes de tamanho, acoplamento, coeso e complexidade de sistemas orientados por aspectos, os quais seriam interessantes de se obter previamente refatorao para aspectos de um sistema, pois so fatores de deciso importantes. A mtrica CDA, proposta por Ceccato e Tonella (2004), informa o nmero de mdulos afetados por um aspecto. Em outro trabalho, Apel (2010) prope as mtricas HHC, SDC e CRR. A mtrica HHC dene interesses homogneos e heterogneos (embora seu conceito de homogeneidade seja diferente do conceito utilizado nesta dissertao), a mtrica SDC mostra at que ponto aspectos estendem o cdigo dinmico do programa, e a mtrica CRR calcula a reduo de replicao de cdigo. Essas mtricas provem uma avaliao da importncia e o impacto de um aspecto para o sistema, mas nos estudos apresentados foram aplicadas a sistemas j na verso orientada por aspectos. As mtricas DOSC e DOSM, propostas por Eaddy et al. (2008), calculam o grau em que o cdigo do interesse est distribudo entre classes e mtodos. Essas mtricas so importantes pois podem ser utilizadas em um sistema que ainda no foi migrado para aspectos, possibilitando uma avaliao do espalhamento dos interesses transversais para uma possvel deciso de refatorao, diferente da maioria das mtricas para avaliao de sistemas orientados por aspectos. Esses valores vinculados a informaes de reduo de cdigo, de acoplamento, coeso e complexidade, caso estejam disponveis para sistemas ainda na verso orientada por objetos, podem prover informaes relevantes para a deciso da refatorao, ou no, de um sistema para aspectos. 2.6 Avaliaes em Projetos Orientados por Aspectos As mtricas para sistemas orientados por aspectos apresentadas na seo anterior possibilitam a avaliao de atributos especcos em um projeto de software. Nesta seo, sero apresentados alguns trabalhos de avaliao de sistemas orientados por aspectos, os quais realizaram medies de atributos, tais como, tamanho, coeso, acoplamento, complexidade e quanticao. Esses atributos so medidos normalmente por meio da aplicao de mtricas de software, em sua maioria, em sistemas j refatorados para as- pectos. As avaliaes podem ser feitas ainda, a partir da comparao da implementao de um determinado interesse, implementado no cdigo orientado por objetos e tambm no cdigo orientado por aspectos. No trabalho de Filman e Friedman (2005), feita uma avaliao para determinar 39 caractersticas distintivas de sistemas passveis de refatorao para aspectos. A concluso neste trabalho que a quanticao um fator importante para a caracterizao de um sistema "aspectizvel". Um interesse quanticvel quando sua declarao tem efeitos em diversos locais do sistema, ou seja, um nmero grande de join points. A partir dessa avaliao, Filman e Friedman (2005) concluem que um sistema com interesses transver- sais amplamente quanticveis apresenta uma caracterstica positiva para a deciso de refatorao para aspectos. Usando as mtricas de separao das interesses, acoplamento, coeso e tamanho, mtricas essas que foram criadas ou adaptadas das mtricas CK para sistemas orientados por aspectos, SantAnna et al. (2003) tm investigado o uso de aspectos em uma ampla variedade de domnios e sistemas, incluindo padres de projeto (GARCIA et al., 2005), manipulao de excees (FILHO et al., 2006), sistemas de informao baseados na Web (KULESZA et al., 2006) e linhas de produto de software (FIGUEIREDO et al., 2008). Em outro estudo, Garcia et al. (2005) utilizaram as mtricas denidas por SantAnna et al. (2003) para avaliar a implementao de padres de projeto por meio de aspectos. Foi observado que na maioria dos padres houve vantagem na utilizao de aspectos para modularizar os interesses transversais, porm alguns padres apresentaram maior acopla- mento, complexidade e tamanho que as solues orientadas por objetos. Em seu estudo sobre manipulao de excees, Filho et al. (2006) zeram uma ava- liao da utilizao de aspectos para modularizao de excees e concluiu que eciente quando se trata de excees homogneas, ou seja, quando um ou poucos advices atingem todos os join points. Porm, quando se trata de excees heterogneas e dependentes do contexto do sistema, podem causar mais danos do que benefcios, pois, pode tornar o cdigo mais complexo e os interesses frgeis. No estudo de Kulesza et al. (2006), foi apresentada a implementao de um sistema de informao web utilizando aspectos e sua comparao com uma implementao somente orientada por objetos. Constatou-se na verso orientada por aspectos uma diminuio da coeso e aumento de operaes e componentes, ou seja, baixa quanticao. Porm, no sis- tema em geral, a implementao orientada por aspectos apresentou superioridade quanto a linhas de cdigo, separao de interesses, baixo acoplamento e menor complexidade. No trabalo de Figueiredo et al. (2008), foi apresentado um estudo baseado em linhas de produtos utilizando-se de aspectos. Nesse trabalho foram desenvolvidos dois exemplos de linhas de produto utilizando-se aspectos com o intuito de avaliar caractersticas como modularidade, estabilidade, manutenabilidade e acoplamento. Foi constatado que, com 40 a utilizao de aspectos, houve um aumento dessas caractersticas, porm apresentou diculdade para introduo de novas implementaes, o que uma caracterstica forte em projetos de linhas de produto. As experincias na refatorao de features da Oracle Berkeley DB com aspectos foram relatadas por Kastner, Apel e Batory (2007). Neste trabalho observou-se que os elementos extrados, em geral, apresentam um pequeno grau de quanticao, ou seja, nmero reduzido de advices que podem afetar mais de um ponto de execuo (join point). Por exemplo, a partir de 482 advices extrados apenas 7 afetam mais de um ponto comum. Alm disso, a maioria dos pointcuts denidos esto intimamente ligados ao programa de base e, portanto, so especialmente frgeis para modicaes no programa, pois, alteraes no programa base afetaro os advices e podem ocasionar erros. No trabalho de Apel (2010) foi apresentada uma anlise do uso de AspectJ em onze sistemas, usando as mtricas CIA, HHC, CRR, SDC e BAC. O estudo mostrou que 86% do cdigo considerado orientada por objetos, 12% utiliza mecanismos de base trans- versal (declaraes inter-tipos ou extenses de um mtodo nico), e apenas 2% utilizam mecanismos transversais avanados (incluindo advices que afetam conjuntos inteiros de join points). Uma vez que na maioria dos sistemas avaliados, AspectJ foi usado para extrair caractersticas heterogneas a partir do cdigo fonte, os resultados reforam as concluses derivadas da refatorao de Oracle Berkeley DB (KASTNER; APEL; BATORY, 2007). Em geral, em cada um desses estudos empricos foram identicados efeitos positivos e negativos da utilizao de aspectos. Na maioria dos estudos, as situaes em que eles no recomendam o uso de aspectos podem estar ligadas a um reduzido grau de quanticao, onde h o aumento de linhas de cdigo e de componentes. Os trabalhos apresentados exemplicam as avaliaes de sistemas orientados por aspectos. Observa-se que, para que as avaliaes apresentadas fossem feitas, foi necessrio a refatorao dos sistemas para aspectos. Isso implica em custo e tempo, podendo, caso observe-se que no interessante a utilizao de aspectos, signicar prejuzo para o pro- jeto. A incerteza do resultado da refatorao pode ser considerado um limitador para a utilizao de programao orientada por aspectos comercialmente. Caso seja possvel essa avaliao previamente refatorao para aspectos, a utilizao de aspectos seria mais segura e possivelmente mais disseminada. 41 2.7 Ferramentas de Automao de Clculo de Mtricas Conforme relatado na Seo 2.3, em um processo de medio a coleta de dados e anlise devem ser, preferencialmente, automatizados (ROCHE, 1994). Na medio em pro- jetos de software normalmente so criadas ferramentas para automatizar parte ou todo o processo do clculo de mtricas, conforme sero relatados alguns exemplos nesta seo. As ferramentas que sero apresentados foram selecionadas por apresentarem automatizao de mtricas de software para avaliao de interesses transversais. A ferramenta ConcernMapper 1 utilizada como uma ferramenta de apoio para coleta de dados. Foi desenvolvida por Robillard e Weigand-Warr (2005) com duas pro- postas distintas. A primeira delas criar uma ferramenta para tcnicas avanadas para a separao de interesses; a segunda disponibilizar uma plataforma para criar, armazenar e consultar mapas de concerns para atender a diferentes abordagens. A ferramenta ConcernMapper apoia o desenvolvimento e as tarefas de manuteno de software que envolvam interesses espalhados pelo sistema. Permite aos desenvolvedores organizar e visualizar o cdigo de um projeto vinculado a uma abstrao de alto nvel, permitindo uma viso modularizada dos interesses transversais de um sistema sem que ele sofra qualquer tipo de alterao estrutural. Figura 3: Concern Maps da ferramenta ConcernMapper. Atravs da ferramenta ConcernMapper possvel organizar atributos e mtodos correspondentes a interesses transversais em uma estrutura em forma de rvore, deno- minada Concern Maps, conforme ilustrado na Figura 2.7. A ferramenta ConcernMapper permite montar a rvore de concerns, o qual uma estrutura visual, semelhante por exem- plo ao Package Explorer da plataforma Eclipse 2 . Para isso, basta selecionar o interesse no 1 http://www.cs.mcgill.ca/ martin/cm/ 2 http://www.eclipse.org 42 Package Explorer e arrast-lo at o concern no Concern Maps, solt-lo e ele ser automati- camente includo na rvore de concerns. Atualmente a ferramenta ConcernMapper est disponvel em forma de plugin do Eclipse e estendida para criao de outras ferramentas, inclusive a ferramenta ConcernMetrics que foi desenvolvida nesta dissertao. A ferramenta ConcernTagger 3 uma ferramenta desenvolvida a partir da exten- so de ConcernMapper. A ferramenta ConcernTagger foi desenvolvida para automatizar as mtricas de software orientado por aspectos, incluindo CDC, CDO, DOSC e DOSM, propostas por Eaddy et al. (2008). Permite ao usurio criar uma hierarquia de concerns e associar aos mesmos requisitos, cdigo fonte e bugs, atravs da interface de Concern- Mapper e obter o resultado dos clculos das mtricas. Essas mtricas so calculadas com base no cdigo fonte orientado por objetos. A ferramenta ConcernMorph uma ferramenta para automatizao de clculo de mtricas de software. A ferramenta implementa diversas mtricas, entre elas a mtrica de separao de interesses CDC (SANTANNA et al., 2003) e as mtricas NOA e NOO que contam, respectivamente, o nmero de atributos e operaes de um sistema (KICZALES et al., 1997). Atravs de ConcernMorph possvel a identicao de interesses transversais e a classicao destes em uma srie de padres transversais pr-denidos atravs da apli- cao de mtricas de software. Esses padres foram baseados no projeto de Figueiredo, Whittle e Garcia (2009), onde denido um grupo de 12 padres transversais para quali- cao de interesses transversais. A ferramenta ConcernMorph possui a funcionalidade de identicao de padres transversais com base em mtricas coletadas diretamente a partir do cdigo orientado por objetos, sua interface estendida da ferramenta ConcernMapper para montagem da rvore de concerns. Figura 4: Ferramenta ConcernMorph (FIGUEIREDO; WHITTLE; GARCIA, 2009). 3 http://www.cs.columbia.edu/eaddy/concerntagger 43 A Figura 4 apresenta duas vises da ferramenta ConcernMorph: Mtricas (Viso A) e Padres Transversais (Viso B), onde so mostrados respectivamente o clculo das mtricas e as instncias dos padres transversais encontrados. 2.8 Consideraes Finais Neste captulo, foi apresentada uma reviso da literatura diretamente relacionada ao desenvolvimento desta dissertao. A reviso apresentada incluiu conceitos bsicos sobre o paradigma de programao orientada por aspectos e AspectJ, que uma linguagem para implementar aspectos em Java. Foram apresentados conceitos de medio e mtricas de software, mtricas para projetos orientados por objetos e orientados por aspectos. Foram apresentadas ainda ferramentas de automao de clculo de mtricas de software. A partir da anlise dos trabalhos apresentados, nota-se que ainda no feita uma larga utilizao de medio em sistemas orientados por objetos, e ainda em menor escala em projetos orientados por aspectos. Pode-se talvez justicar essa menor utilizao em projetos orientados por aspectos pela caractersticas das mtricas apresentadas, que, para analisar o projeto, normalmente h a necessidade da refatorao do cdigo fonte base para aspectos, o que despende um grande esforo e custo. Foi vericado tambm uma quantidade limitada de ferramentas para automatizar os clculos de mtricas, visto que esses clculos so trabalhosos e tediosos, o que pode ocasionar uma maior abertura a erros na sua aplicao manual. 44 3 MTRICAS PARA AVALIAO DO GRAU DE QUANTIFICAO Neste captulo, sero apresentados alguns estudos de quanticao em sistemas orientados por aspectos e a proposta de duas novas mtricas de software. Como validao da proposta desta dissertao, ser exposto um estudo sobre uma anlise quantitativa utilizando-se mtricas de separao de interesse j amplamente utilizadas em sistemas orientados por aspectos. Essas mtricas sero aplicadas em sistemas nas verses orientadas por objetos e verses refatoradas para aspectos, a partir do resultado da aplicao das mtricas para cada verso, esses sero comparados quantitativamente. Ser apresentada a proposta de uma mtrica para medir o grau de quanticao de um interesse transversal em um sistema, a mtrica Quantication Degree (QD), e uma submtrica para medir a reduo do espalhamento caso os interesses venham a ser modularizados atravs de aspectos, a mtrica Scattering Reduction (SR). Sero apresentados ainda alguns exemplos da aplicao das mtricas e a anlise de cada aplicao. Na Seo 3.1, sero apresentadas avaliaes quantitativas de mtricas convencionais de separao de interesses nos sistemas JSpider e JAccounting. Na Seo 3.2 sero apre- sentadas as denies do Modelo de Concerns proposto e a formalizao das mtricas QD e SR. Na Seo 3.3 sero expostos exemplos da aplicao das mtricas propostas em exemplos da aplicao das mtricas em sistemas hipotticos. Na Seo 3.4, por m, sero apresentadas as consideraes nais. 3.1 Avaliaes Quantitativas Ser apresentada nesta seo uma avaliao dos sistemas JAccounting 1 e JSpider 2 j refatorados para aspectos. Ambos os sistemas possuem cdigo aberto, verses orien- tadas por objetos e tambm verses orientadas por aspectos que foram desenvolvidas por Binkley et al. (2006), com o intuito de ilustrar a utilizao de aspectos para modularizar interesses transversais. 1 http://jaccounting.dev.java.net 2 http://j-spider.sourceforge.net 45 Os aspectos implementados nos sistemas mencionados fazem usos opostos de quan- ticao. Por exemplo em JAccounting, declaraes quanticadas so amplamente uti- lizadas a m de modularizar o interesse de controle de transaes, por outro lado, a refatorao da preocupao de log de JSpider faz o uso mnimo de quanticao. Inicial- mente ser ilustrado o uso de aspectos para modularizao de requisitos transversais, em seguida ser apresentada uma avaliao feita nos sistemas JAccounting e JSpider das van- tagens da quanticao atravs da anlise da aplicao manual das mtricas de separao de interesses transversais CDC e CDO (SANTANNA et al., 2003). Para a avaliao quantitativa apresentada nesta seo, os projetos JAccounting e JSpider foram selecionados por apresentarem um histrico de utilizao em avaliaes de refatorao para aspectos (MALTA; OLIVEIRA; VALENTE, 2009; MALTA; VALENTE, 2009). Alm disso, esses sistemas possuem verses orientadas por objetos e verses orientadas por aspectos (BINKLEY et al., 2006), o que possibilita a comparao quantitativa do resultado das mtricas aplicadas em ambas as verses. No trabalho de Binkley et al. (2006), os sistemas JAccounting e JSpider foram selecionados para serem os estudos de caso na aplicao de sua proposta de passos para refatorao de projetos orientados por objetos e de sua ferramenta de automatizao desse processo chamada AOP-Migrator. Nos trabalhos Malta, Oliveira e Valente (2009) e Malta e Valente (2009), so apresentadas propostas de transformaes de cdigo para extrao de interesses transversais por meio de aspectos. Esses trabalhos utilizam os sistemas JAccounting e JSpider como estudos de caso, propondo modicaes no cdigo para a melhor refatorao possvel dos respectivos interesses transversais transaction e logging. No estudo de Ceccato (2008), os sistemas JAccounting e JSpider tambm so utilizados para validao de seu trabalho sobre identicao e transformao de cdigo para refatorao de interesses transversais para aspectos. O sistema JAccounting um sistema web contbil de mdio porte e tem como principais processos a automatizao de faturamento e controle de contas (BINKLEY et al., 2006). O interesse transversal selecionado no trabalho de Binkley et al. (2006), para exemplo de refatorao em JAccounting, foi o controle de transaes transaction. Esse interesse se encontra espalhado pelo sistema em 44 pontos de juno e sua implementao est entrelaada aos interesses funcionais do sistema. O interesse transversal transaction o controle de transaes que deve ser feito a cada acesso ao banco de dados, conforme exemplo na Figura 5. Ao iniciar o acesso deve ser chamado o mtodo beginTransaction() (linha 01), no m o mtodo commit() (linha 12), e, caso ocorra alguma exceo, o mtodo 46 rollback() (linha 07) chamado. 01: tx= sess.beginTransaction(); // starts a transaction 02: try { 03: ... // database operations 04: } 05: catch (...) { // handles database exceptions 06: if (tx != null) { 07: tx.rollback(); // performs a rollback 08: tx= null; 09: } 10: } 11: finally { 12: if (tx != null) tx.commit(); // commits 13: } Figura 5: Chamada do interesse transversal transaction de JAccounting. O sistema JAccounting apresenta um alto grau de quanticao do interesse trans- versal transaction, ou seja, foi possvel fazer a modularizao do interesse transversal atravs de um nmero reduzido de advices e que atenda a todos os join points. Isso porque o interesse transversal transaction apresenta um comportamento homogneo, ou seja, suas chamadas so idnticas (MALTA; OLIVEIRA; VALENTE, 2009; MALTA; VALENTE, 2009). A partir dessa avaliao, constatou-se que as 44 chamadas do interesse transac- tion foram modularizadas em um nico aspecto e em trs advices, conforme mostrado na Figura 6, atravs dos advices p0 (linha 04), p1 (linha 08) e p2 (linha 14). Avaliando quantitativamente, esse resultado pode ser considerado um bom exemplo do benefcio da quanticao. O sistema JSpider, por sua vez, um sistema de mdio porte que funciona como um rob que permite recuperar e validar pginas Web. Na verso orientada por objetos desse sistema, logging um interesse transversal, estando sua implementao espalhada e entrelaada por diversas classes, exemplos de chamadas do interesse so mostrados na Figura 7. Na verso orientada por aspectos, implementada em AspectJ, o cdigo de logging foi devidamente modularizado por meio de aspectos. H porm casos que os interesses transversais no so homogneos, como por exem- plo as chamadas do mtodo info() mostrado na Figura 7, que implementam o interesse transversal logging do sistema JSpider. As chamadas de info() no so homogneas pois apresentam variaes nos parmetros, embora sejam chamadas do mesmo mtodo. Outros mtodos que implementam o interesse logging de JSpider apresentam essa 47 01: aspect TransactionManagement { 02: ... 03: // pointcut p0 captures when database sessions must be opened 04: after(): p0() { 05: tx = sess.beginTransaction(); 06: } 07: // pointcut p1 captures when database exceptions must be handled 08: before(): p1() { 09: if (tx != null) { 10: tx.rollback(); tx= null; 11: } 12: } 13: // pointcut p2 captures when database sessions must be closed 14: before(): p2() { 15: if (tx != null) tx.commit(); 16: } 17: } Figura 6: Aspecto com modularizao do interesse transaction em JAccounting. 01: log.info("Loading " + pluginCount + " plugins."); 02: ... 03: log.info("Loading plugin configuration " + pluginInstance + "..."); 04: ... 05: log.info("Plugin class ... not found"); 06: ..... 07: log.info("Plugin uses local event filtering"); 08: ... 09: log.info("Plugin not configured for local event filtering"); 10: ... 11: log.info("Plugin Name : " + plugin.getName()); Figura 7: Chamada do interesse transversal Logging de JSpider. mesma caracterstica, interesses heterogneos. Dessa forma no possvel em JSpider modularizar o interesse transversal logging em um nico, ou mesmo em poucos, advices, sendo necessrio criar um advice para atender a cada variao de passagem de parmetro dos mtodos que implementam o interesse logging. No sistema JSpider foram necessrios 176 advices para modularizar as 190 chamadas do interesse. Esse um exemplo de um grau de quanticao baixo, onde os advices atingem poucos join points. Os sistemas JAccounting e JSpider apresentam caractersticas de modularizao dos interesses transversais distintas. Os interesses do sistema JAccounting apresentam uma caracterstica homognea, enquanto no sistema JSpider os interesses transversais 48 apresentam caractersticas heterogneas. Esses dois projetos, em conjunto, apresentam caractersticas que devem ser examinadas durante o processo de migrao de sistemas para aspectos e possibilitam uma avaliao eciente das propostas desta dissertao. Para o desenvolvimento da anlise quantitativa nos sistemas JAccounting e JSpi- der, foram aplicadas manualmente mtricas de separao de interesses e feita uma anlise da comparao dos resultados das mtricas. Na Tabela 1 so apresentadas informaes relevantes dos sistemas j na verso orientada por aspectos, como nmero de aspectos, join point shadows (JPS) e advices. JAccounting JSpider Aspects 1 1 JPS 44 190 Advices 3 176 Tabela 1: Informaes sobre verso orientada por aspectos dos sistemas JAccounting e JSpider. Uma das mtricas aplicadas foi a CLC, que conta o nmero de linhas de cdigo que implementam um determinado interesse (GARCIA et al., 2005). No sistema JAccounting, o valor de CLC na verso orientada por objetos 105, aps sua refatorao para aspectos o valor de CLC foi reduzido para 72, ou seja, reduziu o nmero de linhas que implementam o interesse em 32%. Isso se justica pela modularizao do interesse transaction em um nico aspecto e em somente trs advices, pois seus interesses so homogneos em todo o sistema. No sistema JSpider o valor de CLC na verso orientada por objetos de 244, na verso refatorada para aspectos aumentou para 2400, havendo um aumento de 884% no valor da mtrica. Basicamente, essa diferena pode ser explicada pelo nmero signicativo de linhas extras necessrias para implementar os aspectos para atender s variaes do interesse logging. Como exemplo, na Figura 8, para modularizar uma nica chamada de error() (linha 6), seis linhas extras de cdigo foram utilizadas: quatro linhas para declarar o pointcut (linhas 1-4) e duas linhas que delimitam o corpo do advice (linha 5 e linha 7). A mtrica CDO tambm foi utilizada para avaliao dos sistemas JAccounting e JSpider. A mtrica CDO conta o nmero de mtodos e advices que contribuem para a implementao de um interesse transversal e outros mtodos e advices que os acessam. Outra mtrica aplicada foi a mtrica CDC, que semelhante mtrica CDO, porm em CDC contado o nmero de classes, no de mtodos, que contribuem na implementao 49 1: pointcut p_27(DBUtil _this, SQLException e ): 2: this(_this) 3: && execution(void DBUtil.sqlException(SQLException)) 4: && args(e); 5: before(DBUtil _this, SQLException e): p_27(_this, e) { 6: _this.log.error("SQL Exception during JDBC Connect", e); 7: } Figura 8: Exemplo da descrio do pointcut e implementao do advice em JSpider de um interesse e outras classes e aspectos que acessam as mesmas. Ao aplicar a mtrica CDO em JAccounting foi obtido o valor 11 para a verso orientada por objetos e o valor 7 para a verso orientada por aspectos. Atravs da refatorao para aspectos foi obtida uma reduo de 36% no valor de CDO, ou seja, houve a reduo de 36% da quantidade de mtodos ou advices que implementam ou acessam o interesse transaction. Em JSpider, porm, foi observado um aumento signicativo do valor de CDO em 125%, sendo o valor na verso orientada por objetos foi igual a 108, enquanto que na verso refatorada para aspectos aumentou para 243. Esse aumento resultado do baixo grau de quanticao dos interesses de JSpider, isso porque, em sua maioria, uma chamada de logging movida para um advice, apenas movendo a chamada de lugar no sistema de um mtodo para dentro de um aspecto. Um outro fator que no sistema JSpider, na verso orientada por objetos, s vezes um nico mtodo tem diversas chamadas de mtodos que implementam o interesse logging, neste caso contado somente uma vez. Na verso orientada por aspectos porm, as chamadas so implementadas em advices diferentes, aumentando conseqentemente o valor de CDO, pois cada um desses advices contado separadamente. A aplicao da mtrica CDC no sistema JAccounting obteve o valor 10 na verso orientada por objetos e o valor 3 para a verso orientada por aspectos, diminuindo assim o valor de CDC em 70%. Semelhantes ao sistema JAccounting, o sistema JSpider tambm teve uma reduo signicativa, diminuiu o valor de CDC em 91%, passando o valor de CDC da verso orientada por objetos de 39 para 3 da verso refatorada para aspectos. A reduo no valor de CDC para ambos os sistemas ocorreu, porque para a imple- mentao de advices, necessrio apenas um aspecto, sendo que quando se utiliza mais de um por deciso dos desenvolvedores, dessa forma diminuindo a quantidade de com- 50 ponentes que implementam e acessam determinado interesse. Os resultados da aplicao das mtricas CLC, CDO e CDC em JAccounting e JSpider so apresentados na Tabela 2. Mtricas JAccounting JSpider OO OA % OO OA % CLC 105 72 -32% 244 2400 +884% CDO 11 7 -36% 108 243 +125% CDC 10 3 -70% 39 3 -92% Tabela 2: Resultado da aplicao das mtricas CLC, CDO e CDC na verso orientada por objetos e orientada por aspectos dos sistemas JAccounting e JSpider. A partir da avaliao quantitativa dos exemplos apresentados, pode-se presumir que quanto maior a quanticao de um determinado interesse, menor ser o nmero de linhas de cdigo necessrias para implement-lo (CLC), tambm contribui para reduzir o nmero de advices necessrios para atender a todos os join points (CDO), no impacta diretamente na reduo do nmero de aspectos necessrios no processo de refatorao de um determinado sistema (CDC), porm com a reduo da quantidade de advices conse- quentemente o tamanho de tais aspectos diminui. 3.2 Denies das Mtricas de Avaliao do Grau de Quanticao Nesta seo ser apresentada a proposta da mtrica de quanticao, Quantica- tion Degree (QD), e da submtrica de medida da reduo do espalhamento, Scattering Reduction (SR). Essas mtricas foram desenvolvidas com base nos estudos apresentados na Seo 3.1 deste captulo e tm a proposta de denir valores para o grau de quanticao de um interesse no sistema, sendo uma medida para ajudar aos mantenedores de software a decidir se uma refatorao para aspectos ir prover resultados positivos em um sistema, isto ainda na sua verso orientada por objetos. Inicialmente ser apresentado o Modelo de Concerns, depois sero denidas as mtricas QD e SR e por m sero apresentados exemplos de sua aplicao e anlise dos resultados. 3.2.1 Modelo de Concerns O Modelo de Concerns denido neste trabalho foi inspirado em um modelo j exis- tente proposto por Eaddy et al. (2008) para relacionar interesses transversais com defeitos. O modelo organiza hierarquicamente os interesses transversais em uma rvore, onde os ns internos so os interesses principais e os ns folha so os mtodos que implementem esse interesse. 51 Por exemplo, no estudo de caso JAccounting, o interesse transversal o controle de transaes (transaction), que implementado atravs dos seguintes mtodos, que sero os ns folha do modelo: begin, commit e rollback. No estudo de caso JSpider o interesse transversal analisado o logging, que foi denido como o n principal e os mtodos que o implementam sero mapeados como ns folha do modelo: debug, error, fatal, info e warn. Os modelos dos estudos de caso JAccounting e JSpider so mostrados nas Figuras 9 e 10 respectivamente. Figura 9: Modelo de Concerns do interesse transversal transaction do estudo de caso JAccount- ing. Figura 10: Modelo de Concerns do interesse transversal logging do estudo de caso JSpider. Para a aplicao das mtricas QD e SR sero considerados os interesses atmicos, isto , os mtodos que correspondem ao n folha do Modelo de Concers. Essa denio se justica pelo motivo que, quando um interesse implementado por dois mtodos distin- tos dicilmente sero modularizados em uma nica instruo. Por exemplo, o interesse transversal de JAccounting transaction dicilmente poder ser modularizado em um nico advice, visto que possui os seguintes ns folha beginTransaction, commit e rollback e entre essas chamadas pode haver cdigos diversos do sistema. Porm plausvel con- siderar que todas as chamadas do mtodo rollback possam ser connados em um nico advice. Alm disso, as preocupaes podem ser mapeadas para elementos do programa esttico, ou seja, ns da Abstract Syntax Tree (AST) do programa de destino. Desta forma assume-se que h uma relao que possibilita o mapeamento dos ns do Modelo de Concerns para os ns da AST. Por exemplo, o interesse rollback pode ser mapeado para 52 os ns da AST quando uma operao de rollback for acionada. Segundo essa denio, uma preocupao transversal um interesse que mapeado para vrios elementos do programa (EADDY et al., 2008). 3.2.2 Formalizao das Mtricas de Quanticao Suponha que a implementao do interesse transversal C, representado pelo n folha no Modelo de Concerns, esteja relacionado a jps join point shadows do programa base. Suponha tambm que adv advices foram usados para implementar C em um sistema AspectJ. Logo apresentado a primeira relao: N o de advices que implementam C N o de JPS afetados pelos advices = adv jps O melhor caso quando o interesse modularizado em um nico advice que afete os jps join point shadows, e o pior caso quando so necessrios jps advices para referenciar os jps join point shadows. Desta forma a relao descrita est no intervalo [1/jps, 1]. Porm, observa-se que quanto maior o valor, pior o resultado da quanticao. Assim, para atender premissa da denio de mtricas (EJIOGU, 1991; PRESSMAN, 2005), onde o valor 0 (zero) deve representar o pior caso, foi includa na frmula uma funo linear para ajustar ao intervalo desejado. 1 adv jps Essa nova normalizao est no intervalo de [0, 1-(1/jps)]. Porm o intuito transpor a razo para o intervalo [0,1], que um intervalo mais signicativo (PRESSMAN, 2005). Para isso, ser necessria a normalizao do resultado, considerando que o seu valor mximo igual a 1 - (1/jps). O resultado a frmula da mtrica Quantication Degree (QD), ou Grau de Quanticao: QD(C) = 1 adv jps 1 1 jps = jps adv jps 1 , jps > 1 Nesta frmula, C o interesse que ser implementado usando adv advices que afetam um total de jps join point shadows do cdigo orientado por objetos. Como pode ser observado, QD(C) varia de 0 (no pior caso) at 1 (no melhor caso), sendo que o pior caso acontece quando jps = adv, ou seja, cada advice implementado afeta somente um 53 join point shadow no programa base. No melhor caso porm, teremos o melhor benefcio da quanticao, ou seja, necessrio um advice (adv = 1) para afetar todos os jps join points shadows do sistema base. Na mtrica QD, o clculo (jps - adv) mede os benefcios da quanticao em termos de reduo de espalhamento. Em implementaes orientadas por objetos, o cdigo relacionado ao interesse deve ser colocado em cada um dos jps join point shadows do programa C. Na implementao orientada por aspectos possvel connar o cdigo em adv advices (enquanto jps > 1 e adv 1), visto que o valor de jps deve ser maior que 1 (um), pois caso seu valor seja igual a 1 (um) no ser considerado um interesse transversal. Em outras palavras, usando Java, o interesse estar espalhado ao longo dos jps join point shadows do sistema base, usando AspectJ, o espalhamento ser reduzido para adv advices. A partir da mtrica QD foi denida uma submtrica, a mtrica Scattering Reduc- tion (SR). Essa mtrica mede a reduo do espalhamento de cdigo caso um determinado interesse C venha a ser refatorado para aspectos, utilizando a seguinte frmula: SR(C) = jps adv A partir da denio de SR(C) a frmula de QD(C) pode ser reescrita assim: QD(C) = SR(C) jps 1 , jps > 1 O conceito de interesses homogneos e heterogneos utilizados nesta dissertao seguem as seguintes premissas, as chamadas de um interesse so homogneas quando os parmetros passados nesses mtodos possuem valores idnticos e podem ser modularizados atravs de um nico advice, essas chamadas sero consideradas heterogneas quando os parmetros passados nas chamadas do interesse tiverem valores diferentes. A partir dessa denio, um interesse transversal que possua n chamadas no cdigo do sistema, pode ter chamadas homogneas e heterogneas. Por exemplo, suponha as chamadas a seguir para o mtodo m : t 1 .m(arg 1 ) e t 2 .m(arg 2 ), enquanto t i indica o destino e arg i indica o argumento das chamadas (i = 1 ou i = 2). Essas chamadas do mtodo m sero homogneas quando os valores de arg 1 e arg 2 forem idnticos; caso esses valores sejam diferentes as chamadas sero heterogneas. 54 Atravs de QD possvel denir um aspecto de homogeneidade, ou seja, se QD(C) = 1, o interesse homogneo, se QD(C)= 0 o interesse heterogneo, os valores entre 0 e 1 sero indicadores para suportar decises de desenvolvimento. Dessa forma importante ressaltar que no se pode armar que um interesse considerado homogneo se tem um valor de QD superior a um valor pr-denido ou heterogneo caso contrrio, esse valor no existe. 3.3 Exemplos Nesta seo, sero apresentados exemplos da aplicao das mtricas propostas, assim como uma anlise para cada exemplo. Exemplo 1: Suponha o concern C mapeado para 20 join point shadows. Na Figura 11 so apresentados os possveis valores que QD pode assumir quando o nmero de advices usados para implementar C varia de 1 at 20. Nesse exemplo, possvel vericar que QD possui um valor escalvel e seu valor normalizado entre 0 e 1. Figura 11: Valores de QD assumidos para concerns mapeados para 20 join point shadows. Exemplo 2: Considere o sistema hipottico Gracos que possibilita a gerao de grcos a partir de informaes denidas pelo usurio. Os seguintes mtodos fazem parte da classe Ponto, setX(int x) e setY(int y), os dois mtodos, em conjunto, so responsveis por desenhar um determinado ponto na tela. Esses mtodos so os ns folha do Modelo de Concerns do interesse transversal Ponto. Na Figura 12 so exemplicadas algumas chamadas dos mtodos no sistema. Os valores calculados para as mtricas QD e SR para os interesses setX e setY so 55 public class Linha{ public class Matriz{ ... ... public Linha() { public Matriz() { Ponto.setX(0); Ponto.setX(10); ... ... Ponto.setY(0); Ponto.setY(50); } } void DesenhaLinha(){ void MontaMatriz(){ ... ... int x = 10; Ponto.setX(x); Ponto.setX(x); ... ... Ponto.setY(retornaY()); Ponto.setY(retornaY()); ... .... } } ... ... } } Figura 12: Exemplos de chamadas do interesse Ponto no sistema Gracos. mostrados na Tabela 3. Avaliando os resultados identica-se que os valores de QD e SR foram altos para o interesse setY e baixos para o interesse transversal setX. Isso se justica porque foi identicado que possvel implementar as 67 chamadas do interesse transversal setY em apenas 3 advices, ou seja, uma grande quantidade de chamadas homogneas desse interesse. Porm, para o mtodo setX, sero necessrios 65 advices para implementar as 67 chamadas, isso porque apresentam um comportamente heterogneo. Os resultados para a mtrica SR acompanham o resultado da mtrica QD, ou seja, para o interesse setY sero reduzidas 64 chamadas no cdigo orientado por objetos, enquanto para o interesse setX somente 2 chamadas sero reduzidas. Concern jps adv SR QD setX(int x) 67 65 2 0,03 setY(int y) 67 3 64 0,97 Tabela 3: Clculo de QD e SR para os interesses setX(int x) e SetY(int y). A partir dos resultados apresentados, pode-se armar que mais indicada a refa- torao do interesse transversal setY do que do interesse transversal setX. O interesse transversal setY apresenta alto grau de quanticao, o que proporcionar a reduo das linhas de cdigo, do espalhamento, do entrelaamento e da replicao de cdigo do interesse no sistema. Para o interesse setX, o baixo valor de quanticao no signica 56 diretamente que este no deva ser modularizado por meio de aspectos, porm o valor baixo do grau de quanticao indica que sero necessrios muitos advices para atender a todos os join points do sistema. Dessa forma, a refatorao pode no resultar em vantagens ao sistema. Por exemplo, ao se analisar o nmero de linhas de cdigo necessrios para a implementao dos interesses, haver o aumento das linhas necessrias para a implemen- tao dos pointcuts e advices. Sendo um valor muito superior da quantidade utilizada para implementar as chamadas dos mtodos no sistema, isso pode ocasionar diculdade de manuteno e abertura a erros. Exemplo 3: Suponha os sistemas hipotticos S1 e S2 e respectivamente as pre- ocupaes C1 e C2 dos sistemas conforme mostrado na Tabela 4. Sistema Concern jps adv SR QD S1 C1 101 51 50 0.5 S2 C2 11 6 5 0.5 Tabela 4: Comparao de valores de QD e SR. Em ambos os casos o valor de QD o mesmo, 0.5. Este valor signica que o nmero extrado de advices exatamente a mdia entre o valor mnimo e mximo de advices que podem ser utilizados nesses sistemas. Por exemplo, no sistema S1 o melhor cenrio para modularizar o interesse C1 seria 1 advice e o pior cenrio seria necessitar de 101 advices. Conforme o exemplo do sistema S1 o clculo de QD apresentado a seguir: QD(C1) = 101 51 100 = 0.5 Similar em S2: QD(C1) = 11 6 10 = 0.5 Analisando os exemplos dos sistemas de exemplo, observa-se em S1 que a quanti- cao contribuiu para reduzir de 101 para 51 o nmero de locais que requerem a presena do cdigo relacionado ao interesse C1, isto , o valor de SR = 50. SR(C1) = 101 51 = 50 J no sistema S2 a quanticao contribuiu para reduzir de 11 para 6 o nmero de locais que requerem o cdigo relacionado ao interesse C2, ou seja, SR = 5. 57 SR(C1) = 11 6 = 5 Portanto, mesmo os sistemas S1 e S2 terem os mesmos valores de QD, a modulari- zao dos interesses atravs de aspectos prov mais benefcios de reduo de espalhamento para o sistema S1 (50) do que para o sistema S2 (5). importante ressaltar que na avali- ao dos benefcios da quanticaao necessrio avaliar o resultado tanto de QD quanto SR, pois fornecem informaes distintas. A mtrica QD apresenta um ndice de melhor uso possvel dos aspectos em um determinado cenrio, SR porm apresenta o valor ab- soluto de locais onde no ser necessrio inserir o cdigo do interesse transversal caso decidam utilizar aspectos. 3.4 Consideraes Finais Neste captulo inicialmente foi apresentada uma anlise quantitativa da aplicao das mtricas de separao de interesses CDC e CDO e da mtrica CLC em sistemas reais que foram refatorados para aspectos. A partir dessa anlise pode-se concluir que os melhores resultados da refatorao para aspectos tambm apresentaram os melhores resultados quantitativos. A partir dessa motivao, foram propostas duas novas mtricas de quanticao QD e SR, com o objetivo de prover uma medida direta da quanticao de um interesse transversal em um sistema e o valor da reduo do espalhamento de cdigo caso esse seja refatorado para aspectos. Aps a denio formal dessas mtricas, foram apresentados alguns exemplos de aplicao das mtricas e as avaliaes dos resultados. Conforme os exemplos apresentados, a partir dos valores de QD e SR, pode-se criar a relao da quanticao com o sucesso da refatorao de um determinado interesse, ou seja, altos valores de QD e SR signicam bons resultados da refatorao de interesses transversais para aspectos. Quando os valores de QD e SR so baixos, pode indicar que a refatorao no seja interessante, pois a implementao destes atravs de aspectos no vai ocasionar reduo de nmero de linhas, de componentes e pode dicultar a manuteno e testes dos sistemas. 58 4 FERRAMENTA CONCERNMETRICS Neste captulo, ser apresentada a ferramenta ConcernMetrics que foi desenvolvida para possibilitar a modelagem do Modelo de Concerns, a automatizao do clculo das mtricas QD e SR, bem como das mtricas convencionais de separao de interesses CDC e CDO. Na Seo 4.1 so apresentados os objetivos da implementao da ferramenta ConcernMetrics. Na Seo 4.2 o projeto da ferramenta ConcernMetrics apresentado, detalhando a interface, anlise do cdigo fonte e algoritmos de deciso. Na Seo 4.3 so apresentadas as limitaes da verso atual da ferramenta. Finalmente, na Seo 4.4 so feitas as consideraes nais. 4.1 Objetivos Para a aplicao manual das mtricas QD e SR, necessrio denir um Modelo de Concerns com o detalhamento da rvore de concerns at os nveis folha dos mtodos que implementem o interesse transversal selecionado. A partir do Modelo de Concerns, necessrio identicar em todo o sistema os join points e denir quais chamadas so homo- gneas e heterogneas para consequentemente serem modularizadas atravs do mnimo de advices. Somente aps essa anlise do sistema como um todo, as mtricas QD e SR sero efetivamente calculadas. Essas mtricas foram formalizadas e exemplicadas, porm o processo para a sua aplicao pode se tornar exaustivo, complexo e aberto a erros quando aplicado manualmente, crescendo conforme o tamanho do sistema e a quantidade de join points espalhados pelo cdigo fonte. Outro fator importante a avaliao quantitativa da comparao dos resultados das mtricas de separao de interesses CDC e CDO aplicadas a uma verso do sistema orientado por objetos e tambm em sua verso j refatorada para aspectos, conforme foi apresentado no estudo do Captulo 3. Como foi vericado, o valor quantitativo da comparao dessas mtricas pode ser uma medida importante na avaliao da refatorao de um sistema para aspectos. Essa avaliao pode se tornar muito dispendiosa visto 59 que, para o clculo das mtricas CDC e CDO, precisa-se que sejam identicados os in- teresses transversais a serem analisados, os mtodos, classes, advices e aspectos que os implementem e que faam chamadas a esses interesses. Outro fator importante o fato de que necessrio que exista uma verso do sistema j refatorada para aspectos, o que pode tomar tempo e esforo em vo, caso se identique que os interesses transversais no podero ser devidamente modularizados atravs de aspectos. O objetivo do desenvolvimento da ferramenta ConcernMetrics automatizar o processo de modelagem do Modelo de Concerns, o clculo da mtrica de quanticao QD e da submtrica de reduo do espalhamento SR. A ferramenta ConcernMetrics prope ainda o clculo das mtricas convencionais de separao de interesses CDC e CDO para o cdigo orientado por objetos e tambm a estimativa dos valores destas mtricas caso o interesse venha a ser refatorado para aspectos. Para o clculo das mtricas propostas para a ferramenta ConcernMetrics as se- guintes funcionalidades foram implementadas: Mapeamento lgico de interesses transversais possibilitando a modelagem do Modelo de Concerns; Identicao dos join points no cdigo fonte; Identicao de chamadas homogneas e heterogneas do interesse e deciso do agrupamento dos join points em advices; Identicao de mtodos e classes que implementem e acessem um determinado interesse. A ferramenta ConcernMetrics automatiza esses processos e calcula as mtricas totalmente baseada no cdigo fonte orientado por objetos, isto sem que o sistema sofra qualquer alterao estrutural ou comportamental. A ferramenta ConcernMetrics foi de- senvolvida na linguagem Java e disponibilizada como um plugin da ferramenta de desen- volvimento Eclipse. 4.2 Implementao Nesta seo, ser detalhado todo o processo de desenvolvimento da ferramenta ConcernMetrics, suas funcionalidades, tecnologias utilizadas e algoritmos de deciso. 60 4.2.1 Interface A ferramenta ConcernMetrics estende a interface da ferramenta ConcernMapper, proposta por Robillard e Weigand-Warr (2005). ConcernMapper um plugin para o Eclipse que permite acesso estrutura do sistema criando uma comunicao direta entre o cdigo fonte e a ferramenta. A ferramenta ConcernMetrics adicionou algumas funcionalidades especcas fer- ramenta ConcernMapper, porm manteve suas principais funcionalidades. Por exemplo, ConcernMapper possui a funcinalidade de criao de um modelo lgico de interesses que apresentado em forma de uma rvore hierrquica. A ferramenta ConcernMapper possui ainda a possibilidade de identicao no cdigo fonte a chamada de mtodos e atributos que foram vinculados ao concern inserido no seu modelo lgico, um exemplo demons- trado na Figura 13. Figura 13: Identicao dos mtodos dos interesses a partir da viso da ferramenta Concern- Mapper. A ferramenta ConcernMetrics estendeu a funcionalidade de mapeamento de in- teresses transversais de ConcernMappers que permite a modelagem do Modelo de Con- cerns, conforme denido no Captulo 3. De acordo com a denio do modelo proposto, necessrio a adio de concerns ao modelo at o seu nvel atmico, ou seja, at que no seja possvel dividir o interesse em mais de um mtodo que o implementa. Um exemplo da modelagem do Modelo de Concerns mostrado na Figura 14. 61 Figura 14: Ferramenta ConcernMetrics: Modelo de Concerns do interesse transversal logging do sistema JSpider. O Modelo de Concerns criado na interface de ConcernMapper. Para montar o modelo necessrio selecionar os mtodos associados ao interesse transversal a partir da viso Package Explorer do Eclipse, arrastando-os e soltando-os no n correspondente ao interesse no Modelo de Concerns. Na Figura 15, apresentado um diagrama de sequncia da utilizao da ferramenta ConcernMetrics. Figura 15: Diagrama de sequncia da ferramenta ConcernMetrics. Aps a denio do Modelo de Concerns, o clculo das mtricas pode ser solicitado na tela ConcernMetrics. A tela ConcernMetrics do plugin foi desenvolvida para ser a interface do usurio para solicitao do clculo das mtricas para os interesses detalhados no Modelo de Concerns e para apresentao dos resultados das mtricas QD, SR, CDC e CDO para o cdigo orientado por objetos e das mtricas CDC e CDO para o cdigo 62 orientado por aspectos. Os resultados so apresentados em uma inteface em forma de tabela, possibilitando uma visualizao e anlise dos resultados, conforme mostrado na Figura 16. Figura 16: Ferramenta ConcernMetrics: apresentao do resultado do clculo das mtricas para o interesse transversal logging do sistema JSpider. 4.2.2 Anlise do Cdigo Fonte A leitura do cdigo fonte do sistema que est sendo avaliado feita utilizando-se o framework Java ASM 1 para manipulao e anlise de bytecode. O framework ASM foi desenvolvido por Bruneton, Lenglet e Coupaye (2002) e possibilita a anlise estrutural do sistema, modicaes de cdigo, declarao de classes, mtodos e atributos, entre outras manipulaes mais complexas. A ferramenta ConcernMetrics necessita analisar a estrutura do cdigo fonte para o clculo das mtricas, para isso implementa as interfaces Visitor do ASM. As intefaces Visitor so responsveis pela anlise estrutural das classes (ClassVisitor), mtodos (MethodVisitor) e atributos (FieldVisitor) do cdigo fonte. Dessa forma, o cdigo fonte do sistema atravessado identicando declarao de classes, mtodos, atributos, instanciao de objetos, identicao de chamadas de mtodos e parmetros, assim como a identicao dos tipos e valores dos parmetros, atributos e objetos. Um exemplo da interface ClassVisitor do framework ASM mostrado na Figura 17. O mtodo visit (linha 02) chamado a cada declarao de uma classe, podendo identicar atravs dessa chamada o seu nome, assinatura, sua superclasse e interfaces que essa classe implementa. O mtodo visitMethod (linha 12), por exemplo, chamado nas declaraes e chamadas 1 As siglas ASM no tem nenhum signicado especco, apenas uma referncia para a palavra chave asm na linguagem C, que permite que algumas funes sejam implementadas em linguagem assembly (BRUNETON; LENGLET; COUPAYE, 2002). 63 de mtodos nesta classe. A partir dessas interfaces possvel fazer uma leitura completa do cdigo fonte do sistema. 01: public interface ClassVisitor { 02: void visit(int version, int access, String name, String signature, 03: String superName, String[] interfaces); 04: void visitSource(String source, String debug); 05: void visitOuterClass(String owner, String name, String desc); 06: AnnotationVisitor visitAnnotation(String desc, boolean visible); 07: void visitAttribute(Attribute attr); 08: void visitInnerClass(String name, String outerName, String innerName, 09: int access); 10: FieldVisitor visitField(int access, String name, String desc, 11: String signature, Object value); 12: MethodVisitor visitMethod(int access, String name, String desc, 13: String signature, String[] exceptions); 14: void visitEnd(); 15: } Figura 17: Interface ClassVisitor do framework ASM (BRUNETON; LENGLET; COUPAYE, 2002). As informaes coletadas atravs da classe Visitor da ferramenta ConcernMetrics, que implementa as interfaces ClassVisitor, MethodVisitor e FieldVisitor, so tra- tadas para que sejam armazenadas em uma estrutura em rvore dentro do mdulo Tree. Esse mdulo trata as informaes e as armazena conforme os seguintes objetos: Objeto Tree: contm uma estrutura em rvore de todas as classes do sistema; Objeto Class: contm as informaes de herana da classe e seus mtodos; Objeto Method: contm o valor dos parmetros e a informao se so dinmicos ou estticos, tipo dos parmetros e chamadas de outros mtodos. Para o armazenamento das informaes, os objetos se relacionam de acordo com a estrutura modelada no diagrama de classes da ferramenta ConcernMetrics, Figura 18. O objeto Tree pode ser considerado o n principal da estrutura em rvore que con- tm as informaes do cdigo fonte do sistema, esse contm uma lista de objetos Class, que a lista de classes do sistema. Cada objeto Class por sua vez possui uma lista de ob- jetos Method que representam os mtodos implementados nessa classe. Um objeto Method contm uma lista de objetos do tipo Param, que contm os parmetros desse mtodo, seu tipo e valor; uma lista dos objetos declarados no mtodo, seu tipo e valor; e uma lista de 64 Figura 18: Diagrama de classes da ferramenta ConcernMetrics. outros mtodos que este mtodo acessa. A partir desta estrutura, a ferramenta Concern- Metrics possui as informaes necessrias para a localizao dos join points, denio dos advices e anlise de quais classes e mtodos implementam determinados interesses contidos no Modelo de Concerns. 4.2.3 Algoritmos de Deciso O mdulo Metrics da ferramenta o responsvel pela identicao e anlise das informaes dos interesses na estrutura Tree e pelo clculo das mtricas QD, SR, CDC e CDO. Para efetuar a anlise e clculo das mtricas foram denidos alguns algoritmos de deciso, estes possibilitam a identicao de advices homogneos e heterogneos, identi- cam os join points e calculam as mtricas propostas para cada interesse do Modelo de Concerns. 65 A deciso mais importante no momento do clculo das mtricas a identicao dos interesses homogneos e heterogneos, ou seja, identicar quais chamadas so idnticas e quais so diferentes, para a denio da quantidade de advices necessrios para atender a todos os join points. Essas denies so feitas no mdulo Metrics e obedecem aos algoritmos de deciso detalhados a seguir. Algoritmo 1: Suponha as chamadas a seguir para o mtodo m : t 1 .m(arg 1 ) e t 2 .m(arg 2 ), t i indica o destino e arg i indica o argumento das chamadas (i = 1 ou i = 2). Essas chamadas sero movidas para o mesmo advice nas seguintes condies: 1. Caso sejam mtodos estticos, t 1 e t 2 devem denotar a mesma classe ou classes que herdem da mesma superclasse. Em caso de mtodos dinmicos, t 1 e t 2 devem denotar que so do mesmo tipo ou que so derivados de um tipo comum. 2. arg 1 e arg 2 so o mesmo valor constante ou campos tenham o mesmo tipo (ou so derivados de um tipo comum). Suponha as chamadas de start e log nas classes A e B da Figura 19. Neste exemplo, o interesse start pode ser movido para um nico advice considerando-se as denies do Algoritmo 1. Isso se verica pois, o objeto tx em ambas as classes do tipo Transaction, logo atende regra nmero 1, e o parmetro passado na chamada do mtodo nas duas classes esttico e tem o valor igual a 1, logo atende regra nmero 2. class A { class B { Transaction tx; Transaction tx; void foo(){ void bar(){ tx.start(1); tx.start(1); .... .... Logger.log("finished"); Logger.log("panic"); .... .... } } } } Figura 19: Exemplo de chamadas do interesse transversal log. O mtodo log, do mesmo exemplo da Figura 19, um mtodo esttico da classe Logger, dessa forma atende regra nmero 1 do algoritmo. Porm, os argumentos passados nas chamadas desse mtodo so dinmicos e no tm o mesmo valor. O va- lor do parmetro passado para log na classe A "nished", enquanto o valor de log 66 na classe B "panic", desta forma no atendem regra nmero 2, consequentemente no possvel conn-los em um nico advice. Algoritmo 2: Suponha as chamadas a seguir para os mtodos m i : x.m 1 (arg) e y.m 2 (arg), enquanto m i indica os advices contidos no Modelo de Concerns, sendo (i = 1 ou i = 2). Essas chamadas sero movidas para o mesmo advice nas seguintes condies: 1. m 1 e m 2 faam parte do mesmo Modelo de Concerns; 2. m 1 e m 2 sejam chamadas em sequncia, ou seja, sem nenhum outro cdigo da implementao do sistema entre as duas chamadas. Considere o Modelo de Concerns do interesse logging, Figura 10 na pgina 51 do Captulo 3. Esse Modelo de Concerns tem o n principal logging e os seguintes ns folha: debug, error, fatal, info e warn. Considere o trecho do cdigo fonte da classe VelocityPlugin do sistema JSpider apresentado na Figura 20. class VelocityPlugin { ... log.debug("opened trace file " + traceFileName + ""); log.info("Writing to trace file: " + traceFileName) .... } Figura 20: Exemplo de interesses transversais do sistema JSpider. No exemplo da Figura 20 h a chamada de dois interesses do Modelo de Concerns de logging, debug e info. Ao analisar esses dois interesses, segundo o Algoritmo 2, considerado que ambos possam ser modularizados por um nico advice, visto que ambos fazem parte do mesmo Modelo de Concerns e ambos esto sendo chamados em sequncia. Considere as classes hipotticas X e Y da Figura 21. Neste exemplo, na classe X, as chamadas dos interesses error e debug podem ser modularizados em um mesmo advice pois atendem ao Algoritmo 2. Isso porque fazem parte do mesmo Modelo de Concerns e so chamados em sequncia, sem nenhum outro cdigo entrelaado entre as chamadas. O mesmo ocorre para o exemplo da classe Y e as chamadas dos interesses error e warn. 67 Alm disso, h ainda outro fator para anlise neste mesmo exemplo, os interesses atendem ao Algoritmo 1 que identica as chamadas de um mesmo advice. As cha- madas so estticas do mesmo tipo, tanto para as chamadas dos interesses error e warn da Classe X, quanto para as chamadas na Classe Y, e os parmetros so es- tticos e idnticos. Dessa forma, ser possvel modularizar as quatro chamadas dos interesses em um nico advice pois atendem s regras dos dois algoritmos denidos. class X class Y { { void a() void b() { { ... ... log.error("Error."); log.error("Error."); log.warn("Caution"); log.warn("Caution"); ... ... } } } } Figura 21: Exemplo de chamada de interesses transversais chamados em sequncia. Os algoritmos detalhados acima foram feitos para a identicao de interesses ho- mogneos e heterogneos e a partir desses a denio da quantidade de advices necessrios para implement-los. A partir da identicao dos advices necessrios para implementar os interesses transversais, possvel efetuar o clculo das mtricas QD e SR. Para o cl- culo das mtricas CDC e CDO do cdigo orientado por objetos no necessrio nenhum dos algoritmos, visto que esses valores so obtidos diretamente do cdigo fonte e essa identicao feita pela ferramenta baseada somente nas informaes armazenadas no mdulo Tree. A ferramenta ConcernMetrics estima o valor das mtricas CDC e CDO caso o sistema seja refatorado para aspectos, esses clculos so totalmente baseados no cdigo orientado por objetos e na quantidade de advices e aspectos que sero necessrios para modularizar os interesses transversais que esto sendo analisados. A partir dessas infor- maes as seguintes frmulas foram denidas para a estimativa dos clculos de CDC e CDO: CDC: O clculo de CDC, conforme j detalhado anteriormente, feito somando-se a quantidade de classes e aspectos que implementam ou acessam um determinado 68 interesse. Para o clculo de CDC, para o cdigo orientado por aspectos, feita a soma de C (quantidade de classes) que implementam o interesse e A (quantidade de aspectos) que implementam os advices. Consideram-se para esse clculo somente a classe que implementa o interesse transversal, isto porque previsto que todos os join points do sistema sero modularizados atravs de aspectos. A partir disso, a frmula para o clculo de CDC para o sistema orientado por aspectos denida: CDC(OA) = C + A Um exemplo do clculo para CDC o mtodo debug(object) do interesse trans- versal logging do sistema JSpider apresentado na Figura 22. class DistributedLoadThrottleProvider { ... log.debug("throttle interval set to " + interval + " ms."); .... } Figura 22: Exemplo de chamada de interesse transversal do sistema JSpider. Esse interesse transversal no cdigo orientado por objetos do sistema possui o valor de CDC igual a 16, para o sistema orientado por aspectos, conforme a frmula apresentada, o valor de CDC ser igual a 2. O valor de C a quantidade de classes que implementam o interesse transversal, esse valor obtido a partir da estrutura Tree, o valor de A a quantidade de aspectos necessrios para implementar os advices, este ser sempre considerado igual a 1, pois todos os advices do sistema podem ser implementados em um nico aspecto, caso seja separado em mais aspectos ser feito por opo dos desenvolvedores do sistema. CDO: O clculo de CDO feito com base na quantidade de mtodos e advices que implementam ou acessam determinado interesse. Para o clculo de CDO, para o cdigo orientado por aspectos, considera-se o total de adv advices somado com o valor m, que a quantidade de mtodos que implementam o interesse. A frmula do clculo de CDO denida a sequir: CDO(OA) = adv + m 69 O exemplo apresentado na Figura 22 pode ser utilizado tambm para exemplicar o clculo de CDO. Para o sistema orientado por objetos o valor de CDO igual a 47, para o sistema orientado por aspectos, para o mtodo debug(object), o resultado ser igual a 43. Para estimar o valor de CDO, para o sistema orientado por aspecto, deve-se conhecer o valor de advices necessrios para modularizar todos os join points do interesse que est sendo avaliado, neste exemplo foram necessrios 42 advices para atender aos 46 join points. O valor de advices foi somado ao valor de m, baseado na denio do Modelo de Concerns utilizado, onde um interesse transversal deve ser detalhado at serem encontrados seus ns folha que so unidades indivisveis, ou seja, um nico mtodo, o valor de m ser sempre igual a 1 (um). A partir das denies feitas nesta seo a ferramenta ConcernMetrics calcula o valor da mtrica de quanticao QD e a submtrica de reduo do espalhamento SR. Calcula ainda, com base nas informaes coletadas e de acordo com a denio das frmu- las apresentadas nesse captulo, os valores das mtricas de separao de interesses CDC e CDO para o cdigo orientado por objetos e tambm estima os valores para essas mesmas mtricas considerando uma possvel refatorao do sistema para aspectos. A ferramenta ConcernMetrics possibilita a gerao do Modelo de Concerns e a partir deste facilmente solicitar o clculo das mtricas. Os resultados so apresentados em uma interface em forma de tabela, com os resultados das mtricas para cada interesse, tornando fcil a anlise dos resultados para tomadas de decises de refatorao do sistema. 4.3 Limitaes da Ferramenta ConcernMetrics A ferramenta ConcernMetrics apresenta ainda algumas limitaes na sua verso atual, conforme detalhado a seguir: A m de avaliar os benefcios da quanticao, a ferramenta ConcernMetrics ape- nas trata de interesses transversais dinmicos, ou seja, interesses transversais que podem ser modulados por meio de advices (KICZALES et al., 2001). Alm disso, a ferramenta assume que interesses transversais (dinmicos) sempre correspondem chamadas de mtodos nicos. Portanto, as preocupaes associadas a outras declaraes (atribuies, loops, etc) ou interesses associados a vrias instrues, devem ser primeiro extrados do mtodo, utilizando a Extract Method Refactoring (FOWLER et al., 1999). No entanto, a exigncia da aplicao prvia de extrao para 70 um mtodo, nesses casos, no representa um esforo infrutfero. Mesmo que os de- senvolvedores decidam no utilizar aspectos, os mtodos de extrao, na maioria dos casos, contribuem para eliminar cdigo repetido e para aumentar a inteligibilidade. AspectJ permite utilizao de aspectos somente em pontos bem denidos na exe- cuo de sistemas, ou seja, antes, durante ou depois de alguma chamada que possa ser identicada por um pointcut. Em casos que no possvel a identicao desses join points, necessria uma transformao de cdigo. Geralmente, essas transfor- maes de cdigo podem ser divididas em Reordenao da Declarao ou Mtodo de Extrao (MALTA; VALENTE, 2009; BINKLEY et al., 2006). A ferramenta Concern- Metrics no considera eventuais necessidades de transformaes no cdigo, considera que os join points encontrados so possveis de ser identicados atravs de pointcuts. A ferramenta avalia somente se possvel extrair as chamadas associadas a interes- ses transversais para o mesmo advice. No entanto, aconselhvel, para o clculo das mtricas e identicao de join points e advices atravs de ConcernMetrics, a avaliao se h a necessidade de eventuais transformaes de cdigo previamente sua utilizao. 4.4 Consideraes Finais Neste captulo foi apresentada a ferramenta ConcernsMetrics, que uma ferra- menta para automatizao do processo de modelagem do Modelo de Concerns e do clculo das mtricas propostas nesta pesquisa, a mtrica de quanticao QD e a submtrica de reduo do espalhamento SR. A ferramenta ConcernMetrics ainda calcula o valor das mtricas de separao de interesses CDC e CDO para o cdigo orientado por objetos e estima os valores dessas mtricas caso o sistema seja refatorado para aspectos. A ferramenta capaz de identicar de informaes no cdigo fonte como join points, mtodos e classes que implementem e acessem o interesse em anlise. A ferramenta possui ainda a funcionalidade de estimativa do menor nmero necessrio de advices para modularizar os interesses transversais que esto sendo analisados. Foram apresentados detalhes da interface, da estrutura para leitura do cdigo fonte, algoritmos de deciso, e por m as limitaes presentes na verso atual da ferramenta. 71 5 AVALIAES DO GRAU DE QUANTIFICAO Neste captulo apresentada uma avaliao das mtricas de quanticao QD e SR atravs da aplicao destas em trs sistemas, JAccounting e JSpider refatorados por Binkley et al. (2006) e JHotDraw refatorado por Binkley et al. (2005). As mtricas QD e SR foram aplicadas manualmente nos sistemas selecionados como estudos de caso e esses valores sero comparados com os resultados obtidos pela avaliao quantitativa apresentada no Captulo 3. Ainda neste captulo sero apresentados os resultados obtidos para as mtricas QD, SR, CDC e CDO para o cdigo orientado por objetos e tambm os resultado das mtricas CDC e CDO para o cdigo orientado por aspectos, feitos para os sistemas JSpider, JAccounting e JHotDraw atravs da ferramenta ConcernMetrics. Os valores obtidos atravs da ferramenta sero comparados com os resultados da anlise j efetuada manualmente e sero discutidas divergncias encontradas. A organizao do captulo feita como a seguir. So apresentadas as aplicaes em estudos de caso das mtricas QD e SR na Seo 5.1, na Seo 5.2 so detalhados testes feitos com a ferramenta ConcernMetrics em trs estudos de caso e avaliao dos resultados, na Seo 5.3 apresentada uma discusso sobre a quanticao e na Seo 5.4 nalmente sero apresentadas as consideraes nais. 5.1 Avaliao Manual das Mtricas QD e SR Os sistemas JSpider e JAccounting j foram apresentados no Captulo 3, onde foram utilizados para uma avaliao quantitativa atravs das mtricas CDC e CDO apli- cadas no cdigo orientado por objetos e tambm no cdigo orientado por aspectos. O sistema JHotDraw por sua vez um framework orientado por objetos da 2D graphics 1 , foi originalmente desenvolvido por Erich Gamma e Thomas Eggenschwiler e um frame- work Graphical User Interface (GUI) para Java. O sistema JHotDraw possui ainda uma verso que tem alguns interesses transversais implementados atravs de aspectos que 1 http://www.jhotdraw.org, version v.54b1 72 o AJHotDraw 2 , desenvolvido por Binkley et al. (2005) e juntamente com JHotDraw utilizado em diversos estudos sobre desenvolvimento de software orientado por aspectos (ANBALAGAN; XIE, 2007; MARIN; DEURSEN; MOONEN, 2007; MARIN et al., 2009). Esses sistemas foram selecionados como estudos de caso por terem verses originais orientadas por objetos e tambm verses refatoradas para aspectos, dessa forma possvel avaliar os resultados obtidos pelas mtricas QD e SR e compar-los aos resultados da refatorao desses sistemas. 5.1.1 Exemplo 1 - JAccounting O sistema JAccounting contm o interesse transversal transaction que pode ser decomposto nos interesses atmicos: iniciar a transao (beginTransaction), salvar a transao (commit) e desfazer a transao (rollback). Foi feita uma anlise manual no sistema JAccounting para a localizao dos join points do interesse transaction do cdigo fonte orientado por objetos. Os advices que modularizam os join points foram identicados com base no cdigo fonte j refatorado para aspectos. Na Tabela 5 so apresentados os valores obtidos das mtricas QD e SR, a quantidade de join point shadows (jps) encontrados no sistema e o nmero de advices (adv) necessrios para atender a todos os jps do sistema JAccounting. Interesses jps adv SR QD beginTransaction 15 1 14 1 commit 15 1 14 1 rollback 14 1 13 1 Tabela 5: Valores de QD e SR para o sistema JAccounting. Anlise dos resultados: No estudo de caso JAccouting foi obtido o melhor resultado possvel da quanticao atravs da utilizao de aspectos, ou seja, os trs interesses avaliados obtiveram o mximo possvel de quanticao (QD = 1). Alm disso, foram removidas 14 chamadas do cdigo base do sistema relacionado ao interesse beginTransacion (SR = 14), 14 chamadas do interesse commit (SR = 14) e 13 chama- das do interesse rollback (SR = 13). Dessa forma, pode-se armar que o resultado da quanticao e reduo do espalhamento ser satisfatrio caso esse sistema seja refatorado para aspectos. Conforme a anlise apresentada no Captulo 3, com base no cdigo fonte orientado por objetos e tambm no cdigo fonte orientado por aspectos, esse resultado 2 http://ajhotdraw.sourceforge.net/ 73 est correto, pois foi constatado que as 44 chamadas do interesse transaction foram efe- tivamente modularizadas por 3 advices. Alm disso o valor das mtricas CDC e CDO, calculados diretamente no cdigo orientado por objetos e no cdigo orientado por aspec- tos, mostrou que a refatorao dos interesses atravs de aspectos reduziu em 36% o valor de CDO e 70% o valor de CDC, resultado to positivo quanto o vericado atravs das mtricas QD e SR, validando desta forma que o resultado da quanticao encontrada por QD e SR compatvel com o resultado original, conforme analisado no cdigo j refatorado. 5.1.2 Exemplo 2 - JSpider No sistema JSpider, o interesse transversal utilizado para o estudo de caso foi o interesse logging. Este se decompe nos interesses atmicos: debug, info, warn, error e fatal. Foi feita uma inspeo manual no sistema JSpider para identicao dos interesses e localizao dos join points no cdigo fonte orientado por objetos. A identicao dos advices que foram utilizados para modularizar os interesses foi feita diretamente no cdigo fonte orientado por aspectos. A avaliao manual do cdigo fonte do sistema JSpider foi bem dispendiosa, visto que existem 190 join points do interesse e essas chamadas apresentam caractersticas heterogneas, o que diculta a identicao dos concerns. Por m, as mtricas QD e SR foram calculas e os resultados so apresentados na Tabela 6. Interesses jps adv SR QD debug(Object) 45 44 1 0.02 debug(Object,Throwable) 12 12 0 0.00 error(Object) 12 11 1 0.09 error(Object,Throwable) 68 68 0 0.00 fatal(Object,Throwable) 1 1 0 0.00 info(Object) 44 38 6 0.14 warn(Object) 2 2 0 0.00 Tabela 6: Valores de QD e SR para o sistema JSpider. Anlise dos resultados: Atravs dos valores calculados para a mtrica QD, pode-se pressupor que caso o sistema seja refatorado para aspectos ir utilizar poucas declaraes quanticadas, uma vez que os valores so zero ou muito prximos a zero. Em outras palavras, esses valores expressam o modo como os advices so utilizados na verso orientada por aspectos de JSpider. Na maioria dos casos, as chamadas dos interesses foram simplesmente transferidos para um advice, ou seja, foram retiradas as chamadas 74 dos join points e foram implementados os advices para atend-las. Foi identicado que o sucesso da refatorao para aspectos proporcional ao grau de quanticao de um interesse, ou seja, quanto mais alto o grau de quanticao melhores resultados sero obtidos atravs da refatorao. O valor de QD tambm implica nos valores de SR, pois quando o valor da quanticao baixo, consequentemente o valor de SR tambm ser baixo e menos indicada ser essa refatorao. Na anlise quantitativa do Captulo 3, o sistema JSpider no mostrou bons resulta- dos da quanticao, onde os valores para CDO aumentaram 125%, ou seja, foi necessrio um nmero muito maior de advices do que o nmero de join points espalhados no sistema para refatorar esses interesses, sendo esse valor compatvel com os resultados de QD e SR. A partir dessa anlise pode-se armar que o resultado da refatorao do interesse trans- versal logging, com base na quanticao e na reduo do espalhamento, no se mostra vantajosa. 5.1.3 Exemplo 3 - JHotDraw No sistema JHotDraw os valores de QD e SR foram calculados para dois mtodos relacionados a diferentes interesses transversais: fireSelectionChanged: faz parte do interesse selection picture; setUndoActivity: faz parte do interesse undo. Foi feita uma inspeo manual no cdigo fonte orientado por objetos e no cdigo orientado por aspectos. A Tabela 7 apresenta os valores calculados para as mtricas QD e SR para o sistema JHotDraw. Interesses jps adv SR QD reSelectionChanged() 4 2 2 0.67 setUndoActivity(Undoable) 10 9 1 0.11 Tabela 7: Valores de QD e SR para o sistema JHotDraw. Anlise dos resultados: Foi encontrado um valor mdio para o clculo de QD para o interesse fireSelectionChanged (QD = 0,67) e o resultado de SR foi igual a 2. Isso signica que o grau de quanticao do interesse intermedirio, porm ao se analisar juntamente QD e SR observa-se que o valor de SR muito pequeno, podendo neste caso no ser indicada sua refatorao pois a reduo do espalhamento ser pequena e pode causar maior complexidade no sistema pela sua implementao atravs de aspectos. Para o interesse fireSelectionChanged o grau de quanticao foi baixo (QD = 0.11) assim 75 como o valor de SR (SR = 1), caracterizando um interesse pouco quanticvel e no sendo indicada sua refatorao. 5.2 Avaliao da Ferramenta ConcernMetrics Com o intuito de validar os clculos feitos pela ferramenta ConcernMetrics das mtricas de quanticao QD e SR e tambm das mtricas de separao de interesses CDC e CDO para o cdigo orientado por objetos e tambm para o cdigo orientado por aspectos, foram utilizados os sistemas JAccounting, JSpider e JHotDraw como estudos de caso. Em geral, os resultados sugeridos pela ferramenta ConcernMetrics se igualam aos valores calculados manualmente a partir das verses orientadas por objetos e orientadas por aspectos destes sistemas. Em alguns casos, porm, os resultado no foram corres- pondentes. Isso se deve a novos requisitos implementados ou a falta de chamadas desses requisitos nas verses orientadas por aspectos. Os detalhes so mais bem discutidos nos exemplos a seguir. 5.2.1 Exemplo 1 - JAccounting O sistema JAccounting foi utilizado como estudo de caso da aplicao das mtricas de quanticao QD e SR, assim como das mtricas de separao de interesses CDC e CDO atravs da ferramenta ConcernMetrics. Na Figura 23, apresentado o Modelo de Concerns modelado na ferramenta ConcernMetrics. Figura 23: Modelo de Concerns do interesse transversal transaction do sistema JAccounting. 76 Baseado no Modelo de Concerns de JAccounting, a ferramenta calcula os valores das mtricas na aba ConcernMetrics. A Tabela 8 apresenta os resultados de QD e SR calculados a partir da ferramenta ConcernMeetrics na coluna CM, esses valores foram calculados com base no cdigo orientado por objetos do sistema. A coluna AM mostra os valores da anlise manual apresentada na Seo 5.1 deste captulo para o interesse transversal transaction. Interesses AM CM SR QD SR QD beginTransaction 14 1 14 1 commit 14 1 14 1 rollback 13 1 13 1 Tabela 8: Valores de SR e QD para o interesse transversal transaction de JAccounting. Anlise dos resultados: Comparando os resultados atuais calculados pela fer- ramenta ConcernMetrics, coluna CM, e os resultados apresentados na anlise manual, coluna AM, observa-se que a ferramenta obteve precisamente os mesmos valores medidos com base no cdigo fonte orientado por aspectos. Conforme j avaliado na Seo 5.1, e agora mostrado pela ferramenta ConcernMetrics, atravs dos clculos de QD e SR, o interesse transversal transaction apresenta uma caracterstica homognea e foi possvel a modularizao dos seus mtodos beginTransaction, commit e rollback atravs de 3 advices. Isso signica que a quanticao desse interesse transversal grande e indica uma caracterstica positiva a ser considerada para deciso da refatorao. A ferramenta ConcernMetrics calcula as mtricas de separao de interesses CDC e CDO para o cdigo orientado por objetos. No Captulo 3 foi feita uma anlise manual da aplicao dessas mtricas na verso do sistema orientada por objetos. Os resultados dos clculos destas mtricas para o sistema JAccounting feito pela ferramenta ConcernMetrics apresentado na Tabela 9 coluna CM, esse resultado comparado ao resultado obtido pela anlise manual na coluna AM. Anlise dos resultados: Conforme observado na Tabela 9, o resultado das mtri- cas CDC e CDO obtidos pela ferramenta ConcernMetrics foram idnticos aos resultados da aplicao manual dessas mtricas do sistema JAccounting. Atravs de ConcernMetrics possvel a identicao dos interesses transversais, assim como das classes e mtodos que acessam esses interesses, diretamente no cdigo fonte do sistema. A ferramenta ConcernMetrics foi utilizada ainda neste estudo de caso para prever 77 Interesses AM CM CDC CDO CDC CDO beginTransaction 8 8 8 8 commit 8 8 8 8 rollback 7 7 7 7 Tabela 9: Valores de CDC e CDO para o interesse transversal transaction de JAccounting do cdigo fonte orientado por objetos. os valores para as mtricas CDC e CDO, caso o sistema seja refatorado para aspectos. O resultado desse clculo demonstrado na Tabela 10, coluna CM. Esse clculo baseado no cdigo orientado por objetos e feita uma anlise dos interesses transversais estimando-se o valor dessas mtricas com base nas frmulas denidas no Captulo 4 desta dissertao. Os valores obtidos pela ferramenta so comparados com os valores calculados manual- mente, com base no cdigo fonte original orientado por aspectos, apresentados na coluna AM. Interesse AM CM CDC CDO CDC CDO beginTransaction 1 1 1 1 commit 1 1 1 1 rollback 1 1 1 1 Tabela 10: Valores de CDC e CDO para o interesse transversal transaction de JAccounting do cdigo fonte orientado por aspectos. Anlise dos resultados: Conforme a Tabela 10 as estimativas do clculo das mtricas CDC e CDO feitos pela ferramenta ConcernMetrics para o sistema JAccount- ing foram idnticos aos clculos feitos diretamente no cdigo orientado por aspectos. A ferramenta ConcernMetrics, a partir do cdigo orientado por objetos do sistema, obteve valores corretos para o clculo das mtricas de separao de interesses. A ferramenta ConcernMetrics, aplicada ao sistema JAccounting, apresentou os re- sultados corretos do clculos das mtricas QD e SR propostas nesta dissertao e tambm das mtricas convencionais de separao de interesses CDC e CDO, sendo essas ltimas calculadas para o cdigo orientado por objetos e tambm a estimativa dos valores para o cdigo orientado por aspectos. O resultado obtido pela ferramenta ConcernMetrics mais uma vez conrma que o interesse transversal transaction contm um alto grau de quanticao, ou seja, o resultado de sua quanticao ser positivo pois consegue retirar 78 diversas chamadas do interesse transversal espalhadas e entrelaadas pelo cdigo fonte e modulariz-las em apenas 3 advices, tornando mais fcil a manuteno, reutilizao e modularizao. 5.2.2 Exemplo 2 - JSpider O sistema JSpider o segundo estudo de caso utilizado para validao dos clculos da ferramenta ConcernMetrics. O interesse transversal que foi analisado o logging, este interesse se divide nos seguintes interesses atmicos: debug, error, fatal, info e warn, seu Modelo de Concerns apresentado na Figura 14. A ferramenta ConcernMetrics foi utilizada para calcular o valor das mtricas de quanticao de QD e SR, o resultado do clculo dessas mtricas apresentado na Tabela 11, coluna CM, que compara os valores obtidos pela ferramenta ConcernMetrics com os resultados obtidos do clculo manual apresentado na Seo 5.1, coluna AM. Interesse AM CM SR QD SR QD 1 debug(Object) 1 0.02 4 0.09 2 debug(Object,Throwable) 0 0.00 0 0.00 3 error(Object) 1 0.09 1 0.08 4 error(Object,Throwable) 0 0.00 0 0.00 5 fatal(Object,Throwable) 0 0.00 0 0.00 6 info(Object) 6 0.14 6 0.14 7 warn(Object) 0 0.00 0 0.00 Tabela 11: Clculo de QD e SR para o interesse transversal logging do sistema JSpider. Anlise dos resultados: Como podemos observar na Tabela 11, os valores indi- cados pelo ConcernMetrics se igualam aos valores reais medidos no cdigo fonte orientado por aspectos, em cinco dos sete mtodos considerados na avaliao (mais especicamente, os mtodos 2, 4, 5, 6 e 7). Porm alguns resultados apresentaram divergncias, estes so explicados da seguinte forma: A verso orientada por aspectos de JSpider no contm algumas chamadas do in- teresse transversal logging, ou seja, h chamadas de logging que existem na verso orientada por objetos, mas no so implementadas em nenhum advice na verso ori- entada por aspectos. Por exemplo, h 46 chamadas do mtodo debug(Object), na verso orientada por objetos analisada pela ferramenta ConcernMetrics, no entanto, na verso orientada por aspectos apenas 45 de tais chamadas so implementadas 79 pelos advices. Esse fato justica a diferena do valor calculado pela ferramenta ConcernMetrics encontrado para esse interesse. Duas novas chamadas do mtodo error(Object) foram implementados na verso orientada por aspectos, essas no existiam no cdigo orientado por objetos. No h justicativa para sua incluso, porm com essa vericao se justica a diferena dos valores calculados manualmente e pela ferramenta. Em algumas situaes, h chamadas consecutivas para o mesmo mtodo de logging no cdigo orientado por objetos. Por exemplo, a Figura 24 mostra trs chamadas consecutivas para debug(Object) no construtor da classe EventDispatcherImpl. O algoritmo para estimativas de mtricas utilizado em ConcernMetrics, denido no Capitulo 4, considera que chamadas consecutivas para mtodos includos no mesmo Modelo de Concerns pode ser extrado para um mesmo advice. No entanto, no caso particular da Figura 24, os desenvolvedores de JSpider decidiram implemen- tar essas chamadas em advices diferentes, justicando a diferena entre os valores encontrados. class EventDispatcherImpl { public EventDispatcherImpl (...) { ... log.debug("EventFilter for engine events = " + ...); log.debug("EventFilter for monitor events = " + ...); log.debug("EventFilter for spider events = " + ...); ... } Figura 24: Chamadas consecutivas de debug em JSpider. A ferramenta ConcernMetrics foi usada para calcular o valor das mtricas CDC e CDO para a verso original do sistema orientado por objetos, e tambm para realizar uma estimativa de qual seriam os valores dessas mtricas caso aspectos sejam usados para modularizar o cdigo de logging. Por m, as estimativas produzidas pela ferramenta foram comparadas com o valor efetivo das mtricas CDC e CDO calculados manualmente no cdigo orientado por objetos e no cdigo refatorado para aspectos. A Tabela 12 apresenta o resultado dos clculos para a mtrica CDC. Anlise dos resultados: Conforme mostrado na Tabela 12, em relao mtrica CDC, pode-se observar que no houve diferena entre a estimativa calculada pela ferra- 80 Interesse CDC AM-OO AM-OA CM-OO CM-OA Comp. 1 debug(Object) 16 2 16 2 0 2 debug(Object,Throwable) 2 2 2 2 0 3 error(Object) 6 2 6 2 0 4 error(Object,Throwable) 24 2 24 2 0 5 fatal(Object,Throwable) 2 2 2 2 0 6 info(Object) 16 2 16 2 0 7 warn(Object) 3 2 3 2 0 Tabela 12: Mtrica CDC para o interesse logging nas verses orientadas por objetos e orien- tadas por aspectos do sistema JSpider, bem como estimativa para essas mtricas produzida pela ferramenta ConcernMetrics (CM). menta ConcernMetrics e o valor efetivamente medido manualmente nas verses orientadas por objetos e orientadas por aspectos do sistema JSpider. Para todos os mtodos avali- ados o valor de CDC, na verso orientada por aspectos, foi igual a 2 (dois). O motivo que essa mtrica conta o nmero de componentes que implementam e acessam a fun- cionalidade logging, no caso do JSpider apenas a classe Log e um aspecto, o qual passa a connar todo o cdigo de logging do sistema. Os clculos da mtrica CDO para o sistema JSpider apresentaram algumas di- vergncias em relao avaliao feita manualmente do sistema. Os valores obtidos para o clculo CDO so apresentados na Tabela 13. Interesse CDO AM-OO AM-OA CM-OO CM-OA Comp. 1 debug(Object) 47 43 47 43 0 2 debug(Object,Throwable) 13 14 13 13 -1 3 error(Object) 14 12 14 13 +1 4 error(Object,Throwable) 71 68 71 71 +3 5 fatal(Object,Throwable) 2 2 2 2 0 6 info(Object) 46 39 46 40 +1 7 warn(Object) 3 3 3 3 0 Tabela 13: Mtrica CDO para o interesse logging calculado a partir do cdigo orientado por objetos e do cdigo orientado por aspectos do sistema JSpider, bem como estimativa para essas mtricas produzida pela ferramenta ConcernMetrics(CM). Anlise dos Resultados: Como pode ser observado na Tabela 13, a estimativa para a mtrica CDO para o cdigo orientado por objetos, calculado pela ferramenta ConcernMetrics, apresentou um resultado idntico anlise manual do sistema. Porm 81 a estimativa do valor dessa mesma mtrica para o cdigo orientado por aspectos foram identicadas algumas divergncias. Os valores calculados pela ferramenta ConcernMetrics coincidiram em trs dos sete mtodos avaliados (mtodos 1, 5 e 7), para os mtodos onde houveram diferenas, foi realizada uma inspeo manual com o objetivo de tentar esclarecer as divergncias. Os resultados dessa inspeo so reportados abaixo: O valor de CDO do mtodo debug(Object,Throwable), calculado pela ferramenta ConcernMetrics, menor em uma unidade do que o valor medido na verso orientada por aspectos. Essa diferena se justica pelo fato de uma chamada extra a esse mtodo ter sido adicionada ao cdigo da verso refatorada para aspectos, chamada essa que no existe na verso orientada por objetos do sistema. Consequentemente, um adendo a mais teve que ser criado. Foram observadas tambm diferenas nos valores de CDO para os mtodos error( Object) e error(Object,Throwable). Essas diferenas se explicam pelo fato de uma chamada ao mtodo error(Object) e trs chamadas ao mtodo error(Object, Throwable) terem sido eliminadas do cdigo da verso orientada por aspectos. O valor de CDO do mtodo info(Object) calculado pela ferramenta Concern- Metrics maior em uma unidade do que o valor medido na verso orientada por aspectos. Essa diferena justicada pelo fato de uma chamada a esse mtodo ter sido removida do cdigo orientado por objetos. A partir da anlise do estudo de caso JSpider, pode-se vericar que os clcu- los feitos pela ferramenta ConcernMetrics foram aqueles esperados em uma ferramenta que trabalha analisando apenas o cdigo orientado por objetos do sistema. Na verdade, constatou-se que as refatoraes realizadas no sistema JSpider para modularizao do cdigo de logging para aspectos implicaram em alteraes no comportamento original do sistema em determinados pontos. Como descrito anteriormente, chamadas a logging foram acrescentadas em alguns casos e removidas em outros. Essas alteraes podem ter ocorrido devido a novos requisitos que foram levantados durante a implementao dos aspectos ou ento por um descuido ou esquecimento dos responsveis por essa tarefa. Assim, conclui-se que a ferramenta ConcernMetrics estimou corretamente os valo- res das mtricas de quanticao QD e SR e tambm os valores das mtricas de separao de interesse CDC e CDO, tanto no cdigo orientado por objetos, quanto caso refatoraes para extrao de aspecto venham a ser aplicadas para modularizar o interesse de logging no sistema JSpider. Atravs dos resultados apresentados por ConcernMetrics pode-se 82 armar ainda que os valores quantitativos obtidos pelas mtricas foram baixos, o que signica que a refatorao desses interesses para aspectos no ir apresentar grandes van- tagens, pois na maioria das vezes as chamadas iro somente ser trocadas de lugar, sendo necessrio uma grande quantidade de advices para poder atingir a todos os join points. 5.2.3 Exemplo 3 - JHotDraw O sistema JHotDraw utilizado como o terceiro estudo de caso para validao da ferramenta ConcernMetrics. Conforme j relatado na Seo 5.1, dois mtodos so utilizados para estudo de caso da aplicao das mtricas QD e SR, estes tambm sero utilizadas agora para validao da ferramenta ConcernMetrics. Na Figura 25 apresen- tado o Modelo de Concerns feito atravs da ferramenta ConcernMetrics para modelagem dos interesses a serem analisados. Figura 25: Modelo de Concerns do sistema JHotDraw. A ferramenta ConcernMetrics calculou as mtricas QD e SR para o sistema JHot- Draw, conforme apresentado na Tabela 14. A coluna AM mostra os valores obtidos da avaliao manual diretamente feita no cdigo fonte orientado por aspectos do sistema e a coluna CM os valores estimados pela ferramenta ConcernMetrics. Anlise dos resultados: Conforme os resultados apresentados na Tabela 14 algu- mas diferenas foram encontradas entre a avaliao feita diretamente no cdigo orientado por aspectos e pelas estimativas da ferramenta ConcernMetrics. Essas so explicadas a seguir. 83 Interesse AM CM SR QD SR QD 1 reSelectionChanged() 2 0.67 3 1 2 setUndoActivity(Undoable) 1 0.13 11 0.92 Tabela 14: Resultado de QD e SR para JHotDraw. As chamadas para fireSelectionChanged poderiam ter sido connadas em um advice nico, porm na verso refatorada para aspectos estas chamadas foram im- plementadas em dois advices. No caso de setUndoActivity(Undoable) na verso orientada por aspectos do sis- tema, no foram extradas quatro chamadas do interesse para aspectos, nove cha- madas foram refatoradas para aspectos e uma nova chamada foi inserida. Foi ve- ricado no cdigo fonte orientado por aspectos que 10 join points foram modu- larizados por 9 advices. A partir de uma inspeo no cdigo fonte orientado por aspectos, com o intuito de explicar os motivos dessas implementaes, foi veri- cado que na refatorao do interesse setUndoActivity(Undoable), foram utiliza- dos diferentes pointcuts para atender aos join points do interesse. Desta forma, foram necessrios nove advices para implementar as 10 chamadas desse interesse transversal. Uma anlise baseada no cdigo fonte orientado por objetos e no cdigo fonte orientado por aspecto foi feita e concluiu-se que caso o interesse transver- sal setUndoActivity(Undoable) tivesse sido implementado atravs de um nico pointcut, a quantidade correta de advices necessrios para modulariz-los seriam 2 advices e iriam atingir a todos os 13 join points, conforme foi calculado pela ferra- menta ConcernMetrics. A partir do estudo de caso JHotDraw, pode-se vericar que a ferramenta Concern- Metrics obteve os valores corretos para as mtricas QD e SR. Alm da avaliao de QD e SR para JHotDraw, tambm foram feitas as avaliaes do clculo das mtricas CDC e CDO para o cdigo orientado por objetos, de acordo com o clculo da ferramenta Con- cernMetrics. Os resultados so demonstrados na Tabela 15. Os valores de CDC e CDO, conforme anlise manual do cdigo fonte orientado por objetos e o resultado obtido atravs da ferramenta ConcernMetrics, foram idnticos, mostrando mais uma vez a eccia da ferramenta. As mtricas CDC e CDO, quando foram calculados manualmente no cdigo fonte orientado por aspectos, resultaram nos valores apresentados na Tabela 16, os resultados 84 Interesse AM CM CDC CDO CDC CDO 1 reSelectionChanged() 1 5 1 5 2 setUndoActivity(Undoable) 13 13 13 13 Tabela 15: Resultado de CDC e CDO para os interesses transversais de JHotDraw do cdigo fonte orientado por objetos. por sua vez foram diferentes dos resultados estimados pela ferramenta ConcernMetrics. Interesse AM CM CDC CDO CDC CDO 1 reSelectionChanged() 2 3 2 2 2 setUndoActivity(Undoable) 10 9 2 3 Tabela 16: Resultado de CDC e CDO para os interesses transversais de JHotDraw do cdigo fonte orientado por aspectos. Anlise dos resultados: Algumas diferenas foram encontradas para os valores de CDC e CDO para o clculo do cdigo orientado por aspectos. Essas divergncias se justicam por modicaes encontradas no ato da implementao dos interesses atravs de aspectos. Desta forma, ocasionou as diferenas encontradas para os valores de CDC e CDO e tambm as divergncias vericadas nos clculos QD e SR, conforme j apresentado na Tabela 14. As diferenas so mais bem detalhadas abaixo: No cdigo orientado por aspectos, foi vericado que o interesse fireSelection- Changed() foi modularizado atravs de dois advices, resultando um valor para CDO igual a 3. A ferramenta ConcernMetrics por sua vez, considerou que seria necessrio somente 1 advice para modularizar os 4 join points, logo o resultado estimado para a mtrica CDC foi igual a 2. O mtodo setUndoActivity(Undoable) apresentou maiores diferenas, isso se deve ao fato que somente dez chamadas de SetUndoActivity(Undoable) foram refa- toradas para aspectos, estas chamadas moram modularizadas atravs de nove ad- vices, causando a diferena no valor de CDC e CDO para o valor calculado com base no cdigo fonte orientado por aspectos e o estimado pela ferramenta. A ferramenta ConcernMetrics apresentou resultados corretos para a avaliao do sitema JHotdraw, e, de acordo com os resultados apresentados, pode-se vericar que os 85 interesses analisados, quando refatorados separadamente de quaisquer interesses do sis- tema, iro apresentar alto grau de quanticao, ou seja, um nmero grande de chamadas sero refatoradas em uma quantidade pequena de advices. Isso se identica tanto pelo clculo das mtricas de quanticao QD e SR quanto pela anlise das mtricas CDC e CDO. 5.2.4 Anlise ConcernMetrics Conforme os estudos de caso apresentados a ferramenta ConcernMetrics apresen- tou uma estimativa correta para os interesses transversais dos sistemas JAccounting, JSpi- der e JHotDraw. Os valores estimados pela ferramenta foram comparados com os valores avaliados manualmente diretamente no cdigo fonte orientado por objetos e tambm nas verses orientada por aspectos dos sistemas. Isso possibilitou uma validao do clculo das mtricas, tanto para a validao das mtricas de quanticao QD e SR, quanto para as mtricas j conhecidas de separao de interesses CDC e CDO. Como anlise geral, os resultados foram totalmente corretos para o clculo das mtricas QD e SR, concluindo que a ferramenta ConcernMetrics eciente para a ava- liao quantitativa de interesses transversais de sistemas orientados por objetos Java na ferramenta Eclipse. A ferramenta ConcernMetrics apresentou tambm 100% de acerto no clculo de CDC e CDO para o cdigo orientado por objetos, para a estimativa de CDC e CDO para o cdigo orientados por aspectos identicou-se algumas diferenas entre os resultados de ConcernMetrics e os resultados obtidos a partir da anlise feita no cdigo fonte refatorado para aspectos. Essas divergncias, porm, foram justicadas porque nas verses refatoradas para aspectos foram feitas implementaes diferentes acrescentando ou retirando chamadas dos interesses do sistema, alm de tomarem decises de imple- mentao dos interesses em mais advices do que seriam necessrios para refatorao. A ferramenta ConcernMetrics estimou os valores corretos do clculo das mtricas CDC e CDO para o cdigo orientado por aspectos, analisando somente o cdigo fonte orientado por objetos, seguindo-se os algoritmos de deciso descritos no Captulo 4 e analisando os interesses atmicos conforme denido pelo Modelo de Concerns, ou seja, anlise de somente uma interesse sem inuncia de demais interesses que no estejam includos no Modelo de Concerns. A ferramenta ConcernMetrics possibilita a modelagem do Modelo de Concerns que serve para raciocinar sobre a separao de interesses de um sistema, calcula com eccia o grau de quanticao dos interesses selecionados no Modelo de Concers, possui 86 uma interface amigvel para clculo e visualizao do resultado dos clculos das mtricas, facilitando a avaliao dos valores de QD, SR, CDC e CDO para tomada de decises para refatorao de sistemas para orientao por aspectos. 5.3 Discusso Nesta seo, discutida a importncia da quanticao para a refatorao de interesses transversais em sistemas orientados por objetos para aspectos. analisado como essa quanticao possibilita uma avaliao feita diretamente no cdigo fonte original, sem a necessidade de qualquer alterao estrutural do sistema, possibilitando uma anlise do resultado que ser obtido previamente refatorao. De acordo com o resultado da mtrica de quanticao QD para os sistemas JAc- counting, JSpider e JHotDraw apresentados nas Tabelas 5, 6 e 7 respectivamente, pos- svel visualizar o valor quantitativo de cada interesse analisado. O sistema JAccouting contm um alto grau de quanticao, o sistema JSpider apresenta um grau de quanti- cao baixo e o sistema JHotDraw apresenta tambm um alto grau de quanticao. A quanticao um fator de avaliao importante para a deciso da refatorao de interesses transversais para aspectos. A anlise quantitativa apresentada no Captulo 3 mostra o clculo de mtricas de separao de interesses para sistemas orientados por aspectos. Quando seus resultados so analisados quantitativamente, demonstram valores que espelham os resultados reais da refatorao, ou seja, os sistemas que apresentaram me- lhor resultado da refatorao para aspectos, tambm apresentaram os melhores resultados da quanticao. Essa mesma interpretao feita a partir da anlise dos resultados obtidos da mtrica QD, onde mostra o grau de quanticao dos sistemas JAccouting, JSpider e JHotDraw. Esses resultados so compatveis com a anlise quantitativa feita baseada nas mtricas CDC e CDO. Outro fator para validao da quanticao como critrio de deciso da refatorao de sistemas para aspectos o clculo da mtrica SR. Este retorna o valor especco da reduo do espalhamento de cdigo pelo sistema, o qual um dos principais problemas causados pelos interesses transversais (KICZALES et al., 1997; SOMMERVILLE, 2006). importante ressaltar porm que a quanticao e a reduo do espalhamento no devem ser os nicos fatores a ser analisados na deciso de refatorao para aspec- tos de interesses transversais. Fatores como transformao de cdigo (MALTA; VALENTE, 87 2009), separao de interesses (SANTANNA et al., 2003), complexidade, entre outros, tam- bm devem ser avaliados, alm de necessidades especcas para cada projeto de software. Exemplos de situaes que no podem ser previstas so mostrados nos estudos de caso dos sistemas JSpider e JHotDraw. Nestes exemplos, alguns interesses transversais homogneos foram implementados em mais de um advice, enquanto poderiam ter sido modularizados atravs de um nico advice. Desta forma, a implementao feita resultou em um valor diferente do que a anlise de uma ferramenta baseada somente no cdigo fonte pudesse identicar. A anlise quantitativa porm se mostrou ecaz nos estudos de caso apresentados, resultando em valores similares aos comparados com a anlise feita diretamente no cdigo refatorado desses sistemas, assim como o clculo automatizado dessa quanticao em sistemas Java pela ferramenta ConcernMetrics. Isso mostra que a quanticao deve ser um requisito importante para a anlise da tomada de decises para a refatorao de sistemas para aspectos. 5.4 Consideraes Finais Neste captulo, foram apresentados os resultados de trs estudos de caso de sis- temas reais realizados para avaliao da aplicao das mtricas QD e SR propostas no Captulo 3, esses mesmos estudos de caso tambm serviram para a validao da ferra- menta ConcernMetrics. Nas avaliaes foram aplicadas manualmente as mtricas QD e SR nos sistemas JAccounting, JSpider e JHotDraw, os resultados obtidos foram com- parados com anlise quantitativa apresentada no Captulo 3, baseado na aplicao das mtricas de quanticao CDC e CDO nos sistemas orientados por objetos e tambm nas verses dos mesmos orientadas por aspectos. Atravs da ferramenta ConcernMetrics foram feitos os clculos para as mtricas QD e SR para os estudos de caso, o clculo das mtricas CDC e CDO para o cdigo orientado por objetos e tambm a estimativa dos valores destas mtricas caso o sistema fosse refatorado para aspectos. Esses resultados foram analisados separadamente e dis- cutidos nesse captulo divergncias encontradas. A ferramenta demonstrou eccia no clculo das mtricas, facilidade para a montagem do Modelo de Concerns e possibilita uma avaliao totalmente baseada no cdigo orientado por objetos sem a necessidade de nenhuma alterao estrutural do sistema. A partir das anlises manuais feitas para validao dos estudos de caso dessa dis- 88 sertao, constatou-se a real necessidade de ferramentas para automatizao do clculo de mtricas de software. Esse fato se justica pelo grau de diculdade encontrado para a inspeo manual dos sistemas JAccounting, JSpider e JHotDraw. Embora a ferramenta Eclipse facilite a identicao das chamadas de mtodos atravs da funcionalidade Call Hierarchy, ainda so necessrios diversos outros passos para o clculo das mtricas. necessria a avaliao dos join points, a denio dos interesses homogneos e heterog- neos, a anlise e deciso dos advices para modularizarem todos os join points, identicao de classes e mtodos que implementam e acessam determinado interesse, e nalmente o clculo das mtricas. A ferramenta ConcernMetrics mostrou eccia na automatizao do processo de anlise, denio e clculo de mtricas, baseado somente nos interesses identicados no Modelo de Concers e no cdigo fonte orientado por objetos. Desta forma, tornando mais fcil a avaliao quantitativa de sistemas orientados por objetos previamente refatorao para aspectos, alm de evitar possveis erros de avaliao e identicao de interesses transversais que podem ocorrer atravs de uma anlise manual. As discusses por sua vez abordam a importncia da quanticao para a tomada de decises para a refatorao de sistemas para aspectos, tambm discute fatores externos anlise quantitativa como decises de alterao estrutural de projeto no momento da refatorao, que podem inuenciar tanto quanto a quanticao nessa tomada de deciso. 89 6 CONCLUSES O paradigma de programao orientada por aspectos se consolida cada vez mais como a melhor tecnologia utilizada para separao e modularizao de interesses transver- sais. Esse fato pode se conrmar a partir de diversas pesquisas sobre o assunto, onde so relatados trabalhos sobre refatoraes orientadas a aspectos que descrevem como modu- larizar interesses transversais (BINKLEY et al., 2005, 2006; COLE; BORBA, 2005; LADDAD, 2006; MONTEIRO; FERN, 2006), e tambm trabalhos que apresentam estudos de caso so- bre a extrao e modularizao de interesses transversais por meio de aspectos (GARCIA et al., 2005; HANNEMANN; KICZALES, 2002; APEL; LEICH; SAAKE, 2006; FIGUEIREDO et al., 2008; KASTNER; APEL; BATORY, 2007; MENDHEKAR; KICZALES; LAMPING, 1997). No entanto, esses estudos, em geral, no abordam a questo sobre como decidir quando as refatoraes propostas iro trazer benefcios ao sistema. Nos trabalhos citados, observa-se que alguns apresentaram benefcios na refatorao, porm outros praticamente retiraram as chamadas do interesse do cdigo e foram transferidas para o aspecto, isso pode trazer diculdades para testes, manuteno, complexidade e inteligibilidade. Nesses trabalhos no foram feitas avaliaes prvias sobre os reais benefcios da refatorao e somente al- guns apresentaram uma avaliao aps o processo, o que poderia ter evitado o esforo da refatorao caso fosse constatado que no se obteria um resultado positivo. Para tratar da necessidade de anlise de projetos de refatorao para aspectos, alguns trabalhos so propostos com o intuito de avaliar as vantagens e desvantagens das refatoraes (SANTANNA et al., 2003; CECCATO; TONELLA, 2004; EADDY et al., 2008; LOPEZ-HERREJON; APEL, 2007; APEL, 2010; KULESZA et al., 2006; STEIMANN, 2006). Essas avaliaes so feitas em sua maioria atravs de mtricas de software e atributos especcos para aspectos. Tambm so utilizadas medidas comuns para projetos de soft- ware convencionais ou orientados por objetos que so aplicveis a sistemas orientados por aspectos. Nos estudos apresentados, poucos utilizam o conceito de quanticao, que conforme Filman e Friedman (2005) uma das caractersticas mais favorveis para a constatao da eccia da utilizao de aspectos. Outro fator a ser considerado nos tra- 90 balhos avaliados que esses, em sua maioria, so feitos com base no cdigo j refatorado para aspectos, nenhum se propondo a prever uma possvel avaliao prvia da refatorao totalmente feita com base no cdigo fonte original. A motivao principal para a pesquisa desenvolvida nesta dissertao surgiu a partir da observao de que trabalhos na rea de refatorao de interesses transversais dicilmente utilizavam-se de uma anlise para a avaliao do resultado da refatorao. O fator proposto para essa medida a quanticao, que uma medida imprescindvel quando se trata da modularizao de interesses transversais atravs de aspectos e que pouco utilizada nos trabalhos atuais de propostas de avaliaes destes. Alm disso, trabalhos feitos para prover essa avaliao no apresentam um resultado prvio migrao do sistema para aspectos, sendo necessrio dispensar tempo e esforo para o processo sem saber ao certo se essa refatorao pode ocasionar um resultado positivo ou negativo ao projeto. 6.1 Contribuies A quanticao permite aos desenvolvedores implementar atravs de um nico advice o cdigo espalhado em diversas posies estticas do sistema orientado por ob- jetos, desde que esses sejam interesses homogneos. Sendo assim, a quanticao um mecanismo chave para a avaliao e tomada de deciso da refatorao de sistemas para aspectos. A m de mais bem avaliar as vantagens da quanticao, foram propostas duas mtricas: Quantication Degree (QD) e Scattering Reduction (SR), que medem respecti- vamente o grau de quanticao e a reduo do espalhamento de cdigo de determinado interesse. Essas mtricas foram descritas e denidas formalmente e seu uso exemplicado utilizando-se sistemas reais. De acordo com estudos de caso se validou a eccia das mtricas para medir o grau de quanticao de interesses transversais. Como mais uma contribuio desta dissertao, foi implementada a ferramenta ConcernMetrics, um plugin para a ferramenta de desenvolvimento Java Eclipse, que cal- cula as mtricas QD e SR e tambm as mtricas de separao de interesse CDC e CDO. Esses clculos so feitos sem requerer a extrao fsica de interesses transversais do cdigo fonte para aspectos, com o intuito de ser utilizada para calcular antecipadamente as mtri- cas propostas de quanticao, fornecendo informaes para a avaliao das vantagens de usar aspectos em sistemas Java. Apresentou-se uma descrio do projeto desta ferramenta, 91 suas principais funcionalidades e as limitaes de sua atual implementao. A ferramenta ConcernMetrics foi utilizada para a avaliao em trs sistemas de mdio porte em Java, JAccounting, JSpider e JHotDraw. De acordo com pesquisas feitas, ConcernMetrics a primeira ferramenta que fornece estimativas de mtricas para anlise de cdigo orientado por aspectos, totalmente baseado no cdigo orientado por objetos. Com o apoio de ConcernMetrics, foram realizados estudos de caso envolvendo os sistema JSpider, JAccounting e JHotDraw. Foram aplicadas as mtricas QD e SR, CDC e CDO para o cdigo orientado por objetos e estimados os valores dessas mtricas para o cdigo orientado por aspectos. As principais lies aprendidas nesses estudos de caso so resumidas a sequir: os resultados obtidos evidenciam quanticao como uma medida imprescindvel para avaliao de extraes de interesses para aspectos; a partir da inspeo manual no cdigo dos sistemas, podem ocorrer erros na identi- cao de interesses transversais, alm do alto esforo necessrio para esse processo. O uso de uma ferramenta como a ConcernMetrics pode evitar essas situaes; a localizao de interesses transversais, assim como seus join points, em um sistema uma tarefa complexa e trabalhosa, alm disso a denio de advices que atendam todos os join points complexa e aberta a erros; mais uma vez o uso de uma ferramenta como a ConcernMetrics pode evitar esses possveis problemas. 6.2 Comparao com Outros Trabalhos A seguir sero apresentados trabalhos relacionados ao tema desta dissertao: 6.2.1 Mtricas de Software Orientado por Aspectos As mtricas de separao de interesses CDC e CDO, que foram utilizadas para avaliar os benefcios da quanticao apresentada no Captulo 3, foram propostas por SantAnna et al. (2003). Em outro trabalho, Garcia et al. (2005) utiliza as mtricas CDC e CDO para avaliar os benefcios dos aspectos na implementao de padres de projeto, alm disso props adaptaes para as mtricas de acoplamento e coeso do conjunto de mtricas CK (CHIDAMBER; KEMERER, 1994), que conforme as mtricas CDC e CDO, avaliam caractersticas especcas de um projeto j refatorado para aspectos. Esta dissertao 92 prope uma abordagem de anlise do grau de quanticao de interesses transversais, atravs das mtricas QD e SR, previamente a qualquer alterao estrutural do sistema. A mtrica CDA, proposta por Ceccato e Tonella (2004), utiliza o conceito de quanticao para medir o grau de espalhamento de um aspecto. Esta mtrica conta o nmero de mdulos afetados pelos pointcuts e pela introduo de um determinado aspecto. Porm ao se comparar a mtrica proposta QD com a mtrica CDA, verica-se que CDA no apresenta um comportamento relacionado a nenhum modelo de concerns. Alm disso, apresenta uma noo bsica sobre a quanticao baseada somente no cdigo orientado por aspectos. A mtrica QD, por sua vez, apresenta uma medida no intervalo de 0 e 1 para a medida do grau de quanticao com base no cdigo original do sistema, e um relacionamento atravs do Modelo de Concerns, possibilitando o mapeamento dos interesses transversais e o clculo da mtrica. A mtrica CRR uma mtrica proposta para avaliar sistemas em AspectJ, basica- mente mede o nmero de linhas de cdigo que poderia ser reduzido atravs da utilizao de aspectos (APEL, 2010) . Existem duas diferenas principais entre CRR e a mtrica SR: (1) em primeiro lugar CRR resulta o nmero de linhas de cdigo reduzidos baseado no cdigo orientado por aspectos, por outro lado, a mtrica SR conta o nmero de chamadas que sero reduzidas (menos um) do cdigo orientado por objetos. (2) em segundo lugar, CRR d um nmero nico e global para o sistema como um todo, enquanto a mtrica SR calculada para as preocupaes individuais previamente organizadas em um Modelo de Concerns hierrquico. 6.2.2 Avaliaes Orientadas por Aspectos Diversos trabalhos so realizados para validao da refatorao de softwares para aspectos utilizando-se as mtricas de separao de interesses e as mtricas adaptadas pelas mtricas CK (SANTANNA et al., 2003). Para estas validaes foram utilizados exemplos de padres de projeto (GARCIA et al., 2005; SANTANNA et al., 2003), manipulao de exceo (FILHO et al., 2006), sistemas de informao baseados na Web (KULESZA et al., 2006) e as linhas de produto de software (FIGUEIREDO et al., 2008). Em geral, em cada um destes estudos empricos foram identicados efeitos positivos e negativos da utilizao de aspectos. Na maioria dos estudos, as situaes em que eles no recomendam o uso de aspectos podem ser relacionados com um reduzido grau de quanticao. No trabalho de Kastner, Apel e Batory (2007), foram relatadas as experincias na refatorao de features da Oracle Berkeley DB para aspectos. Nesse trabalho, foi obser- 93 vado que os elementos extrados, em geral, apresentam um pequeno grau de quanticao. Alm disso, h o relato de que a maioria dos pointcuts denidos esto intimamente ligados ao programa base e, portanto, so especialmente frgeis s modicaes no programa. Foi analisado em Apel (2010) o uso de AspectJ em onze sistemas atravs das mtricas CIA, CRR, SDC, entre outras. Constatou-se que apenas 2% utilizam avanados mecanismos transversais, incluindo advices que afetam conjuntos inteiros de join points. Acredita-se que atravs da anlise das mtricas QD e SR, principalmente suportada pela ferramenta ConcernMetrics, seria possvel chegar s mesmas concluses sem extrair qualquer parte do interesse do cdigo original orientado por objetos. 6.2.3 Ferramentas A ferramenta ConcernTagger uma extenso da ferramenta ConcernMapper que calcula as mtricas de disperso, incluindo CDC, CDO e DOSC e DOSM j anteriormente mencionadas (EADDY et al., 2008). No entanto, pelo menos na sua verso atual, as mtricas so medidas apenas para o cdigo orientado por objetos. Por outro lado, uma caracterstica marcante da ferramenta ConcernMetrics sua habilidade de inferir os valores de QD e SR relativos a uma eventual refatorao do cdigo para aspecto. Calcula ainda os valores de CDC e CDO para o cdigo orientado por objetos e estimar os valores dessas mtricas para o cdigo orientado por aspectos, sendo esses clculos baseados totalmente no cdigo fonte orientado por objetos e sem nenhuma alterao estrutural do sistema. 6.3 Trabalhos Futuros Com o objetivo de validar as mtricas de quanticao QD e SR, prope-se a realizao de novas avaliaes aplicando-as a mais estudos de caso de sistemas reais que apresentem diferentes cenrios de interesses transversais, podendo-se utilizar a ferramenta ConcernMetrics. Essas avaliaes podero validar a eccia das mtricas QD e SR, alm de possibilitar a evoluo da ferramenta ConcernMetrics. Sugere-se ainda a incorporao ferramenta ConcernMetrics o clculo de outras mtricas para avaliao de sistemas orientados por aspectos j difundidas, como CLC (GARCIA et al., 2005), DOSM e DOSC (EADDY et al., 2008). A partir de CLC ser obtido o nmero de linhas que implementam um determinado interesse, e atravs de DOSC e DOSM ser possvel uma viso do grau de distribuio do interesse entre as classes 94 e mtodos do sistema. Essas mtricas podero ser calculadas a partir do cdigo fonte orientado por objetos e podero ser estimados os seus valores para o cdigo orientado por aspectos. Alm disso, prope-se o plano de integrao de ConcernMetrics com a ferramenta TransformationMapper, proposta por Malta, Oliveira e Valente (2009), que fornece infor- maes sobre transformaes necessrias ao cdigo orientado por objetos para permitir a extrao de aspectos. Atravs dessa integrao, a ferramenta ConcernMetrics ir avaliar tambm transformaes necessrias para a refatorao de um determinado interesse para aspectos para a estimativa de advices necessrios para essa modularizao. Finalmente, em outro estudo, sugere-se abordar a correlao, caso seja possvel, entre fragilidade de um pointcut e altos valores de QD. Dessa forma, poderia-se vericar se a fragilidade de pointcuts, ou seja, a exposio a impacto dos pointcuts por alteraes no cdigo funcional orientado por objetos, alta quando existem altos valores de QD. 95 REFERNCIAS ANBALAGAN, P.; XIE, T. Automated inference of pointcuts in aspect-oriented refactoring. In: ICSE 07: Proceedings of the 29th international conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. p. 127136. APEL, S. How aspectj is used: An analysis of eleven aspectj programs. Journal of Object Technology, v. 9, n. 1, p. 117142, jan. 2010. APEL, S.; LEICH, T.; SAAKE, G. Aspectual mixin layers: aspects and features in concert. ACM, New York, NY, USA, p. 122131, 2006. BINKLEY, D. et al. Automated refactoring of object oriented code into aspects. IEEE Computer Society, Washington, DC, USA, p. 2736, 2005. BINKLEY, D. et al. Tool-supported refactoring of existing object-oriented code into aspects. IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 32, p. 698717, September 2006. BRUNETON, E.; LENGLET, R.; COUPAYE, T. ASM: A code manipulation tool to implement adaptable systems. Grenoble, France, november 2002. CECCATO, M. Automatic support for the migration towards aspects. In: CSMR 08: Proceedings of the 2008 12th European Conference on Software Maintenance and Reengineering. Washington, DC, USA: IEEE Computer Society, 2008. p. 298301. CECCATO, M.; TONELLA, P. 1st workshop on aspect reverse engineering (ware 2004). Measuring the eects of software aspectization, 2004. CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 20, p. 476493, June 1994. COLE, L.; BORBA, P. Deriving refactorings for aspectj. In: Proceedings of the 4th international conference on Aspect-oriented software development. New York, NY, USA: ACM, 2005. (AOSD 05), p. 123134. EADDY, M. et al. Do crosscutting concerns cause defects? IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 34, p. 497515, July 2008. EJIOGU, L. O. Software engineering with formal metrics. Wellesley, MA, USA: QED Information Sciences, Inc., 1991. FENTON, N. Software measurement: A necessary scientic basis. IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 20, p. 199206, March 1994. FENTON, N. E.; NEIL, M. Software metrics: success, failures and new directions. J. Syst. Softw., Elsevier Science Inc., New York, NY, USA, v. 47, p. 149157, July 1999. 96 FIGUEIREDO, E. et al. Evolving software product lines with aspects: an empirical study on design stability. ACM, New York, NY, USA, p. 261270, 2008. FIGUEIREDO, E. et al. Crosscutting patterns and design stability: An exploratory analysis. Proc. of Intl Conf. on Program Comprehension (ICPC), Vancouver, Canada, p. 138147, 2009. FIGUEIREDO, E.; WHITTLE, J.; GARCIA, A. F. Concernmorph: metrics-based detection of crosscutting patterns. In 7th International Symposium on Foundations of Software Engineering (FSE), p. 299300, 2009. FILHO, F. C. et al. Exceptions and aspects: the devil is in the details. ACM, New York, NY, USA, p. 152162, 2006. FILMAN, R. E.; FRIEDMAN, D. P. Aspect-oriented programming is quantication and obliviousness. In: FILMAN, R. E. et al. (Ed.). Aspect-Oriented Software Development. Boston: Addison-Wesley, 2005. p. 2135. FOWLER, M. et al. Refactoring: improving the design of existing code. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999. GARCIA, A. et al. Assessment of contemporary modularization techniques - acom07: workshop report. SIGSOFT Softw. Eng. Notes, ACM, New York, NY, USA, v. 32, n. 5, p. 3137, 2007. GARCIA, A. et al. Modularizing design patterns with aspects: a quantitative study. ACM, New York, NY, USA, p. 314, 2005. GRADECKI, J. D.; LESIECKI, N. Mastering AspectJ: Aspect-Oriented Programming in Java. New York, NY, USA: John Wiley Sons, Inc., 2003. GREENWOOD, P. et al. On the impact of aspectual decompositions on design stability: An empirical study. In: ERNST, E. (Ed.). ECOOP. Berlin, Germany: Springer, 2007. (Lecture Notes in Computer Science, v. 4609), p. 176200. HALL, T.; FENTON, N. Implementing eective software metrics programs. IEEE Softw., IEEE Computer Society Press, Los Alamitos, CA, USA, v. 14, p. 5565, March 1997. HANNEMANN, J.; KICZALES, G. Design pattern implementation in java and aspectj. ACM, New York, NY, USA, p. 161173, 2002. HARRISON, R.; COUNSELL, S. J.; NITHI, R. V. An evaluation of the mood set of object-oriented software metrics. IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 24, p. 491496, June 1998. HILSDALE, E.; HUGUNIN, J. Advice weaving in aspectj. ACM, New York, NY, USA, p. 2635, 2004. IRWIN, J. et al. Aspect-oriented programming of sparse matrix code. Springer-Verlag, London, UK, p. 249256, 1997. 97 KANER, C.; MEMBER, S.; BOND, W. P. Software engineering metrics: What do they measure and how do we know? 2004. KASTNER, C.; APEL, S.; BATORY, D. A case study implementing features using aspectj. IEEE Computer Society, Washington, DC, USA, p. 223232, 2007. KICZALES, G.; HILSDALE, E. Aspect-oriented programming. In: ESEC/FSE-9: Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering. New York, NY, USA: ACM, 2001. p. 313. KICZALES, G. et al. An overview of aspectj. In: ECOOP 01: Proceedings of the 15th European Conference on Object-Oriented Programming. London, UK: Springer-Verlag, 2001. p. 327353. KICZALES, G. et al. Aspect-oriented programming. In 11th European Conference Object-Oriented Programming (ECOOP), v. 1241, p. 220242, 1997. KULESZA, U. et al. Quantifying the eects of aspect-oriented programming: A maintenance study. IEEE Computer Society, Washington, DC, USA, p. 223233, 2006. LADDAD, R. AspectJ in Action: Practical Aspect-Oriented Programming. Greenwich, CT, USA: Manning Publications Co., 2003. ISBN 1930110936. LADDAD, R. Aspect Oriented Refactoring. Greenwich: Addison-Wesley Professional, 2006. LOPEZ-HERREJON, R. E.; APEL, S. Measuring and characterizing crosscutting in aspect-based programs: basic metrics and case studies. Berlin, Heidelberg: Springer-Verlag, 2007. 423437 p. (FASE07). LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994. MALTA, M. N.; OLIVEIRA, S. d.; VALENTE, M. T. Guidelines for enabling the extraction of aspects from existing object-oriented code. Jornal Of Object Technology - JOT, v. 8, n. 3, p. 101 119, May - June 2009. MALTA, M. N.; VALENTE, M. T. Object-oriented transformations for extracting aspects. Information and Software Technology, v. 51, p. 138 149, May - June 2009. MARIN, M. et al. An integrated crosscutting concern migration strategy and its semi-automated application to jhotdraw. Automated Software Engg., Kluwer Academic Publishers, Hingham, MA, USA, v. 16, n. 2, p. 323356, 2009. MARIN, M.; DEURSEN, A. V.; MOONEN, L. Identifying crosscutting concerns using fan-in analysis. ACM Trans. Softw. Eng. Methodol, ACM, New York, NY, USA, v. 17, n. 1, p. 137, 2007. MENDHEKAR, A.; KICZALES, G.; LAMPING, J. Rg: A case-study for aspect-oriented programming. Palo Alto, CA 94304, p. 2133, feb 1997. 98 MONTEIRO, M. P.; FERN, J. M. Towards a catalogue of refactorings and code smells for aspectj. In T. Aspect-Oriented Software Development I, Portugal, p. 214258, 2006. PARK, R. E.; GOETHERT, W. B.; FLORAC, W. A. Goal Driven Software Measurement - A Guidebook. Pittsburgh, PA 15213: Software Engineering Institute, Carnegie Mellon University, 1996. PRESSMAN, R. Software Engineering: A Practitioners Approach. 6. ed. New York, NY, USA: McGraw-Hill, Inc., 2005. ROBILLARD, M. P.; WEIGAND-WARR, F. Concernmapper: simple view-based separation of scattered concerns. ACM, New York, NY, USA, p. 6569, 2005. ROCHE, J. M. Software metrics and measurement principles. SIGSOFT Softw. Eng. Notes, ACM, New York, NY, USA, v. 19, p. 7785, January 1994. SANTANNA, C. et al. On the reuse and maintenance of aspect-oriented software: An assessment framework. In 17th Brazilian Symposium on Software Engineering (SBES), p. 1934, 2003. SOMMERVILLE, I. Software Engineering: (Update) (8th Edition) (International Computer Science Series). Redwood City, CA, USA: Addison Wesley Longman Publishing Co., Inc., 2006. STEIMANN, F. The paradoxical success of aspect-oriented programming. SIGPLAN Not., ACM, New York, NY, USA, v. 41, n. 10, p. 481497, 2006. TIRELO, F. et al. Desenvolvimento de software orientado por aspectos. In: MARTINS., A. A. A. T. (Ed.). XXIII Jornada de Atualizao em Informtica (JAI). Salvador, BA: Sociedade Brasileira de Computao, 2004. v. 2, p. 5796.