EH-Meter Uma Ferramenta para Coleta de Métricas de Tratamento de Exceções

Transcrição

1 EH-Meter Uma Ferramenta para Coleta de Métricas de Tratamento de Exceções Júlio César Taveira 1, Fernando Castor 2, Sergio Soares 1,2 1 Departamento de Sistemas e Computação Universidade de Pernambuco (UPE) Recife PE Brasil 2 Centro de Informática Universidade Federal de Pernambuco (UFPE) Recife PE Brasil Resumo {jcft2, scbs}@dsc.upe.br, castor@cin.ufpe.br A maioria das ferramentas de coleta de métricas existentes não contemplam linguagens de programação orientadas a aspectos e adicionalmente, implementam métricas genéricas, nem sempre ideais para avaliar atributos de qualidade relativos a interesses específicos do sistema. Este trabalho apresenta uma ferramenta que coleta métricas referentes ao interesse de tratamento de exceções em sistemas escritos nas linguagens Java e AspectJ. A ferramenta proposta foi utilizada na coleta de métricas em vários sistemas escritos nessas duas linguagens. Abstract Most of the existing metrics collection tools do not cover aspect-oriented programming languages. In addition, these tools implement generic metrics, not always appropriate to evaluate quality attributes pertaining to specific system concerns. This work presents a metrics collection tools specifically targeting the exception handling concern and capable of working with both Java and AspectJ programs. The proposed tool was employed to measure a number of software systems written in both languages. 1. Introdução Métricas estáticas de código são amplamente utilizadas para avaliar atributos de qualidade de sistemas de software [Sommerville 2007]. Métricas de código podem fornecer desde informações básicas, como número de linhas de código e de módulos no sistema, até informações mais refinadas como as dependências entre os elementos do sistema e o quão focados esses elementos são [Ceccato e Tonella 2004, Eaddy et al. 2007]. Idealmente, métricas de código devem ser coletadas de maneira automática, a fim de acelerar o processo de medição, evitar os erros inerentes à coleta manual e garantir a uniformidade dos resultados, tornando possível a realização de comparações. Existem diversas ferramentas capazes de coletar métricas estáticas de código a partir de

2 programas escritos em diferentes linguagens de programação. Por exemplo, Metrics 1 e FindBugs 2 coletam diversas métricas a partir de programas escritos em Java. Apesar da crescente popularidade da programação orientada a aspectos (POA) [Kiczales et al. 1997], há poucas ferramentas de coleta de métricas capazes de medir programas escritos em linguagens de POA. Um exemplo de tais ferramentas é o AOPMetrics 3, que coleta métricas de programas em AspectJ [Laddad 2003], uma extensão orientada a aspectos da linguagem Java. Para que POA possa se consolidar como o próximo passo na evolução das linguagens de programação, essa técnica precisa ser avaliada exaustivamente, idealmente tanto qualitativa quanto quantitativamente. Até onde foi possível averiguar, todas as ferramentas de coleta de métricas existentes trabalham com métricas gerais, aplicáveis a todos os interesses (do inglês: concerns) de um sistema. Consequentemente, não é possível avaliar alguns atributos de qualidade no contexto de interesses específicos. Entretanto, alguns autores [Castor et al. 2009, Eaddy et al. 2008, Couto et al., 2009] acreditam que, para avaliar o impacto de novas abordagens de desenvolvimento, como POA, em atributos de qualidade como reuso, métricas focadas em interesses específicos são mais eficazes do que as independentes de interesse. Utilizar apenas métricas que se aplicam ao sistema como um todo, sem levar em conta os interesses que o compõem, pode fazer com que a avaliação de tais abordagens não reflita adequadamente seus benefícios e limitações. Este trabalho propõe uma ferramenta de coleta de métricas que visa preencher parcialmente essa lacuna. A ferramenta proposta, chamada de EH-Meter, é capaz de coletar 11 métricas descritas em diferentes trabalhos na literatura [Eaddy et al. 2007, Sant Anna et al. 2003] a partir de programas escritos em Java ou AspectJ. Dez dessas métricas lidam com um interesse específico, tratamento de exceções. O interesse de tratamento de exceções foi escolhido por dois motivos: (i) é o alvo de vários trabalhos realizados pelos autores no passado; e (ii) é um interesse demarcado sintaticamente no código do programa, o que evita dificuldades ligadas à mineração de interesses [Robillard e Murphy 2002] e permite que o foco se mantenha na atividade de medição. 2. Funcionalidades Nessa seção são descritas as métricas que foram implementadas e maneira como o EH- Meter pode ser utilizado na prática. Métricas Implementadas. O EH-Meter é capaz de colher diversas métricas relativas ao interesse de tratamento de exceções. As métricas escolhidas são divididas em dois grupos: métricas de tamanho e métricas de interesses. O primeiro grupo engloba diversas métricas que visam determinar a quantidade de código em um sistema relativa ao interesse de tratamento de exceções. Para tanto, inclui desde métricas tradicionais, como numero de linhas de código (tanto total quanto especificamente de tratamento de exceções) e outras menos comuns, como números de blocos catch e finally. Essas métricas são apresentadas e descritas na parte superior da tabela Tabela 1. Para as métricas NOT, NOC e NOF, caso o bloco try (catch, finally) apareça dentro de outro bloco catch ou finally (mas não try), ele não é levado em conta. A

