PONTIFCIA UNIVERSIDADE CATLICA DE MINAS GERAIS

Programa de Ps-Graduao em Informtica

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.