EH-Meter – Uma Ferramenta para Coleta de Métricas de
Tratamento de Exceções
Júlio César Taveira1, Fernando Castor2, Sergio Soares1,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
{jcft2, scbs}@dsc.upe.br, [email protected]
Resumo
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
programas escritos em diferentes linguagens de programação. Por exemplo, Metrics1 e
FindBugs2 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
AOPMetrics3, 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 EHMeter 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
1
http://metrics.sourceforge.net/
2
http://findbugs.sourceforge.net/
3
http://aopmetrics.tigris.org/
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 Ant4.
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
http://ant.apache.org/
Tabela 1. Resumo das métricas, grupos e respectivas descrições.
Group
Métricas
de
Tamanho
Metric
Description
LOCC
Lines of Common Code: Linhas de código do sistema, excluindo-se comentários e linhas em
branco.
NOT
Number of Try blocks: Número de blocos try.
NOC
Number of Catch blocks: Número de blocos catch.
NOF
Number of Finally blocks: Número de blocos finally.
LOCEH
Métricas
de
Interesse
s
Lines of Exception Handling Code: Linhas de código relativo ao o tratamento de exceções.
NEH
Number of Exception Handlers: Número de blocos de código relativo ao tratamento de
exceções.
CDC
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.
CDO
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.
CDLOC
LOF
DOS
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
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
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.
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 1. Diagrama de Interação
entre pacotes.
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].
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, http://www.dsc.upe.br/~jcft2/eh-meter, 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 152–162.
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 1st ACoM Workshop.
Eaddy, M. et al. (2008), “Do Crosscutting Concerns Cause Defects?”, In: IEEE
Transactions on Software Engineering (34):July 2008, pp. 497-515.
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: 11th ECOOP.
Laddad, R. (2003), “AspectJ in Action”, 1st 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 418-427.
Robillard, M. P.; Murphy, G. C. (2002), “Concern graphs: finding and describing
concerns using structural program dependencies”, In: Proc. of the 24th 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”, 8th ed., Addison-Wesley.
Taveira, J. C. et al. (2009) “Assessing Intra-Application Exception Handling Reuse with
Aspects”. Submitted to SBES'2009.