3 justificativa para isso é que, para fins de separação de interesses, tal bloco não precisaria ser separado pois não está misturado a outros interesses. O outro grupo de métricas, relativas a separação de interesses, tem o intuito de medir o quanto o código está direcionado aos interesses analisados, que no caso desse trabalho é o tratamento de exceções, e separado do código relativo aos outros interesses do sistema. Essas métricas são também apresentadas na Tabela 1, na parte inferior. As três primeiras delas mostram valores absolutos, para os valores coletados. As duas últimas métricas relativas a interesses contabilizam de forma normalizadas os valores apresentados. Para todas as métricas, um valor menor implica em um resultado melhor. Execução e Resultados da Ferramenta. Do mesmo modo que a ferramenta AopMetrics, a ferramenta EH-Meter também funciona através de tasks do Apache Ant 4. Através de um arquivo de configurações XML é especificado quais serão os programas Java que a ferramenta vai analisar, quais as bibliotecas que devem ser utilizadas como referência, versão da linguagem e o nome do arquivo de saída. Arquivo de saída produzido pela ferramenta é uma planilha eletrônica no padrão do Microsoft Excel. Essa planilha contém, para cada componente do sistema, o valor de cada uma das métricas, descritas na Seção 2.1. Apenas a métrica DOS depende do sistema completo. 3. Implementação O EH-Meter é uma extensão da ferramenta AopMetrics. Para facilitar a implementação do EH-Meter, recursos como os parsers para Java e AspectJ o engenho de coleta de métricas do AopMetrics foram utilizados. Para a maior parte das métricas, foi necessário apenas implementar as classes responsáveis pelas novas métricas. Algumas delas, porém, exigem que a medição seja feita de um modo diferente do que tradicionalmente acontece no AopMetrics, levando em conta o sistema como um todo. Para estes casos, foi necessário modificar o engenho de medição do AopMetrics. Arquitetura e Modificações no Código Original. A arquitetura da ferramenta é simples, dividida em módulos (pacotes) com propósitos bem definidos. No pacote principal se encontram o código responsável por receber entradas do usuário para execução da ferramenta e outros recursos comuns a toda a ferramenta, como o engenho de coleta de métricas. Em outros pacotes, source e ajdt, são encontrados elementos que fazem referência a um projeto Java e AspectJ e transformações necessárias, respectivamente. O pacote metrics contém as classes que implementam as métricas a serem coletadas. A maior parte das alterações aplicadas ao AopMetrics resultaram em novas classes sendo incluídas neste pacote. Os últimos pacotes, export e results, contém o código responsável por exportar os resultados da medição para planilhas em formato XLS e como são as saídas das métricas. A Figura 1 mostra as dependências entre os pacotes do sistema. 4

4 Tabela 1. Resumo das métricas, grupos e respectivas descrições. Group Metric Description Métricas de Tamanho Métricas de Interesse s LOCC NOT NOC NOF LOCEH NEH CDC CDO CDLOC LOF Lines of Common Code: Linhas de código do sistema, excluindo-se comentários e linhas em branco. Number of Try blocks: Número de blocos try. Number of Catch blocks: Número de blocos catch. Number of Finally blocks: Número de blocos finally. Lines of Exception Handling Code: Linhas de código relativo ao o tratamento de exceções. Number of Exception Handlers: Número de blocos de código relativo ao tratamento de exceções. Concern Diffusion over Component [Sant Anna et al 2003]: Conta o número de componentes (classes, aspectos, interfaces) que incluem código de tratamento de exceções. Concern Diffusion over Operation [Sant Anna et al 2003]: Conta o número de operações (métodos, advices) que incluem código de tratamento de exceções. Concern Diffusion over Lines of Code [Sant Anna et al 2003]: Conta o número de pontos de transição para cada interesse através das linhas de códigos. O uso dessa métrica necessita do processo de sombreamento dentro do código, com áreas sombreadas e áreas não-sombreadas. Lack of Focus: Essa é a medição da perda de foco de cada componente, para todos os interesses. O resultado é normalizado entre 0 (completamento focado) e 1 (completamente sem foco). O resultado dessa métrica é obtido a partir do valor da métrica DOF (Degree of Focus) [Eaddy et al. 2007]. LOF = 1 DOF DOS Degree of scattering [Eaddy et al. 2007]: Essa métrica mede a variação de concentração de um interesse por todos os componentes. O resultado é normalizado entre 0 (completamento localizado) e 1 (completamente distribuído). A primeira modificação para dar suporte às novas métricas diz respeito a como é calculado o valor para cada uma. Normalmente, as medições são executadas individualmente para cada componente (classe, interface e aspecto). Assim, cada métrica é executada uma vez para cada componente, retorna o valor resultante e a execução prossegue para o próximo componente, sem um valor intervir no outro. A métrica DOS, porém, é calculada para todos os componentes do sistema. Logo, foi necessário levar em conta os valores relativos a cada componente do sistema para poder fazer o calculo da métrica. Esse comportamento precisou ser incorporado ao engenho de coleta do AopMetrics, já que este é construído partindo da suposição de que todas as métricas podem ser coletadas de forma independente, para cada componente. A segunda modificação diz respeito à listagem de todas as métricas. A classe Metrics contém todas as métricas que devem ser coletadas. Para o EH-Meter, foram adicionadas as novas métricas implementadas e suas respectivas strings de identificação. Ponto comum entre todas as métricas as métricas é a interface MetricsCalculator. Entretanto, essa interface é aplicável apenas para métricas que não precisam ser coletadas globalmente. Logo, a ultima modificação consistiu na criação de uma interface para abranger as métricas que sejam calculadas utilizando dados de todo o sistema. Essa interface foi denominada de MetricsCalculatorGeneral e pode ser usada na implementação de novas métricas com essa característica. Novas Métricas. Para as novas métricas implementadas na maioria dos casos foi extendida a classe ASTVisitor, para detectar ocorrências de trechos de código relativos ao tratamento de exceções. Esses trechos de código na maioria dos casos foram ocorrências de blocos try (catch, finally), declarações de método e blocos de código. Para as métricas de tamanho (mostradas na Tabela 1), os resultados foram são

5 obtidos apenas através da contagem das ocorrências do pedaço de código desejado. Para métricas de interesses, interfaces não foram consideradas por não incluírem comportamento, sendo apenas analisadas classes e aspectos. CDC e CDO foram bem simples, bastando apenas marcar para cada componente e operação, respectivamente, a existência de haver códigos tratadores de exceções. Para LOF (medida utilizando DOF) e DOS, apenas foi necessário utilizar informações de outras métricas e trabalhar corretamente com os valores. A Métrica CDLOC é a que apresenta a implementação mais complexa. Em todos os trabalhos anteriores dos quais temos conhecimento [Castor Filho et al. 2006, Castor et al. 2009, Garcia et al. 2005, Sant'Anna et al. 2003], essa métrica foi coletada manualmente. A Figura 2 mostra um exemplo de como é diferenciado as áreas de transições entre o interesse do tratamento de exceção (fundo amarelo) e o interesse de comportamento normal do sistema (fundo branco). Na implementação, foi necessário detectar e marcar essas áreas, a fim de calcular as transições. Para essa métrica, têm que ser levados em conta diversos casos de transição entre o código referente ao tratamento de exceções e o código relativo ao comportamento normal do sistema. Figura 1. Diagrama de Interação entre pacotes. public static void example() { System.out.println("Starting!"); try{...//código que pode levantar exceção }catch (Exception e){...//código que trata a exceção; } System.out.println("Step 1 end!"); try{...//código que pode levantar exceção }catch (Exception e2){...//código que trata a exceção; } } Figura 2. Exemplo de código com suas transições. 4. Um Estudo de Caso Atualmente, está sendo conduzido um estudo com o objetivo de identificar o efeito da modularização de tratamento de exceções usando POA no reuso do código desse interesse. Neste novo estudo, o EH-Meter é usado em todas as atividades de medição. Foram utilizados três sistemas, em versões Java e AspectJ, com diferentes características. No total, as medições foram aplicadas a nove versões distintas, 3 em AspectJ e 6 em Java. Enquanto a medição manual feita por dois desenvolvedores durou cerca de 16 horas para apenas uma das versões, a ferramenta coletou as informações em menos de um minuto. Além disso, a ferramenta foi empregada diversas vezes para refazer as medições de forma rápida. Adicionalmente, a contagem manual apresentou problemas de uniformidade que não ocorreram com a ferramenta. O emprego de métricas centradas em um interesse ressaltou que POA de fato promove o reuso de tratadores de exceções. Também deixou claro que o código de tratamento de exceções cresce de maneira não desprezível quando extraído para aspectos em um sistema não-trivial. A combinação dessas duas descobertas complementa estudos anteriores [Castor Filho et al. 2006, Lippert e Lopes 2000] sobre POA e tratamento de exceções. Mais informações sobre esse estudo podem ser obtidas em outro trabalho [Taveira et al. 2009].

6 5. Conclusão Neste trabalho foi apresentada a ferramenta EH-Meter, que implementa métricas específicas de tratamento de exceções. Foram descritas as métricas implementadas pela ferramenta, bem como sua arquitetura e as principais escolhas de projeto envolvidas no seu desenvolvimento. O EH-Meter é capaz de coletar métricas tanto a partir de programas escritos em Java quanto de programas em AspectJ. Até onde pudemos averiguar, o EH-Meter é a primeira ferramenta capaz de coletar métricas para um interesse específico de forma completamente automática. No Endereço, a ferramenta EH-Meter está disponível. No mesmo endereço também está disponível o código fonte e também outras informações. A licença do EH-Meter é a GPL. Referências Castor Filho, F. et al. (2006), Exceptions and aspects: The devil is in the details, In: 14th SIGSOFT FSE, pages Castor, F. et al. (2009), On the Modularization and Reuse of Exception Handling with Aspects. Submitted to Software Practice & Experience. Ceccato, M. and Tonella P. (2004), Measuring the Effects of Software Aspectization, In: 1st Workshop on Aspect Reverse Engineering (WARE 2004). Couto, C. F. M. et al. (2009), Estimativa de Métricas de Separação de Interesses em Processos de Refatoração para Extração de Aspectos., In: VI Workshop de Manutenção de Software Moderna, Ouro Preto. p. 1-8 Eaddy, M., Aho, A., Murphy, G. C. (2007), Identifying, Assigning, and Quantifying Crosscutting Concerns, In: Proceedings of the 1 st ACoM Workshop. Eaddy, M. et al. (2008), Do Crosscutting Concerns Cause Defects?, In: IEEE Transactions on Software Engineering (34):July 2008, pp Garcia, A. et al. (2005), Modularizing Design Patterns with Aspects: A Quantitative Study, In: 4th AOSD. Kickzales, G. et al. (1997), Aspect-Oriented Programming, In: 11 th ECOOP. Laddad, R. (2003), AspectJ in Action, 1 st ed., Manning. Lippert, M.;Lopes, C. (2000), A study on exception detection and handling using aspect-oriented programming, In: Proceedings of the 22nd ICSE, pages Robillard, M. P.; Murphy, G. C. (2002), Concern graphs: finding and describing concerns using structural program dependencies, In: Proc. of the 24 th ICSE. Sant'Anna, C. et al. (2003), On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework, In: XVII SBES, Manaus, Brazil. Sommerville, I. (2007), Software Engineering, 8 th ed., Addison-Wesley. Taveira, J. C. et al. (2009) Assessing Intra-Application Exception Handling Reuse with Aspects. Submitted to SBES'2009.