ads:
Universidade de Pernambuco
Escola Polit´ecnica de Pernambuco
Departamento de Sistemas e Computa¸c˜ao
Programa de P´os-Gradua¸c˜ao em Engenharia da Computa¸c˜ao
J´ulio C´esar de Freitas Taveira
Reuso de Tratadores de Exce¸c˜oes em
Programas Orientados a Aspectos
Recife, abril de 2010
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE DE PERNAMBUCO
DEPARTAMENTO DE SISTEMAS E COMPUTAC¸
˜
AO
PROGRAMA DE P
´
OS-GRADUAC¸
˜
AO EM ENGENHARIA DA COMPUTAC¸
˜
AO
J
´
ULIO C
´
ESAR DE FREITAS TAVEIRA
Reuso de Tratadores de Exce¸c˜oes em
Programas Orientados a Aspectos
Disserta¸c˜ao apresentada como requisito parcial
para a obten¸c˜ao do grau de Mestre em
Engenharia da Computa¸c˜ao
Prof. Dr. Fernando Jos´e Castor de Lima
Filho
Orientador
Prof. Dr. S´ergio Castelo Branco Soares
Co-orientador
Recife, abril de 2010
ads:
CIP – CATALOGAC¸
˜
AO NA PUBLICAC¸
˜
AO
Taveira, J´ulio C´esar de Freitas
Reuso de Tratadores de Exce¸c˜oes em Programas Orien-
tados a Aspectos / J´ulio C´esar de Freitas Taveira. – Recife:
PPGEC da UPE, 2010.
75 f.: il.
Disserta¸c˜ao (mestrado) – Universidade de Pernambuco.
Programa de P´os-Gradua¸c˜ao em Engenharia da Computa¸c˜ao,
Recife, BR–PE, 2010. Orientador: Fernando Jos´e Castor de
Lima Filho; Co-orientador: S´ergio Castelo Branco Soares.
1. Tratamento de exce¸c˜oes. 2. Reuso. 3. Aspectos. I. Fer-
nando Jos´e Castor de Lima Filho, . II. S´ergio Castelo Branco
Soares, . III. T´ıtulo.
Dedico esse trabalho ao meu irm˜ao, que me viu come¸car, mas n˜ao est´a presente na
minha conclus˜ao.
Tamb´em dedico esse trabalho `a ´area de Engenharia de Software e a todos os
desenvolvedores. Lembro-me dos meus primeiros c´odigos de programa¸c˜ao, ainda
adolescente, usando apenas um livro emprestado, em um 486DX2 com 80MB de
HD, 4MB de mem´oria e interpretando no QBasic.
Agradecimentos
Sei que n˜ao vou conseguir lembrar de todos para essa dedicat´oria, mas vou tentar
lembrar. Vou utilizar uma ordem para me ajudar.
Primeiramente a Deus, pela oportunidade da vida, sa´ude, inteligˆencia e situa¸c˜oes
que aconteceram em minha vida, para eu poder chegar at´e aqui. Com todos dos
desafios de vida, consegui chegar. As pessoas que est˜ao perto dele agora, que at´e
pouco tempo estava junto conosco.
Aos meus pais, Severino Taveira e M
a
Betˆania. Principalmente a minha m˜ae
que me incentivou em tudo e me dando sempre apoio em todas as decis˜oes que eu
tomei, em todos os momentos. Deixando-me livre `a fazer minhas escolhas e apenas
intervindo em momentos de conselhos e corrigindo meu prumo, quando necess´ario.
Aos meus irm˜aos mais pr´oximos, Caio e Jo˜ao Lucas e outros dois mais distantes,
Enzo e M
a
Vit´oria.
A minha av´o, tios, tias e primos. Dando me for¸ca desde o dia da inscri¸c˜ao, as
minhas primas Bl´e e Georgina (ainda doutoranda em Eng. El´etrica). Aos meus
amigos da vida, que sempre me incentivando e algumas vezes tendo em mim um
exemplo de estudo e competˆencia. Tamb´em aos amigos que encontrei no ˆambito de
trabalho, hoje podendo contar com alguns em qualquer hora, sempre conversando e
eu possuindo carinho e respeito, tanto no lado pessoal quanto profissional.
No ˆambito acadˆemico, inicialmente a Universidade de Pernambuco e ao Depar-
tamento de Sistemas e Computa¸c˜ao. Local onde fiz minha gradua¸c˜ao e aqui concluo
meu mestrado acadˆemico. A todos os professores com quem tive o prazer de ter
aula. Tanto aos existentes hoje no departamento, quanto aos egressos. Tamb´em
aos membros participantes do departamento. Alguns nomes n˜ao posso deixar de
citar, como Carlos Alexandre, M´arcio Corn´elio, Tiago Massoni,..., e Ana Georgina
(Secret´aria da P´os).
Agora a quem est´a diretamente ligado ao meu mestrado. Em primeiro ao meu
orientador, Fernando Castor. Mesmo antes de fazer minha inscri¸c˜ao, n˜ao o conhecia
mas j´a hav´ıamos tido a primeira conversa e vi que seria uma boa o trabalho proposto.
Ao meu co-orientador, S´ergio Soares, que roncou muito no SBES’09, mas tamb´em
n˜ao deixei por menos. Agrade¸co ao acompanhamento, sugest˜oes, ajuda e orienta¸c˜ao
dos dois, que me fizeram finalizar o mestrado, de uma forma at´e tranquila.
N˜ao poderia deixar de fora os meus colegas. Primeiro a Robson, que vem me
acompanhando desde a gradua¸c˜ao. No Orkut dele tem foto tanto do list˜ao da
gradua¸c˜ao, quanto ao do mestrado, os nossos nomes. A minha ”parea”de mestrado,
Cristiane Queiroz, que estivemos juntos desde a primeira reuni˜ao, antes das aulas
e at´e hoje sempre mantendo contato e um ajudando o outro. Sem d´uvida uma
amiga que arrumei para sempre. Aos outros colegas como Rˆomulo, Juliana, H´ıtalo,
Jefferson, Amanda, Nathalia e Emanoel, que nos ajudaram nos experimentos, que
foram a base do meu projeto de mestrado. E a todos os membros do SPG.
Sem mais, um obrigado a todos esse que influenciaram a minha conquista. Aos
que esqueci e n˜ao lembrei at´e a vers˜ao final, desculpa.
Sum´ario
LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . vii
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1 INTRODUC¸
˜
AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organiza¸c˜ao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Tratamento de Exce¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Tratamento de Exce¸c˜oes em Java . . . . . . . . . . . . . . . . . . . . . 8
2.3 Programa¸c˜ao Orientada a Aspectos e AspectJ . . . . . . . . . . . . . . 11
2.3.1 Conceitos Fundamentais da Orienta¸c˜ao a Aspectos . . . . . . . . . . . . 12
2.3.2 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Tratamento de Exce¸c˜oes em AspectJ . . . . . . . . . . . . . . . . . . . . 15
2.4 M´etricas Est´aticas de C´odigo . . . . . . . . . . . . . . . . . . . . . . . . 17
3 REUSO INTRA-APPLICAC¸
˜
AO . . . . . . . . . . . . . . . . . . . 19
3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Sistemas Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Extra¸c˜ao e Reutiliza¸c˜ao de Tratadores de
Exce¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Extra¸c˜ao do Tratamento de Exce¸c˜oes . . . . . . . . . . . . . . . . . . . 21
3.3.2 Reuso dos Tratadores de Exce¸c˜ao . . . . . . . . . . . . . . . . . . . . . 25
3.4 Conjunto de M´etricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Conclus˜oes sobre Reuso Intra-Aplica¸c˜ao . . . . . . . . . . . . . . . . . . 35
4 REUSO INTER-APPLICAC¸
˜
AO . . . . . . . . . . . . . . . . . . . 39
4.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Sistemas Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Extra¸c˜ao e Reuso dos Tratadores de Exce¸c˜oes . . . . . . . . . . . . . . . 41
4.4 Metodologia de Busca Utilizada . . . . . . . . . . . . . . . . . . . . . . 43
4.4.1 Procurando Oportunidades de Reuso . . . . . . . . . . . . . . . . . . . 44
4.4.2 Empacotamento e Ambiente de Compila¸c˜ao . . . . . . . . . . . . . . . . 48
4.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5.1 Estrat´egias de Cada Aplica¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 Problemas Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Conclus˜oes do Reuso Inter-Aplica¸c˜ao . . . . . . . . . . . . . . . . . . . 55
5 EH-METER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1 M´etricas Implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Implementa¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Arquitetura e Modifica¸c˜oes no C´odigo Original . . . . . . . . . . . . . . 60
5.2.2 Novas M´etricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Execu¸c˜ao e Resultados da Ferramenta . . . . . . . . . . . . . . . . . . . 63
5.4 Avalia¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1 Comparando Abordagens de Medi¸c˜oes . . . . . . . . . . . . . . . . . . . 65
5.5 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 CONCLUS
˜
OES E TRABALHOS FUTUROS . . . . . . . . . . . 68
6.1 Publica¸c˜oes Resultantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
REFER
ˆ
ENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Lista de Abreviaturas e Siglas
B2B Bussines to Bussiness
GUI Interface Gr´afica com o Usu´ario (Graphic User Interface)
LOC Linhas de C´odigo (Lines Of Code)
POA Programa¸c˜ao Orientada a Aspectos
POO Programa¸c˜ao Orientada a Objetos
XML Linguagem de Marca¸c˜ao Extens´ıvel (eXtensible Marckup Language)
Lista de Figuras
Figura 2.1: Exemplo do tratamento de exce¸c˜oes em Java. . . . . . . . . . . . 10
Figura 2.2: Classe Java afetada por um Aspecto. . . . . . . . . . . . . . . . . 14
Figura 2.3: Aspecto que afeta a ClasseA. . . . . . . . . . . . . . . . . . . . . 15
Figura 2.4: Exemplo de Tratamento de Exce¸c˜oes em AspectJ. . . . . . . . . . 16
Figura 3.1: Fluxo das Refatora¸c˜oes. . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 3.2: C´odigo Original da Classe CheckSelectedFilesAction. . . . . . . . 23
Figura 3.3: C´odigo da Classe CheckSelectedFilesAction Refatorada OO. . . . . 23
Figura 3.4: C´odigo da Classe ActionExceptionHandler. . . . . . . . . . . . . . 24
Figura 3.5: C´odigo da Classe CheckSelectedFilesAction Refatorada AO. . . . . 25
Figura 3.6: C´odigo do Aspecto ActionAspectExceptionHandler. . . . . . . . . 25
Figura 3.7: Diagrama de Classes das vers˜oes Ref. OO. . . . . . . . . . . . . . 26
Figura 3.8: Diagrama de Classes das vers˜oes Ref. AO. . . . . . . . . . . . . . 27
Figura 3.9: Exemplo de Reuso de Tratadores de Exce¸c˜ao nas Ver. Ref. OO. . 27
Figura 3.10: Exemplo de Reuso de Tratadores de Exce¸c˜ao na Ver. Ref. AO. . . 28
Figura 3.11: Incrementos nas M´etricas de Tamanho. . . . . . . . . . . . . . . . 34
Figura 3.12: Incrementos nas M´etricas de Interesses. . . . . . . . . . . . . . . . 34
Figura 4.1: C´odigo Original do Reuso Inter-Aplica¸c˜ao. . . . . . . . . . . . . . 43
Figura 4.2: Aspecto Abstrato no c´odigo reus´avel . . . . . . . . . . . . . . . . . 44
Figura 4.3: Aspecto Concreto que estande do Aspecto Abstrato . . . . . . . . . 44
Figura 4.4: Exemplo da estrat´egia Lan¸camento. . . . . . . . . . . . . . . . . . 45
Figura 4.5: Exemplo da estrat´egia throws. . . . . . . . . . . . . . . . . . . . . 51
Figura 5.1: Hierarquia de Pacotes do EH-Meter. . . . . . . . . . . . . . . . . 61
Figura 5.2: C´odigo da Classe Metrics.java . . . . . . . . . . . . . . . . . . . . 62
Figura 5.3: Transi¸c˜oes entre os interesses. . . . . . . . . . . . . . . . . . . . . 63
Figura 5.4: Exemplo de um arquivo de configura¸c˜ao para executar o EH-Meter. 64
Figura 5.5: Resultado das M´etricas Coletadas. . . . . . . . . . . . . . . . . . 65
Lista de Tabelas
Tabela 2.1: Algumas Linguagens de Programa¸c˜ao e suas Extens˜oes para POA [44]. 12
Tabela 3.1: Conjunto de M´etricas utilizadas . . . . . . . . . . . . . . . . . . . 36
Tabela 3.2: Resultado das M´etricas de Tamanho . . . . . . . . . . . . . . . . 37
Tabela 3.3: Resultado das M´etricas de Interesse . . . . . . . . . . . . . . . . . 38
Tabela 4.1: Aplica¸c˜oes Usadas para reuso Inter-Aplica¸c˜oes. . . . . . . . . . . 42
Tabela 4.2: As estrat´egias de tratamento de exce¸c˜oes propostas por Cabral e
Marques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 4.3: Mapeamento dos casos que levantam uma nova exce¸c˜ao. . . . . . 47
Tabela 4.4: Quantidade de tratadores para cada estrat´egia. . . . . . . . . . . 51
Tabela 4.5: Mapeamento de cada tipo de exce¸c˜ao com seu respectivo grupo. . 53
Tabela 5.1: Conjunto de M´etricas implementadas no EH-Meter . . . . . . . . 59
Tabela 5.2: Comparativo de coleta de m´etricas. Os n´umeros representam o
tempo, em minutos. . . . . . . . . . . . . . . . . . . . . . . . . . 66
Resumo
Tratamento de exce¸c˜oes ´e uma t´ecnica bastante utilizada no desenvolvimento de sis-
temas e diversas linguagens de programa¸c˜oes modernas j´a incluem esse mecanismo
nas suas defini¸c˜oes. Um dos objetivos principais de um mecanismo de tratamento
de exce¸c˜oes ´e separar o c´odigo respons´avel pela atividade normal de um sistema
do c´odigo de tratamento de erros. Apesar disso, os mecanismos de tratamento de
exce¸c˜oes das linguagens mais difundidas na pr´atica propiciam o aparecimento de
c´odigo de tratamento de exce¸c˜oes misturado textualmente com o c´odigo de compor-
tamento normal dos sistemas. Esses mecanismos tamb´em produzem c´odigo dupli-
cado, o que dificulta a manuten¸c˜ao e evolu¸c˜ao dos sistemas de software e os torna
mais dif´ıceis de compreender. O interesse do tratamento de exce¸c˜oes ´e um interesse
transversal (crosscutting concern) porque est´a normalmente misturado com outros
interesses de um sistema e espalhado pelos seus m´odulos. A Programa¸c˜ao Orientada
a Aspectos tem o objetivo de modularizar o c´odigo de interesses transversais, sendo
AspectJ uma das linguagens orientadas a aspetos mais difundidas. O trabalho aqui
proposto aborda o reuso de c´odigo do tratamento de exce¸c˜oes, modularizando esse
c´odigo em aspectos AspectJ. Tamb´em s˜ao discutidas limita¸c˜oes de estudos j´a rea-
lizados com objetivos similares. Diferente destes, esse trabalho utilizou de v´arias
aplica¸c˜oes com tamanhos relevantes. A reusabilidade do c´odigo de tratamento de
exce¸c˜oes foi avaliada de duas formas: a primeira para reuso dentro de uma mesma
aplica¸c˜ao e a segunda para reuso entre aplica¸c˜oes diferentes. Os resultados mos-
tram que a abordagem de reuso de c´odigo para uma mesma aplica¸c˜ao ´e bastante
relevante, pois diminui o n´umero de tratadores de exce¸c˜oes, gerando assim melhor
modulariza¸c˜ao e separa¸c˜ao de interesses. Entretanto, reusar c´odigo em aplica¸c˜oes
diferentes ´e bastante dif´ıcil e com resultados n˜ao t˜ao satisfat´orios, para a abordagem
adotada nesse estudo. Outra contribui¸c˜ao foi o desenvolvimento de uma ferramenta,
para coleta de m´etricas para um interesse espec´ıfico, o tratamento de exce¸c˜oes.
Palavras-chave: Tratamento de exce¸c˜oes, reuso, aspectos.
Abstract
Exception handling is a technique widely used in system development and sev-
eral modern programming languages already include this mechanism in their defi-
nitions. One of the main goals of an exception handling mechanism is to separate
the code responsible for the normal system behavior from the exception handling
code. However, the exception handling mechanisms of most widespread program-
ming languages allow the appearance of exception handling code textually mixed
with the normal system behavior code. These mechanisms also produce duplicated
code, which hinders software maintenance and development, making the software
code more difficult to understand. The exception handling concern is a crosscut-
ting concern because it is usually tangled with other concerns and spread over their
modules. Aspect-Oriented Programming aims to modularize crosscutting concerns,
being AspectJ one of the most widespread aspect-oriented language. This work ad-
dresses exception handling code reuse, when the code is modularized with AspectJ
aspects. It also discusses limitations of previous studies with similar aims. Differ-
ent of these, this work used several applications with relevant sizes. The exception
handling code reusability was evaluated in two ways: the first considered the reuse
within a same application and the second among different applications. The results
show that the code reuse within the same application is very relevant, since it re-
duces the number of exception handlers, thus creating better modularization and
separation of concerns. However, reusing code among different applications is quite
difficult with not so satisfactory result, considering the approach adopted in this
study. Another contribution was a tool developed to collect metrics for a specific
concern, the exception handling.
Keywords: exception handling, reuse, aspects.
Cap´ıtulo 1
Introdu¸c˜ao
O Tratamento de exce¸c˜oes [15] ´e uma t´ecnica bastante utilizada no desenvolvimento
de sistemas de computa¸c˜ao atuais.
´
E comum que uma parte consider´avel do c´odigo
de um sistema seja dedicada `a detec¸c˜ao e ao tratamento de erros [6, 15, 33, 57].
Diversas linguagens de programa¸c˜ao modernas usadas na ind´ustria, como Java, C#,
C++ e Ada, incluem mecanismos de tratamento de exce¸c˜oes. Tais mecanismos
permitem que programas indiquem a ocorrˆencia de situa¸c˜oes errˆoneas, atrav´es do
lan¸camento de exce¸c˜oes, e capturem e tratem tais exce¸c˜oes, de modo a retornar para
um estado consistente.
No projeto do mecanismo de tratamento de exce¸c˜oes [38] de uma linguagem de
programa¸c˜ao, diversas quest˜oes precisam ser consideradas [24]. Exce¸c˜oes represen-
tando erros comuns devem ser nativas da linguagem enquanto o usu´ario deve poder
criar novos tipos de exce¸c˜oes. Tamb´em ´e importante considerar a maneira como
o fluxo de execu¸c˜ao ser´a afetado pelo tratamento da exce¸c˜ao. Uma outra quest˜ao
de projeto importante diz respeito a como as unidades de c´odigo respons´aveis por
tratar exce¸c˜oes (tratadores de exce¸c˜oes) s˜ao associadas `a elementos do programa.
Java, por exemplo, permite apenas que tratadores sejam associados a blocos dentro
de um m´etodo, enquanto Guide [24] torna poss´ıvel associar tratadores a chamadas
de m´etodos, m´etodos e classes. Outra considera¸c˜ao importante ´e quanto aos tipos
de exce¸c˜oes. Em algumas linguagens, como C++, as exce¸c˜oes s´o podem ser defini-
das pelo usu´ario. J´a em Java podem ser utilizadas tanto exce¸c˜oes definidas pelos
usu´arios, como exce¸c˜oes nativas da pr´opria linguagem.
Apesar de toda essa varia¸c˜ao, observa-se que a utiliza¸c˜ao de tratamento de
exce¸c˜oes na constru¸c˜ao de sistemas reais pode resultar na cria¸c˜ao de v´arios tra-
tadores com o mesmo c´odigo e ou com o mesmo comportamento [2], espalhados
pelos m´odulos do sistema, gerando assim os conhecidos clones de c´odigo [28] de tra-
tamento de exce¸c˜oes. A existˆencia de c´odigo duplicado em sistemas de software tem
2
impacto em diversos aspectos relativos `a qualidade do sistema [35, 26]. Abaixo s˜ao
listadas algumas desvantagens da existˆencia de c´odigo duplicado em um sistema:
• Aumento na probabilidade de propaga¸c˜ao de erros;
• Aumento na probabilidade de inser¸c˜ao de novos erros;
• Aumento na probabilidade de um projeto (design) mal definido;
• Aumento na dificuldade e, portanto, nos custos de manuten¸c˜ao e evolu¸c˜ao.
Alguns trabalhos [30, 56, 20] apresentaram novas t´ecnicas de programa¸c˜ao ten-
tando obter benef´ıcios adicionais dos mecanismos de tratamento de exce¸c˜oes exis-
tentes. Apesar disso, a obten¸c˜ao de um c´odigo de tratamento de exce¸c˜oes modular
n˜ao ´e uma tarefa f´acil para os desenvolvedores. O maior problema ´e o grande e
complexo relacionamento entre o c´odigo de comportamento normal da aplica¸c˜ao e o
c´odigo que manipula exce¸c˜oes, nos sistemas de software. Al´em disso, o tratamento
de exce¸c˜oes ´e um requisito do projeto (design) de um sistema [24], afetando todos
os seus m´odulos [30]. Em alguns sistemas, a parte do c´odigo para tratamento de
exce¸c˜oes ´e bastante grande [15, 57], mesmo assim nem todos os casos de tratamento
de exce¸c˜oes s˜ao f´aceis de ser entendidos, documentados [15] e testados.
Nos sistema de software, o tratamento de exce¸c˜oes ´e um interesse que pode ser
encontrado em diversas partes do c´odigo [30], normalmente entrela¸cado ao c´odigo
relativo a outros interesses. Interesses que tˆem essas caracter´ısticas s˜ao conhecidos
como interesses transversais (crosscutting concerns) [27]. Nos anos 90, foi proposta
uma t´ecnica de desenvolvimento cujo objetivo ´e tornar poss´ıvel a modulariza¸c˜ao
desses interesses transversais, separando-os dos demais interesses do sistema. Essa
t´ecnica chama-se Programa¸c˜ao Orientada a Aspectos (POA) [27]. Alguns trabalhos
prop˜oem que o uso de POA ajuda a modulariza¸c˜ao do c´odigo referente ao tratamento
de exce¸c˜oes [27, 29, 30, 6].
V´arios trabalhos [30, 6, 8, 5, 21, 4] mostram que a modulariza¸c˜ao do tratamento
de exce¸c˜oes de um programa com aspectos gera alguns benef´ıcios, tais como se-
para¸c˜ao de interesses transversais, localiza¸c˜ao da implementa¸c˜ao de tais interesses
e diminui¸c˜ao no acoplamento. Em todo esses trabalhos, sistemas pr´e-existentes,
escritos em Java, foram refatorados de modo a extrair todo o seu c´odigo de trata-
mento de exce¸c˜oes para aspectos escritos na linguagem AspectJ [29]. A avalia¸c˜ao da
qualidade das vers˜oes OO e AO de cada sistema se deu pela utiliza¸c˜ao de algumas
m´etricas est´aticas de c´odigo, gen´ericas.
Lippert e Lopes [30], no trabalho seminal sobre POA e tratamento de exce¸c˜oes,
realizaram um estudo cujo objetivo era modularizar o tratamento de exce¸c˜oes de
3
um sistema de m´edio porte utilizando aspectos escritos em AspectJ, deixando esse
interesse separado do restante do c´odigo do sistema. Para esse trabalho, foi utilizado
o c´odigo do framework JWAM 1.4, escrito originalmente na linguagem Java. Os re-
sultados obtidos nesse experimento mostram que houve uma redu¸c˜ao no n´umero de
linha de c´odigo relacionado com o tratamento de exce¸c˜oes. No melhor caso o fator
de redu¸c˜ao foi de 4. Tamb´em foram verificadas algumas propriedades promovidas
pelo uso de AspectJ, como melhor suporte a diferentes comportamentos de exce¸c˜oes,
maior tolerˆancia a mudan¸cas em especifica¸c˜oes do comportamento de exce¸c˜oes, mel-
hor suporte para o desenvolvimento incremental, melhor reuso e programas escritos
mais claramente.
Tomando como base o estudo anterior [30], Castor et al. [6] apresentaram um
estudo aprofundado sobre a adequa¸c˜ao da linguagem AspectJ para modulariza¸c˜ao
do tratamento de exce¸c˜oes. Nesse estudo foram refatorados quatro sistemas, remo-
vendo o tratamento de exce¸c˜oes para aspectos. Dos quatro sistemas refatorados, trˆes
eram orientados a objetos e um era orientado a aspectos. Para compara¸c˜ao do re-
sultado da refatora¸c˜ao obtida com o c´odigo original, foram usadas algumas m´etricas
est´aticas tanto de tamanho de c´odigo, como n´umero de linhas de c´odigo e tamanho
de vocabul´ario. Al´em de tamb´em levar algumas quest˜oes qualitativas, como aco-
plamento, coes˜ao e sobre reusabilidade. Com os resultados obtidos, foram tiradas
algumas conclus˜oes sobre os benef´ıcios da modulariza¸c˜ao de tratamento de exce¸c˜oes
usando aspectos. Assim como Lippert e Lopes, Castor et al. [6] comprovaram que
o uso de aspectos diminuiu a interferˆencia entre interesses do sistema. Embora os
valores de algumas m´etricas, como n´umeros de opera¸c˜oes, tenham crescido, isso n˜ao
´e um fator negativo, pois os tratadores se tornaram mais simples e n˜ao se misturam
com o c´odigo normal do sistema.
Resultado importante do estudo de Castor et al. [6] ´e sobre o reuso de c´odigo.
Esse estudo menciona que reuso de c´odigo n˜ao ´e o principal benef´ıcio da modula-
riza¸c˜ao de interesses transversais de sistemas de software, mas uma consequˆencia
esperada. Entretanto, foi verificado que o reuso foi dif´ıcil de ser obtido, contradi-
zendo os resultados obtidos por Lippert e Lopes. No mesmo trabalho [6], Castor et
al. definiu alguns cen´arios, classificando os casos onde foi poss´ıvel fazer a extra¸c˜ao
dos tratadores de exce¸c˜oes para aspectos. Para cada um dos itens apontados nos
cruzamentos de informa¸c˜oes referentes ao c´odigo a ser refatorado, ´e dito se o cen´ario
poder´a ser aspectizado ou n˜ao, com base nos experimentos realizados nos estudos.
No trabalho realizado por Cacho et al. [4] ´e apresentado um modelo inovador
para tratar exce¸c˜oes utilizando aspectos. Diferente de outros trabalhos, esse modelo
proposto faz a abstra¸c˜ao da vis˜ao global dos fluxos para tratamento de exce¸c˜ao,
4
sendo necess´ario apenas observar uma parte do programa. As avalia¸c˜oes quanti-
tativa e qualitativa desse novo modelo basearam-se em um estudo de caso utili-
zando uma aplica¸c˜ao m´ovel real. Em outro trabalho [25] foi apresentado o resultado
de um estudo emp´ırico fazendo uma compara¸c˜ao dos tradeoffs entre transparˆencia
(obliviousness [22]) e modularidade. No estudo, os tratadores de exce¸c˜oes de trˆes
sistemas reais em Java foram extra´ıdos para aspectos usando abordagens expl´ıcita e
transparente e os sistemas refatorados foram comparados com os originais usando-
se m´etricas de c´odigo usadas em estudos pr´evios. Os dois trabalhos citados nesse
par´agrafo [4, 25] mostram novas maneiras de aumentar reuso de c´odigo para trata-
mento de exce¸c˜oes, utilizando novas constru¸c˜oes para linguagens de POA. Por´em,
eles mostram duas limita¸c˜oes: (i) necessidade de novas constru¸c˜oes, n˜ao se apli-
cando a nenhuma abordagem de POA utilizada atualmente no desenvolvimento; e
(ii) n˜ao conseguem resolver problemas de reuso de sistemas de grande porte, pois
n˜ao mostram como combina¸c˜ao de tratadores similares poderia ser feita de maneira
automatizada.
Coelho et al. [11] apresentaram um estudo sistem´atico sobre a propens˜ao a erros
do uso de POA, levando em conta os fluxos de exce¸c˜oes em sistemas. Esse trabalho
faz a verifica¸c˜ao dos efeitos positivos e negativos da modulariza¸c˜ao do tratamento
de exce¸c˜oes em aspectos. O estudo foi realizado utilizando trˆes sistemas de tamanho
m´edio e pertencentes a diferentes dom´ınios de aplica¸c˜ao. Para esse estudo foi desen-
volvida uma ferramenta de an´alise de fluxo de exce¸c˜oes para auxiliar a avalia¸c˜ao do
c´odigo estudado, tamb´em sendo feitas inspe¸c˜oes sobre o c´odigo, nas vers˜oes originais
em Java e com o tratamento de exce¸c˜oes implementado com aspectos, em AspectJ.
Neste trabalho, v´arios resultados negativos foram encontrados, investigados, apre-
sentados e catalogados. Os principais foram evidˆencias de que existem exce¸c˜oes n˜ao
tratadas, quando h´a o tratamento de exce¸c˜oes estiver dentro de aspectos e exce¸c˜oes
que s˜ao lan¸cadas pelos aspectos e capturadas por tratadores existentes no c´odigo
base. Em outro trabalho, Coelho et al. [10] apresentam poss´ıveis cen´arios de falhas
associados com reuso de bibliotecas de aspectos. Foi apresentado no trabalho que
reuso de bibliotecas de aspectos realmente proporcionam defeitos relativos ao trata-
mento de exce¸c˜oes. Tamb´em apresenta uma abordagem de reuso, apoiada por uma
ferramenta de an´alise est´atica que proporciona melhorias.
1.1 Motiva¸c˜ao
Na engenharia de software, a busca por reuso vem se tornando cada vez mais
constante. Nas ´ultimas decadas, muitas t´ecnicas foram desenvolvidas para apoiar
5
o reuso de software [39]. O uso de c´odigo espec´ıfico para tratadores de exce¸c˜oes
´e bastante encontrado atualmente. Alguns trabalhos mostram que o n´umero de
tratadores de exce¸c˜oes por opera¸c˜oes, para aplica¸c˜oes desenvolvidas em Java EE 5,
varia entre 0,058 e 1,79 [33]. Outro trabalho aponta que entre 1 e 5% do c´odigo, em
aplica¸c˜oes open source, ´e relativos ao tratamento de exce¸c˜oes [57]. Em um sistema
de 20K LOC, utilizando percentual encontrado no trabalho de Weimer e Necula, ele
pode ter entre 200 e 1000 LOC, o que ´e um valor bem relevante para ser analisada
a possibilidade de reuso.
Nas linguagens orientadas a objetos mais usadas na pr´atica de desenvolvimento
de software, o c´odigo referente ao tratamento de exce¸c˜oes est´a fortemente acoplado
ao c´odigo que implementa o comportamento normal do sistema. O c´odigo duplicado
acaba sendo ent˜ao uma consequˆencia desse relacionamento, j´a que se torna dif´ıcil
empregar o mesmo tratador de exce¸c˜oes em diferentes partes do sistema. Mas c´odigo
duplicado, como apresentado em alguns trabalhos [28, 35], diminui alguns atributos
de qualidade e influencia negativamente a manuten¸c˜ao e evolu¸c˜ao do c´odigo, como
tamb´em a legibilidade. Assim a modulariza¸c˜ao do c´odigo referente ao tratamento de
exce¸c˜oes, a fim de obter reuso, visa diminuir os impactos negativos da duplica¸c˜ao do
c´odigo de tratamento de exce¸c˜oes e tenta melhorar a manutenabilidade e legibilidade.
1.2 Objetivos do Trabalho
O problema foco desse trabalho ´e o c´odigo de tratamento de exce¸c˜oes duplicado,
pois gera maior possibilidade de propaga¸c˜ao e insers˜ao de erros, tamb´em podendo
aumentar o custo e tempo de manuten¸c˜ao desses sistemas. Assim, o objetivo ´e fazer
um estudo amplo com foco na an´alise sobre reusabilidade de c´odigo de tratamento
de exce¸c˜oes, quando esse interesse estiver modularizado atrav´es de aspectos AspectJ.
Embora haja alguns estudos que afirmem que AOP promove reuso de tratadores de
exce¸c˜oes, esses estudos foram aplicados a sistemas tratadores muitos simples [30].
H´a tamb´em estudos que afirmam que reutilizar aspectos de tratamento de exce¸c˜oes
n˜ao-triviais ´e dif´ıcil, mas tais estudos n˜ao avaliaram o impacto de AspectJ no reuso
de tratadores de maneira aprofundada [6]. O ponto inicial do trabalho ´e abordar as
limita¸c˜oes de dois estudos j´a descritos [30, 6], buscando reutilizar c´odigo relativo ao
tratamento de exce¸c˜oes em sistemas de m´edio porte e com tratadores de exce¸c˜oes
mais complexos. Tamb´em a utiliza¸c˜ao de novas m´etricas a fim de aferir os impactos
das modifica¸c˜oes no c´odigo, modifica¸c˜oes essas com inten¸c˜ao de possibilitar o reuso.
Para o estudo s˜ao abordadas duas perspectivas: intra e inter-aplica¸c˜oes. Na
primeira perspectiva abordada, foi avaliado o quanto de reuso pode ser obtido dentro
6
de uma mesma aplica¸c˜ao. A avalia¸c˜ao lan¸ca m˜ao de um conjunto de m´etricas de
c´odigo que focam especificamente no interesse de tratamento de exce¸c˜oes. J´a no
´ultimo caso, foram avaliados os fatores que propiciam ou dificultam a reutiliza¸c˜ao de
tratadores de exce¸c˜oes entre aplica¸c˜oes diferentes. Com isso s˜ao propostas solu¸c˜oes
para aumentar o grau de reuso que pode ser obtido com o uso de aspectos para
modulariza¸c˜ao do interesse de tratamento de exce¸c˜oes. Tamb´em s˜ao levantados
alguns problemas advindos da tentativa do reuso do c´odigo de tratadores de exce¸c˜oes.
Pela necessidade de fazer a coleta de m´etricas em v´arias vers˜oes de v´arios sis-
temas diferentes, foi desenvolvida uma ferramenta para coletar essas m´etricas dese-
jadas. Essa ferramenta implementa m´etricas espec´ıficas focadas no tratamento de
exce¸c˜oes. Tais m´etricas medem tanto tamanho de c´odigo, como linhas de c´odigo
(LOC) e n´umero de blocos try, como tamb´em implementa novas m´etricas relativas
a interesses, definidas em trabalhos recentes como DOF [18] e CDLOC [37]. Essa
´ultima n˜ao se tem conhecimento de ferramentas com essa m´etrica implementada.
1.3 Organiza¸c˜ao do Trabalho
Esse documento est´a organizado em seis cap´ıtulos. No Cap´ıtulo 2 s˜ao apresentados
os principais conceitos de tratamento de exce¸c˜oes, AspectJ e m´etricas est´aticas de
c´odigo. No Cap´ıtulo 3 ´e descrito o trabalho realizado referente ao reuso intra-
applica¸c˜ao. O estudo que foi realizado com o intuito de avaliar o uso de AspectJ
para reutilizar tratadores de exce¸c˜oes entre aplica¸c˜oes diferentes e independentes
´e apresentado no Cap´ıtulo 4 e a ferramenta EH-Meter, desenvolvida durante os
estudos sobre reuso, ´e apresentada no Cap´ıtulo 5. Por ´ultimo, no Cap´ıtulo 6 s˜ao
mostradas as conclus˜oes do trabalho.
7
Cap´ıtulo 2
Background
Esse cap´ıtulo faz uma contextualiza¸c˜ao de assuntos abordados nessa disserta¸c˜ao. A
Se¸c˜ao 2.1 aborda o tratamento de exce¸c˜oes, explanando conceitos relacionados `a
captura e o tratamento de exce¸c˜oes e `a recupera¸c˜ao do sistema. A implementa¸c˜ao
do tratamento de exce¸c˜oes na linguagem de programa¸c˜ao Java ´e mostrada na Se¸c˜ao
2.2. A Se¸c˜ao 2.3 apresenta os conceitos fundamentais da Programa¸c˜ao Orientada
a Aspectos, al´em de introduzir a linguagem orientada a aspectos empregada neste
trabalho, AspectJ. Esta se¸c˜ao tamb´em mostra como tratamento de exce¸c˜oes pode
ser implementado usando AspectJ. A Se¸c˜ao 2.4 fornece uma breve introdu¸c˜ao a
m´etricas est´aticas de c´odigo, bem como algumas ferramentas e algumas m´etricas
encontradas na literatura.
2.1 Tratamento de Exce¸c˜oes
V´arios sistemas possuem modo de detec¸c˜ao de erros, tanto implementados em hard-
ware quanto implementados em software. Um exemplo das implementa¸c˜oes em hard-
ware s˜ao os sistemas de c´alculo, que possuem verifica¸c˜ao de overflow, em opera¸c˜oes
de ponto flutuantes. As implementa¸c˜oes em software s˜ao as mais comuns, pelo
n´umero de abstra¸c˜oes poss´ıveis dentro do sitema. Muitas vezes as linguagens pos-
suem estruturas de transferˆencia de informa¸c˜oes, com os sistemas operacionais, para
tratar algumas situa¸c˜oes de erros, como problemas de impress˜ao e falta de mem´oria.
Outras vezes, o controle da aplica¸c˜ao tamb´em pode ser transferido para o pr´oprio
sistema operacional, podendo ser devolvido em seguida. Outros erros podem ser de-
tectados previamente, no momento da compila¸c˜ao do sistema. Mas existem alguns
erros que s´o podem aparecer no momento da execu¸c˜ao do sistema.
Uma exce¸c˜ao ´e um evento incomum, de erro ou n˜ao, que pode ser detectado
por hardware ou software, e que necessita de um processamento especial [38]. Esse
8
processamento especial, que ´e requerido pelo evento, ´e chamado de tratamento de
exce¸c˜ao (exception handling) [38]. O c´odigo referente a esse processamento ´e
chamado de tratador de exce¸c˜ao (exception handler). Assim, ap´os o erro em
determinada parte de c´odigo, uma exce¸c˜ao e um tratador de exce¸c˜oes geralmente
s˜ao associados a um determinado tipo de evento. Isso faz com que, para cada tipo de
erro e cada contexto onde tal erro seja sinalizado, seja poss´ıvel definir um tratamento
espec´ıfico para aquele tipo de evento.
Mesmo quando uma linguagem n˜ao d´a suporte ao tratamento de exce¸c˜oes, algu-
mas vezes o desenvolvedor pode controlar situa¸c˜oes anormais atrav´es dos mecanis-
mos existentes na linguagem. Um exemplo disso ´e a linguagem C, onde costuma-se
usar c´odigos de retorno para indicar sucesso ou falha na execu¸c˜ao de uma fun¸c˜ao.
Uma outra abordagem ´e passagem de r´otulo (label) para subprogramas. Dessa forma
´e poss´ıvel retornar ao local onde ocorreu um erro depois que esse erro for corrigido
pelo tratador apropriado. Uma terceira possibilidade ´e ter tratadores de exce¸c˜oes
como subprogramas separados, passados como parˆametros `a unidade chamada.
Outra abordagem ´e manipular a exce¸c˜ao na mesma unidade onde a exce¸c˜ao foi
detectada. Assim, o tratador ´e um segmento do c´odigo da pr´opria unidade. Essa
´e definida por alguns como uma melhor abordagem [24], pois consegue realmente
descrever onde cada tratador ´e aplicado, e o c´odigo fica com uma melhor legibili-
dade. Por´em, o c´odigo de comportamento normal do sistema se mistura com o do
tratamento de exce¸c˜oes. Nesse caso uma solu¸c˜ao de separa¸c˜ao mais clara do c´odigo
relativo tratamento de exce¸c˜ao com o uso de blocos distintos para comportamento
normal e para o tratamento de exce¸c˜ao. Da´ı algumas linguagens como Java, C++ e
C# possuem as divis˜oes dos c´odigos com diretivas try-catch-finally. Tamb´em ´e
poss´ıvel levantar a exce¸c˜ao a uma unidade antecessora de onde a exce¸c˜ao foi levan-
tada, como o m´etodo ou fun¸c˜ao que chamou o local onde a exce¸c˜ao foi levantada.
Nesse caso um m´etodo ou fun¸c˜ao, a depender da linguagem de programa¸c˜ao, le-
vanta a exce¸c˜ao para o m´etodo ou fun¸c˜ao que a chamou. Exemplo disso ´e a clausula
throws de Java. Com isso torna poss´ıvel tratar e reusar c´odigo tratador de um
mesmo tipo de exce¸c˜ao,
2.2 Tratamento de Exce¸c˜oes em Java
Em Java, todas as exce¸c˜oes s˜ao objetos que herdam da classe Throwable [52]. Os
tipos que herdam diretamente de Throwable, e definidos pelo sistema, s˜ao Error
e Exception. As exce¸c˜oes que herdam de Error e suas descendentes s˜ao gera-
9
das pela m´aquina virtual e jamais dever ser geradas pelo programa do usu´ario e
nem devem ser tratadas. Exception ´e a classe base para as exce¸c˜oes existentes
que podem ser levantadas e tratadas pelos programas escritos em Java. Toda
exce¸c˜ao subtipo de Exception deve ser tratada pelo programa, exceto subtipos
de RuntimeException para os quais o tratamento n˜ao ´e obrigat´orio. As exce¸c˜oes
do tipo RuntimeException indicam erros de programa¸c˜ao e s˜ao levantadas quando
ocorrem erros como vari´aveis locais ou atributos apontando para um objeto nulo,
tentativas de acessar uma posi¸c˜ao inv´alida de um array, entre outros. Exce¸c˜oes
bastante comuns nos sistemas s˜ao as que herdam de IOException, como o pr´oprio
nome diz, ´e relativa a opera¸c˜oes de entrada e sa´ıda de dados, como arquivos em
disco e conex˜oes de rede. Cada sistema pode possuir seus pr´oprios tipos de exce¸c˜oes,
convencionalmente as classes desses novos tipos devem herdar de Exception ou de
algum de seus subtipos.
Dois pontos s˜ao importantes no sistema de tipos da linguagem Java. O primeiro ´e
da obrigatoriedade da exce¸c˜ao ter c´odigo tratador ou n˜ao. Assim as exce¸c˜oes podem
ser divididas em exce¸c˜oes checadas e exce¸c˜oes n˜ao checadas. As exce¸c˜oes
do tipo Exception devem obrigatoriamente possuir o c´odigo tratador da exce¸c˜ao,
sendo verificado a existˆencia desse c´odigo no momento da compila¸c˜ao. J´a exce¸c˜oes
do tipo RuntimeException n˜ao s˜ao obrigadas a possu´ırem o c´odigo tratador de
exce¸c˜ao dentro do m´etodo ou levantar para o m´etodo que as chamaram, portanto,
s˜ao as exce¸c˜oes que n˜ao s˜ao checadas no momento da compila¸c˜ao. O outro ponto
importante diz respeito a tratar uma exce¸c˜ao ou levant´a-la para que seja tratada
pelo m´etodo que chamou o m´etodo onde ela foi levantada. Assim, um m´etodo que
tem c´odigo que pode levantar uma exce¸c˜ao n˜ao tem obriga¸c˜ao de trat´a-la, podendo
tamb´em levantar para o m´etodo que o chamou. Desta forma, a assinatura do m´etodo
deve conter a diretiva throws junto com o tipo da exce¸c˜ao a ser propagada.
Em Java (assim como em C++ e C#), um bloco try define um contexto de
tratamento de exce¸c˜oes, uma regi˜ao de um programa onde as mesmas exce¸c˜oes s˜ao
sempre tratadas da mesma forma. Associados a um bloco try, podem haver zero ou
mais tratadores de exce¸c˜oes, definidos por blocos catch. Cada bloco catch ´e um tra-
tador para uma exce¸c˜ao no contexto ao qual est´a associado. Uma exce¸c˜ao levantada
dentro de um escopo de tratamento de exce¸c˜oes que n˜ao seja tratada por nenhum
de seus tratadores ´e propagada para o escopo mais externo, onde ´e levantada. Esse
processo acontece at´e que a exce¸c˜ao seja tratada ou n˜ao haja mais escopos de trata-
mento de exce¸c˜oes, o que significa que a aplica¸c˜ao falhou (em terminologia de Java,
diz-se que a exce¸c˜ao n˜ao foi capturada). O trecho de c´odigo mostrado na Figura
2.1 h´a um exemplo do tratamento de exce¸c˜oes. Na linha 4 podem ser levantados
10
dois tipos de exce¸c˜ao. O primeiro tipo ´e NullPointerException, caso o atributo
filename n˜ao tenha sido inicializado com algum valor n˜ao-nulo. Essa exce¸c˜ao ser´a
tratada no bloco catch da linha 7. Outro tipo de exce¸c˜ao que pode ser levantada na
linha 4 ´e IOException, caso n˜ao seja poss´ıvel abrir o arquivo com nome filename.
Essa exce¸c˜ao ser´a tratada pelo bloco do catch da linha 9. Por ´ultimo, caso a linha 5
levante a exce¸c˜ao CloneNotSupportedException, esta ser´a propagada para o bloco
try mais externo, onde ser´a capturada pelo bloco catch referente ao tipo correto
da exce¸c˜ao, na linha 13. Caso a exce¸c˜ao CloneNotSupportedException n˜ao seja
lan¸cada, a execu¸c˜ao da chamada ao m´etodo showScreen (linha 12) vai ocorrer. Mas
caso a exce¸c˜ao CloneNotSupportedException seja levantada n˜ao ocorre a chamada
ao m´etodo. Por outro lado, as exce¸c˜oes NullPointerException e IOException que
podem ser levantadas nas linhas 4 e 5 n˜ao mudam a possibilidade da chamada ao
m´etodo showScreen, pois o escopo onde essas exce¸c˜oes est˜ao sendo tratadas ´e um
escopo diferente do escopo de execu¸c˜ao do m´etodo showScreen.
1 try {
2 try {
3 ...
4 Fi l eReader fr = new F ileRead e r ( filena m e );
5 Fi l eReader fr2 = fr . c lone () ;
6 ...
7 } catch ( N u llPo i nter Exce p tion npe ) {
8 System . out . println ( " Null Point e r Excep t ion hand l in g ... ");
9 } catch ( IO E xceptio n npe ) {
10 System . out . println ( " I/ O Excep t i on hand l i ng ... ") ;
11 }
12 sh o wScreen () ;
13 } catch ( Cl o neN o tSup port edEx cept i on npe ) {
14 System . out . println ( " C l one Not Suppor t ed Exce p tion ha n d li ng ... ") ;
15 } finally {
16 System . out . println ( " Finally block code execu t i ng ... ") ;
17 }
Figura 2.1: Exemplo do tratamento de exce¸c˜oes em Java.
Quando uma linha de c´odigo levanta uma exce¸c˜ao, automaticamente a infra-
estrutura de tempo de execu¸c˜ao de Java procura o tratador daquele tipo de exce¸c˜ao
no escopo mais pr´oximo, ou a aplica¸c˜ao encerra, caso nenhum tratador seja encon-
trado. Quando encontra o c´odigo tratador da exce¸c˜ao, come¸ca a sua execu¸c˜ao at´e
o final do c´odigo contido no bloco, e quando acaba a execu¸c˜ao o fluxo volta para
depois do ´ultimo catch vinculados ao bloco try que levantou a exce¸c˜ao. Al´em disso,
a linguagem Java tamb´em possui a diretiva finally, que possui um bloco de c´odigo
11
que sempre ´e executado, caso uma exce¸c˜ao seja levantada ou n˜ao ou mesmo que n˜ao
haja um tratador espec´ıfico para uma exce¸c˜ao levantada. O c´odigo apresentado na
Figura 2.1 tamb´em apresenta um bloco de c´odigo com a diretiva finally associado.
2.3 Programa¸c˜ao Orientada a Aspectos e AspectJ
A separa¸c˜ao de interesses ´e um dos principais fundamentos do projeto (design) e
da implementa¸c˜ao no desenvolvimento de software [17]. Esse princ´ıpio determina
que a organiza¸c˜ao do software deve ser tal que cada elemento (classe, m´etodo, pro-
cedimento, arquivo, recurso etc.) tenha somente uma funcionalidade e somente essa
funcionalidade. Assim, cada elemento focar na sua finalidade, sem a necessidade de
conhecimento dos outros elementos. Pode-se compreender cada parte do programa
pelo seu assunto, sem necessidade de conhecimento de outros elementos.
Embora se concorde geralmente que a separa¸c˜ao de interesses ´e uma boa pra-
tica na engenharia de software [39], ´e dif´ıcil de definir o significado real de um
determinado interesse. Algumas vezes, esse interesse ´e definido como uma no¸c˜ao
funcional que precisa abranger todo o sistema. Assim, os interesses s˜ao mais do que
simples elementos funcionais e a defini¸c˜ao mais geral ´e t˜ao vaga que ´e praticamente
in´util [39]. Muitos dos interesses possuem implementa¸c˜ao que afetam v´arios m´odulos
dos sitemas [29]. Esses interesses s˜ao chamados de interesses tranversais. Usando os
m´etodos de programa¸c˜oes da atualidade, os interesses transversais tendem a se es-
palhar por diversos m´odulos do sistema, podendo deixar o sistema com dif´ıcil projeto
(design), entendimento e desenvolvimento. A Programa¸c˜ao Orientada a Aspectos
(POA) foi apresentada no ano de 1997 por Gregor Kiczales, John Lamping, Anurag
Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier e John Irwin [27],
desenvolvida em Palo Alto, nos laborat´orios da Xerox (Xerox PARC). O objetivo
dessa nova abordagem de desenvolvimento ´e tornar poss´ıvel `as linguagens de pro-
grama¸c˜ao expressar de forma ideal as caracter´ısticas ortogonais ou transversais do
comportamento do programa.
POA estende outras linguagens e t´ecnicas de programa¸c˜ao, como linguagens
orientadas a objetos e programa¸c˜ao estruturada, propondo n˜ao apenas uma de-
composi¸c˜ao funcional, mas tamb´em sistˆemica do problema. Assim, POA permite a
separa¸c˜ao de implementa¸c˜ao de interesses transversais do sistema, sendo os aspectos
a abstra¸c˜ao para separa¸c˜ao dos interesses transversais, enquanto os demais interesses
(n˜ao transversais) utilizam os recursos da pr´opria linguagem estendida pela lingua-
gem de POA. A orienta¸c˜ao a aspectos trabalha em paralelo com outros paradigmas,
portanto, os conceitos podem ser aplicados a linguagens dos paradigmas orientado
12
a objetos, imperativo, funcional e l´ogico. Na Tabela 2.1 s˜ao apresentadas algumas
linguagens de programa¸c˜ao e extens˜oes dessas linguagens para POA [44].
Linguagem Extens˜ao POA
Principal
Java AspectJ [29], AspectWerkz [49], CaesarJ [50], JBoss AOP [12],
LogicAJ [53], The Spring Framework [13]
C#/VB.NET Aspect.NET [36], AspectDNG [47], Seasar.NET [54], Eos [51],
The Spring.NET Framework [14]
C/C++ AspectC [45], AspectC++ [46], XWeaver project [55]
Lua AspectLua [48]
Haskell AspectH [1]
Tabela 2.1: Algumas Linguagens de Programa¸c˜ao e suas Extens˜oes para POA [44].
2.3.1 Conceitos Fundamentais da Orienta¸c˜ao a Aspectos
A orienta¸c˜ao a aspectos possui quatro conceitos fundamentais. Esses conceitos s˜ao:
• Aspecto. O aspecto ´e para uma linguagem orientada a aspectos o mesmo
que uma classe ´e para uma linguagem orientada a objetos.
´
E o mecanismo
disponibilizado por POA para agrupar fragmentos de c´odigo referentes aos
componentes transversais em uma unidade no sistema, e que, sem os aspec-
tos, estariam implementados de forma espalhada e entrela¸cada com outros
interesses.
• Pontos de jun¸c˜ao (join points). Os pontos de jun¸c˜ao s˜ao locais bem
definidos na execu¸c˜ao de um programa onde a execu¸c˜ao de um interesse trans-
versal e de um n˜ao-transversal se sobrep˜oem. Exemplos de pontos de jun¸c˜ao
incluem chamadas a m´etodos ou ocorrˆencias de exce¸c˜oes, entre outros. Pontos
de jun¸c˜ao tˆem contexto associado, como, por exemplo, os argumentos de um
m´etodo.
• Pontos de corte (pointcuts). Pontos de corte s˜ao elementos de uma lingua-
gem de programa¸c˜ao orientada a aspectos usados para selecionar um conjunto
de pontos de jun¸c˜ao. A forma como pontos de corte s˜ao especificados, bem
como seu poder expressivo, dependem do modelo de pontos de jun¸c˜ao da lin-
guagem orientada a aspectos empregada.
• Advice. Os advice s˜ao unidades de implementa¸c˜ao definidas por um aspecto e
executados em pontos bem definidos do programa principal (pontos de jun¸c˜ao).
13
O advice cont´em o ponto de corte que captura o contexto de execu¸c˜ao de c´odigo
e o c´odigo a ser executado, caso o ponto de jun¸c˜ao venha ocorrer. Um advice
tem comportamento semelhante a um m´etodo, mas sua fun¸c˜ao ´e declarar o
c´odigo que deve ser executado a cada ponto de jun¸c˜ao em um ponto de corte.
2.3.2 AspectJ
AspectJ ´e uma extens˜ao orientada a aspectos da linguagem Java. Assim, ´e necess´aria
uma preocupa¸c˜ao com a compatibilidade de quatro itens importantes:
• Compatibilidade Total: Todo programa Java v´alido ´e necessariamente
tamb´em um programa AspectJ v´alido.
• Compatibilidade de Plataforma: Todo programa AspectJ pode ser exe-
cutado em uma m´aquina virtual Java (JVM).
• Compatibilidade de Ferramentas: Deve ser poss´ıvel estender ferramentas
existentes para dar suporte a AspectJ de uma forma natural, incluindo IDEs,
ferramentas de documenta¸c˜ao e ferramentas de projeto.
• Compatibilidade para o Programador: Ao programar com AspectJ, o
programador deve sentir-se como estivesse utilizando uma extens˜ao da lingua-
gem Java.
AspectJ implementa dois tipos de composi¸c˜ao: dinˆamica e est´atica. A com-
bina¸c˜ao dinˆamica adiciona novos comportamentos `a execu¸c˜ao de um programa, au-
mentando ou substituindo partes de seu fluxo de execu¸c˜ao. J´a a composi¸c˜ao est´atica
consiste na combina¸c˜ao modifica¸c˜ao da estrutura de um programa, atrav´es da cria¸c˜ao
de novos elementos (classes, interfaces e aspectos) ou de novos relacionamentos entre
esses elementos. Esses interesses n˜ao alteram diretamente o comportamento de um
sistema, mas d˜ao suporte para que este seja alterado pela implementa¸c˜ao de inter-
esses introduzidos atrav´es de composi¸c˜ao dinˆamica.
A linguagem AspectJ implementa os quatro conceitos b´asicos de uma linguagem
orientada a aspectos. Esses conceitos, com descrito anteriormente, s˜ao os Aspectos,
Pontos de Jun¸c˜ao, Pontos de Corte e Advice.
Geralmente, aspecto define pointcuts, os quais selecionam pontos de corte e va-
lores nestes pontos de corte e advices que definem o comportamento a ser tomado ao
alcan¸car os pontos de corte definidos pelo pointcuts. Um pointcut ´e composto por
um nome, que ´e sua identifica¸c˜ao, junto com pontos de jun¸c˜ao associados e tamb´em
pode conter outros pointcuts. A composi¸c˜ao de pontos de jun¸c˜ao e pointcuts pode
14
1 public class ClassA {
2 // M´etodo 1
3 public void method1 () {
4 // ... corpo do m ´etodo 1
5 }
6 // M´etodo 2
7 public void method2 () {
8 // ... corpo do m ´etodo 2
9 }
10 // M´etodo 3
11 public Stri n g method3 () {
12 // ... corpo do m ´etodo 2
13 }
14 }
Figura 2.2: Classe Java afetada por um Aspecto.
ser dada junto com os operadores && (e), —— (ou) e !(n˜ao). J´a um advice ´e a
implementa¸c˜ao de c´odigo que ser´a executada quando um determinado fluxo for exe-
cutado. O advice pode executar antes da execu¸c˜ao do fluxo indicada no ponto de
jun¸c˜ao (before), depois da execu¸c˜ao (after) ou at´e mesmo pegar todo o controle
de execu¸c˜ao (around). Esse ´ultimo, possui a diretiva proceed() que devolve o fluxo
de excu¸c˜ao ao local interceptado no c´odigo, recebendo novamente o fluxo quando a
execu¸c˜ao do local afetado termina.
Nos trechos de c´odigo mostrados nas Figuras 2.2 e 2.3 s˜ao apresentados uma
classe Java e um aspecto AspectJ que afeta essa classe. O trecho de c´odigo da
Figura 2.2 apresenta uma classe Java com trˆes m´etodos. O trecho de c´odigo da Fi-
gura 2.3 apresenta trˆes pointcut’s que interceptam o c´odigo da classe A. O primeiro
pointcut, linha 3, captura a execu¸c˜ao do m´etodo method1(). O segundo pointcut,
linhas 5 e 6, captura chamadas ao m´etodo method3(), mas somente quando aconte-
cem dentro do m´etodo method2(). O ´ultimo pointcut, linha 8, captura a execu¸c˜ao
do m´etodo method3(). O advice associado ao pointcut pcMethod1() ´e mostrado
nas linhas 10-14. Esse advice executa antes da execu¸c˜ao de todo o m´etodo, pois o
tipo modificador do advice ´e around.
A diretiva proceed(), como mostrado na linha 11, passa a execu¸c˜ao do advice do
aspecto para o m´etodo interceptado no ponto de jun¸c˜ao associado. Ap´os a execu¸c˜ao
do m´etodo que tem o ponto de jun¸c˜ao associado, ou caso o m´etodo levante alguma
exce¸c˜ao, o fluxo de execu¸c˜ao volta para o advice na linha seguinte onde a diretiva
proceed() foi executada. Mas existem outros dois tipos de advice: before e after.
15
1 public aspect AspectA {
2 // P o intcu t 1
3 poi n t cu t pcMet h od 1 () : exec u t ion (* ClassA . method1 () );
4 // P o intcu t 2
5 poi n t cu t pcMet h od 2 () : call (* C l a s s A . method3 () )
6 && wit h in code (* ClassA . met h o d 2 () ) ;
7 // P o intcu t 3
8 poi n t cu t pcMet h od 3 () : call (* C l a s s A . method3 () );
9 // Adv i ce 1
10 void around () : pcMeth o d1 () {
11 proce e d ();
12 // ... Corpo do a dvice que i m ple m ent a o p ointc ut p cMet h od1 ()
13 }
14 // Adv i ce 2
15 before () : pcM e t hod2 () {
16 // ... Corpo do a dvice que i m ple m ent a o p ointc ut p cMet h od2 ()
17 }
18 // Adv i ce 3
19 after () : p cM ethod3 () {
20 // ... Corpo do a dvice que i m ple m ent a o p ointc ut p cMet h od3 ()
21 }
22 }
Figura 2.3: Aspecto que afeta a ClasseA.
O primeiro executa antes do ponto de jun¸c˜ao do pointcut vinculado e o segundo
depois. O advice after pode executar depois da execu¸c˜ao com sucesso do pointcut
vinculado after returning; depois da execu¸c˜ao do pointcut vinculado quando
uma exce¸c˜ao for levantada after throwing, passando a execu¸c˜ao para o advice
sempre que for levantada uma exce¸c˜ao e ela n˜ao for tratada no c´odigo; ou ainda
independente de se a execu¸c˜ao do pointcut vinculado com sucesso ou n˜ao.
Mais detalhes sobre a linguagem AspectJ pode ser obtida no trabalho de Kick-
zales et al. [27] e no site oficial da linguagem: http://www.eclipse.org.br/aspectj/.
2.3.3 Tratamento de Exce¸c˜oes em AspectJ
Assim como programas escritos na linguagem Java, AspectJ tamb´em disponibiliza
tratamento de exce¸c˜oes, dentro do corpo dos advice. Utiliza-se da mesma estrutura
e fluxo apresentado na linguagem Java, com as diretivas try, catch e finally.
Como o tratamento de exce¸c˜oes ´e um interesse transversal, o c´odigo contido do
aspecto pode substituir o c´odigo tratador de exce¸c˜oes nos programas Java, deixando
as classes Java somente com a responsabilidade de implementar o comportamento
normal (sem exce¸c˜oes) da aplica¸c˜ao.
Existem dois modos de capturar uma exce¸c˜ao advinda da execu¸c˜ao de c´odigo
Java. A primeira ´e utilizando o advice do tipo after throwing. Esse tipo de advice
come¸ca sua execu¸c˜ao quando o ponto de jun¸c˜ao associado levanta uma exce¸c˜ao e
16
1 public aspect AspectB {
2 // P o intcu t 1
3 poi n t cu t pcMet h od A () : call (* C l a s s B . methodB () )
4 && wit h incode (* ClassB . m e t ho d A () ) ;
5 // P o intcu t 2
6 poi n t cu t pcMet h od B () : exec u t ion (* C l a s s B . methodB () );
7 // Adv i ce 1
8 void around () : pcMeth o dB () {
9 try {
10 proceed () ;
11 } catch ( E x ception e ){
12 e. p rint S tackT r ace () ;
13 }
14 }
15 // Adv i ce 2
16 after () t h ro wi ng ( Exce p ti on e) : pcMeth o dA () {
17 e. pri n tSta c kTrac e () ;
18 }
19 }
Figura 2.4: Exemplo de Tratamento de Exce¸c˜oes em AspectJ.
n˜ao a trata. Assim, toda vez que o c´odigo Java lan¸ca uma exce¸c˜ao e n˜ao trata, o
fluxo de execu¸c˜ao passa a ser o que estiver definido dentro do advice. O segundo
modo de capturar ´e utilizando o advice do tipo around e incluir nele um comando
proceed() dentro de um bloco try-catch. Dessa forma, o ponto de jun¸c˜ao associado
´e executado quando o comando proceed() ´e chamado. Caso uma exce¸c˜ao ocorra,
ela ´e levantada no contexto de tratamento de exce¸c˜oes onde o comando proceed()
usado, o que ativa os blocos catch e finally associados.
A listagem apresentada na Figura 2.4 apresenta um exemplo de tratamento de
exce¸c˜oes em AspectJ. O primeiro modo de captura e tratamento de exce¸c˜oes ´e apre-
sentado com o pointcut na linha 3 e o advice associado, nas linhas 16-18. Para
esse caso, o fluxo de execu¸c˜ao s´o ´e transferido para o advice caso seja levantada uma
exce¸c˜ao do tipo Exception. J´a no segundo caso, onde o pointcut ´e apresentado na
linha 6 e o advice nas linhas 8-14, o fluxo de execu¸c˜ao passa primeiro para o advice.
Ap´os a chamada do proceed() ´e que o controle passa para o m´etodo que vai ser
executado (o ponto de jun¸c˜ao selecionado). Caso uma exce¸c˜ao do tipo Exception
seja levantada em methodB() e este n˜ao a trate, a execu¸c˜ao volta para o advice e
´e tratada dentro do bloco catch (linhas 11-13).
17
2.4 M´etricas Est´aticas de C´odigo
M´etrica est´atica de c´odigo ´e um modo de medir alguma propriedade de uma parte
de um c´odigo, ou de sua especifica¸c˜ao. Diferente de alguns outros tipos de m´etricas
como, por exemplo, tempo de execu¸c˜ao e uso de mem´oria, m´etricas est´aticas de
c´odigo n˜ao necessitam da execu¸c˜ao do c´odigo. Ao inv´es da execu¸c˜ao, ´e feita uma
an´alise est´atica do c´odigo, que ´e utilizada para auxiliar na an´alise de atributos de
qualidade do c´odigo de um sistema. Assim, ´e poss´ıvel inferir alguns valores referentes
`a qualidade do c´odigo, comparando com algum valor previamente definido. Tamb´em
´e poss´ıvel prever algum erro que ocorreria durante a execu¸c˜ao do c´odigo. Existe uma
vasta gama de atributos que podem ser analisados usando-se m´etricas est´aticas de
c´odigo como: usabilidade, seguran¸ca, corretude do c´odigo, complexidade, facilidade
de compreens˜ao, entre muitas outras.
Grandes empresas, como Hewlett-Packard, AT&T, e Nokia introduziram pro-
gramas de m´etricas e est˜ao usando-as para coletar principalmente defeitos em seus
programas [39]. Muitas empresas ainda n˜ao utilizam m´etricas de c´odigo, por´em.
Geralmente essas empresas n˜ao possuem processos de desenvolvimento de software
maduros e bem definidos [39].
´
E praticamente imposs´ıvel medir diretamente atributos da qualidade do soft-
ware [32]. Atributos como facilidade de manuten¸c˜ao, legibilidade e outros, s˜ao refe-
rentes a atributos externos, que est˜ao ligados a como os desenvolvedores e usu´arios
vˆeem o sistema de software. Os atributos que podem ser medidos diretamente s˜ao
os atributos internos dos sistemas de software, como tamanho, estrutura do c´odigo
e caracter´ısticas que podem ser obtidas de maneira direta a partir do c´odigo. Ideal-
mente, deve haver um relacionamento claro e validade entre os atributos internos e
externos do c´odigo [32].
Abaixo s˜ao descritas algumas das m´etricas est´aticas de c´odigo mais comuns e
outras novas relativas a separa¸c˜ao de interesses:
• Tamanho do C´odigo: ´e o tamanho do sistema todo. Geralmente, quanto
maior o programa, mais dif´ıcil de entendˆe-lo e modific´a-lo e mais prop´ıcio a
erros. Essa rela¸c˜ao n˜ao ´e universal, por´em.
• Complexidade ciclom´atica [31]: ´e uma m´etrica muito popular origin´aria
do paradigma procedimental ou estruturado. Indica o n´umero de caminhos
que podem ser seguidos dentro de um procedimento: n´umero de comandos
if/else, switches, ciclos. Esta m´etrica, adaptada ao paradigma OO, tanto
pode ser utilizada para m´etodos quanto para classes, somando a complexidade
ciclom´atica dos seus m´etodos.
18
• Profundidade de aninhamento [9]: ´e a medida de aninhamento entre blo-
cos de c´odigo. Pode ser dada por blocos condicionais, dentro de blocos de la¸cos,
blocos try, etc. Essa m´etrica ajuda a determinar o qu˜ao complexa ´e a com-
puta¸c˜ao realizada por determinado trecho de c´odigo, tanto do ponto de vista
de consumo de recursos computacionais quanto de facilidade de compreens˜ao.
• Degree of Focus [18]: verifica o quanto as linhas de c´odigo de um deter-
minado componente est˜ao direcionadas a um interesse espec´ıfico, podendo o
c´odigo ser totalmente focado ou totalmente desfocado.
• Concern Diffusion of Components [24]: verifica a quantidade de compo-
nentes prim´arios que possui c´odigo que implementa o interesse medido.
19
Cap´ıtulo 3
Reuso Intra-Applica¸c˜ao
Esse cap´ıtulo aborda o reuso de c´odigo para tratamento de exce¸c˜oes, dentro do
contexto de uma mesma aplica¸c˜ao, ou seja, reuso intra-aplica¸c˜ao. Para ava-
liar a possibilidade de se reusar c´odigo de tratamento de exce¸c˜oes dentro de uma
aplica¸c˜ao usando programa¸c˜ao orientada a aspectos (POA), foi feito um estudo
utilizando algumas aplica¸c˜oes do mundo real pertencentes a diferentes dom´ınios.
Os resultados desse estudo apontam que ´e poss´ıvel reusar c´odigo de tratamento de
exce¸c˜oes dentro de uma mesma aplica¸c˜ao, como tamb´em a confirma¸c˜ao da separa¸c˜ao
do interesse tratamento de exce¸c˜oes, em rela¸c˜ao ao comportamento normal do sis-
tema. Esse estudo foi publicado no XXIII Simp´osio Brasileiro de Engenharia de
Software(SBES’09) [42].
Nas pr´oximas se¸c˜oes o estudo proposto ´e descrito em detalhes. A Se¸c˜ao 3.1 mos-
tra a metodologia do estudo. Na Se¸c˜ao 3.2 s˜ao apresentados os sistemas utilizados
no estudo. Na Se¸c˜ao 3.4 apresenta o conjunto de m´etricas utilizadas nesse estudo
para analisar o c´odigo e fazer um comparativo num´erico entre as vers˜oes dos siste-
mas utilizadas. As refatora¸c˜oes para se estruturar c´odigo de tratamento de exce¸c˜oes
a fim de reusar, incluindo uma explica¸c˜ao sobre como o tratamento de exce¸c˜oes foi
reusado, ´e apresentadas na Se¸c˜ao 3.3. Por ´ultimo s˜ao mostrados os resultados (Se¸c˜ao
3.5) do estudo e as conclus˜oes (Se¸c˜ao 3.6) obtidas.
3.1 Metodologia
Esse trabalho aborda as limita¸c˜oes de estudos anteriores [30, 6], apresentando um
novo estudo com o objetivo de avaliar se a utiliza¸c˜ao de aspectos para modulari-
zar tratadores de exce¸c˜oes possa promover reuso de c´odigo relativo a esse interesse.
Foram comparadas duas alternativas para modularizar o tratamento de exce¸c˜oes,
fazendo um comparativo entre as duas e uma abordagem original orientada a obje-
20
tos. A primeira ´e uma abordagem orientada a objeto, com os tratadores de exce¸c˜oes
em novas classes Java e uma segunda abordagem com os tratadores de exce¸c˜oes den-
tro de aspectos, na linguagem AspectJ. Para as duas ´ultimas abordagens, o c´odigo
foi completamente analisado e revisado a fim de identificar ao m´aximo oportuni-
dades de reuso e combina¸c˜ao de tratadores de exce¸c˜oes. No estudo foram verificadas
situa¸c˜oes em que POA cria oportunidades de reuso contrapondo com POO e vice-
versa. Foram tamb´em analisadas constru¸c˜oes de linguagens que influenciaram essas
oportunidades de reuso, ou limita¸c˜oes que influenciaram o n˜ao reuso. A avalia¸c˜ao
foi feita com utiliza¸c˜ao de m´etricas espec´ıficas para avaliar o c´odigo de tratamento
de exce¸c˜ao, tanto ao reuso quanto `a modulariza¸c˜ao, exceto apenas em uma m´etrica
que ´e bastante gen´erica.
Os trˆes sistemas utilizados no estudo e apresentados na Se¸c˜ao 3.2 foram imple-
mentados originalmente na linguagem Java. As refatora¸c˜oes necess´arias no c´odigo
desses sistemas foram feitas por 8 pessoas, divididas em quatro grupos de duas pes-
soas e fazendo programa¸c˜ao em pares, a fim de garantir uma melhor qualidade na
refatora¸c˜ao. Al´em disso, os grupos eram alternados frequentemente, a fim de se
evitar v´ıcios em determinada atividade e produzindo uma melhor difus˜ao de conhe-
cimento entres os membros da equipe.
´
E importante salientar as principais diferen¸cas entre esse estudo e os estudos
anteriores que abordaram a utiliza¸c˜ao de POA para combinar tratadores de exce¸c˜ao.
Em primeiro lugar, foram utilizados sistemas de reais de tamanho m´edio, enquanto
o estudo de Lippert e Lopes [30] empregou uma infraestrutura com tratadores de
exce¸c˜oes muito simples. O segundo ´e que diferentemente do trabalho de Castor
Filho et al. [6], esse trabalho empregou desenvolvedores em pares na tentativa de
reutiliza¸c˜ao sistem´atica de tratadores de exce¸c˜ao, tanto quanto poss´ıvel. Al´em disso
os pares foram alternados frequentemente e os pares revisaram o trabalho de outros,
a fim de oportunidades de reuso n˜ao serem perdidas.
3.2 Sistemas Utilizados
O estudo abordando o reuso intra-aplica¸c˜ao focou em trˆes aplica¸c˜oes Java. Essas
aplica¸c˜oes s˜ao relevantes para o estudo por diversas raz˜oes. Primeiro, s˜ao sistemas
reais e desenvolvidas de forma independente na ind´ustria. Segundo, porque cada
um desses sistemas possui pelo menos 15.000 LOC e pelo menos 1% dessas linhas de
c´odigos s˜ao relativas ao tratamento de exce¸c˜oes. Terceiro, porque as trˆes aplica¸c˜oes
possuem dom´ınio e plataforma diferentes e foram escritas em Java. Este ´ultimo
fator ´e importante porque as principais implementa¸c˜oes de POA s˜ao extens˜oes de
21
Java. Por fim, as aplica¸c˜oes possuem diversos tratadores de exce¸c˜oes n˜ao-triviais.
A primeira aplica¸c˜ao ´e o Checkstyle Plugin
1
, um plugin para a plataforma
Eclipse
2
que verifica estilo de codifica¸c˜ao de programas escritos em Java. A vers˜ao
original da aplica¸c˜ao possui 19.197 LOC (linhas compil´aveis, excluindo linhas em
branco e coment´arios) e mais de 290 classes e interfaces. A segunda aplica¸c˜ao, a
Java PetStore
3
, ´e um demo para a plataforma Java Enterprise Edition (Java EE),
uma representa¸c˜ao de solu¸c˜oes Java para aplica¸c˜oes B2B e similares. Essa aplica¸c˜ao
implementa v´arias tecnologias dispon´ıveis na plataforma Java EE. A vers˜ao original
da Java PetStore possui aproximadamente 17.500 LOC e 330 classes e interfaces. A
terceira aplica¸c˜ao ´e o JHotDraw
4
, um framework de GUI Java para gr´aficos t´ecnicos
e estruturados. A vers˜ao original da aplica¸c˜ao possui aproximadamente 23.000 LOC
e mais de 400 classes e interfaces.
3.3 Extra¸c˜ao e Reutiliza¸c˜ao de Tratadores de
Exce¸c˜oes
Para avaliar os benef´ıcios da utiliza¸c˜ao de POA no tratamento de exce¸c˜oes, uma
nova abordagem foi utilizada, consistindo na a extra¸c˜ao dos tratadores de exce¸c˜oes e
reuso para novas classes Java, respons´aveis por implementar somente o tratamento
de exce¸c˜oes. Assim, pode-se obter duas vers˜oes: (i) vers˜ao com o tratamento de
exce¸c˜oes em novas classes Java e (ii) vers˜ao com o tratamento de exce¸c˜oes dentro de
aspectos AspectJ. A id´eia de extrair tratadores para novas classes Java ´e motivada
pela inten¸c˜ao de reutilizar tratadores tanto quanto poss´ıvel, tanto em Java quanto
em AspectJ. As refatora¸c˜oes foram feitas em duas etapas. A primeira diz respeito
`a extra¸c˜ao dos tratadores de exce¸c˜oes para dentro dos aspectos e das novas classes.
A segunda etapa foi o reuso. A Figura 3.1 apresenta o fluxo do trabalho para cada
vers˜ao de extra¸c˜oes e etapas utilizadas. Nas se¸c˜oes subsequentes s˜ao descritos os
procedimentos realizados para a extra¸c˜ao do tratamento de exce¸c˜ao (Se¸c˜ao 3.3.1) e
para reusar esses tratadores (Se¸c˜ao 3.3.2).
3.3.1 Extra¸c˜ao do Tratamento de Exce¸c˜oes
Como descrito na Se¸c˜ao 3.3, esse estudo comparou trˆes vers˜oes de cada sistema alvo:
(i) uma vers˜ao original, implementada em Java; (ii) uma vers˜ao refatorada OO,
1
http://eclipse-cs.sourceforge.net/
2
http://www.eclipse.org/
3
http://java.sun.com/developer/releases/petstore/
4
http://www.jhotdraw.org/
22
Figura 3.1: Fluxo das Refatora¸c˜oes.
tamb´em implementada em Java; e (iii) uma vers˜ao refatorada AO, implementada
em AspectJ. As trˆes vers˜oes possuem as mesmas funcionalidades. A diferen¸ca ´e
que, nas duas ´ultimas vers˜oes, os tratadores de exce¸c˜oes foram movidos para novas
classes e novos aspectos, respectivamente.
Foi considerado c´odigo de tratamento de exce¸c˜oes todo o c´odigo que s´o existe
para prover uma solu¸c˜ao para um erro (exce¸c˜ao) e que poderia ser removido, caso
tratar tal erro n˜ao fosse mais necess´ario. Essa defini¸c˜ao est´a de acordo com as id´eias
apresentadas por Eaddy et al. [18]. A defini¸c˜ao inclui os blocos catch e finally,
junto com a linha em que o blocos try ´e declarado (mas n˜ao o c´odigo interno a
ele, que pertence `a atividade normal da aplica¸c˜ao). A cl´ausula throws, bem como
o comando throw n˜ao s˜ao considerados pertencentes ao interesse de tratamento de
exce¸c˜oes.
´
E importante enfatizar que, em cada vers˜ao refatorada OO, o c´odigo de
captura de exce¸c˜oes (blocos try-catch-finally) n˜ao pode ser extra´ıdo para as
novas classes, diferentemente da vers˜ao refatorada AO, por limita¸c˜ao tecnol´ogica.
Para essas vers˜oes, somente o c´odigo interno aos blocos catch e finally foi movido
para as novas classes, com cada bloco catch ou finally resultando na cria¸c˜ao de
um novo m´etodo nessas classes.
O primeiro passo para extra¸c˜ao do c´odigo foi mover todos os tratadores, quando
poss´ıvel, das classes regulares Java para dentro das classes que somente se referem
ao tratamento de exce¸c˜oes. Uma classe foi criada para cada pacote dos sistemas
que possui algum tratamento de exce¸c˜ao. Somente o conte´udo interno dos blocos
23
catch e finally foi movido para dentro de novos m´etodos e dentro desses blocos
foram adicionadas chamadas ao novo m´etodo criado. Em alguns casos, foi necess´ario
adicionar parˆametros aos m´etodos tratadores de exce¸c˜oes criados, a fim de enviar
algumas informa¸c˜oes necess´arias ao tratamento. O trecho de c´odigo na Figura 3.2
apresenta um exemplo de c´odigo Java que foi extra´ıdo. O trecho de c´odigo na Figura
3.3 apresenta o resultado de se extrair o c´odigo de tratamento de exce¸c˜oes, incluindo
uma chamada a um novo m´etodo da nova classe que foi criada (apresentada no trecho
de c´odigo na Figura 3.4). Se um bloco try ou catch escrever em algum atributo
de tipo primitivo privado, vari´avel local, ou parˆametro do m´etodo, essa refatora¸c˜ao
n˜ao ´e poss´ıvel pois esses elementos n˜ao s˜ao acess´ıveis aos novos m´etodos que tratam
as exce¸c˜oes. Essa limita¸c˜ao ´e por conta de que uma altera¸c˜ao em uma vari´avel pode
n˜ao refletir na parte original.
1 public class C heck Sele cted F ile s Acti on {
2 ... public void run ( IAction actio n ) {
3 ... try {
4 add F ileR e sour c es ( m S e lection . toList () , file s ToChec k );
5 } catch () {
6 Chec k style L og . e r rorDia l og ( mPart . getSite () . ge t S he ll () , e , true );
7 // one or more line s
8 }...
9 }.. .
10 }
Figura 3.2: C´odigo Original da Classe CheckSelectedFilesAction.
1 public class C heck Sele cted F ile s Acti on {
2 Ac t ionHa n dler actionH = new Act i onHan d ler () ;
3 ... public void run ( IAction actio n ) {
4 ... try {
5 add F ileR e sour c es ( m S e lection . toList () , file s ToChec k );
6 } catch () {
7 actionH . e rro r Dial ogCh e cks t yle L og (
8 mPart . getSite () . get S h el l () ,e , true ) ;
9 } ...
10 } ...
11 }
Figura 3.3: C´odigo da Classe CheckSelectedFilesAction Refatorada OO.
24
1 public class A ctio nExc e ptio nHan d ler {
2 ... public void er rorD i alo g Chec ksty l eLo g ( Shell shell , Excep t i on e ,
3 boolean b ) {
4 C h eckst y leLog . erro r Dialog ( shell , e , b );
5 }.. .
6 }
Figura 3.4: C´odigo da Classe ActionExceptionHandler.
O segundo passo da extra¸c˜ao consistiu em mover os tratadores de exce¸c˜oes para
dentro dos aspectos, a partir da vers˜ao original de cada sistema utilizado. Para cada
pacote existente em cada sistema, foi criado um novo aspecto para ser respons´avel
pelo tratamento de exce¸c˜oes. Para uniformizar o trabalho, foram utilizados somente
advice do tipo around para os novos tratadores de exce¸c˜oes, uma vez que eles tˆem
poder suficiente para implementar uma variedade de estrat´egias de tratamento de
exce¸c˜oes [6]. Para esta fase do trabalho, foi criado um novo advice para cada conjunto
de blocos try-catch. Todos os blocos catch associados a um mesmo bloco try do
c´odigo foram movidos para o mesmo advice. Adicionalmente, os blocos finally
foram movidos para um outro advice, a fim de separar o tratamento de exce¸c˜oes
(blocos catch) das a¸c˜oes de limpeza associadas (blocos finally). O trecho de
c´odigo na Figura 3.5 apresenta o resultado de extrair os tratadores do trecho de
c´odigo na Figura 3.2 para aspectos. Observa-se que o comando try, junto com o
bloco catch tamb´em foram removidos. Caso a necessidade de na refatora¸c˜ao haver
desmembramento de um advice, por conta de existir mais de um bloco catch, ´e
necess´ario explicitar a ordem da execu¸c˜ao dos advice. A Figura 3.6 apresenta o advice
resultante da extra¸c˜ao, respons´avel por tratar a exce¸c˜ao do tipo CoreException.
Para os casos em que advice tratadores de exce¸c˜oes necessitam de atributos e
campos privados da classe, ´e necess´ario declarar os aspectos como privileged para
ter acesso a essas informa¸c˜oes. Em outro caso, quando o advice tratador de exce¸c˜ao
necessita de vari´aveis locais ao m´etodo, ´e necess´ario uma extrair um trecho de c´odigo
como um novo m´etodo [23], a fim de expor essas vari´aveis locais aos aspectos como
argumentos dos novos m´etodos criados. Em poucas situa¸c˜oes, por exemplo, os advice
tratadores de exce¸c˜oes lˆeem duas ou mais vari´aveis locais dos m´etodos extra´ıdos, n˜ao
´e poss´ıvel fazer a extra¸c˜ao sem comprometer o comportamento normal do sistema.
Assim, os tratadores de exce¸c˜oes permanecem do mesmo modo.
25
1 public class C heck Sele cted F ile s Acti on {
2 ... public void run ( IAction actio n ) {
3 ...
4 a d dFil e Reso u rces ( mSele c tion . toList () , f i lesToC h eck ) ;
5 ...
6
7 } ...
8 }
Figura 3.5: C´odigo da Classe CheckSelectedFilesAction Refatorada AO.
1 public p ri vileged aspect A cti o nAs p ect E xce p tion Hand ler
2 {
3 ... declare soft : C o reExc e ption : C h eck S ele cted Fil e sAc t ion Han d le_ r unH andl e () ;
4 ... point c ut C hec k Sel e cte dFil esA c tio n Han dle_ run H and l e () :
5 ex e c ution ( public void C heck S ele c ted F iles Acti o n . run (..) ) ;
6 ... voi d a r o u n d () : Ch eck S ele c ted File sAc t ion H and le_r unH a ndl e () {
7 try { pro c e e d () ; } catch ( C o reExc e ption e ) {
8 Ch e ckSe lect e dFi l esAc tion c =
9 ( C h eckS elec tedF i les A ctio n ) th i sJoin P oint . g et T hi s () ;
10 Chec k style L og . e r rorDia l og (c . mP art . g et S it e () . getShell () , e , true ) ;
11 }
12 }.. .
13 }
Figura 3.6: C´odigo do Aspecto ActionAspectExceptionHandler.
3.3.2 Reuso dos Tratadores de Exce¸c˜ao
Para reusar os tratadores de exce¸c˜ao, uma abordagem similar foi conduzida com as
vers˜oes refatoradas OO e refatoradas AO, levando-se em conta as diferen¸cas entre
os diferentes paradigmas. Para as vers˜oes refatoradas OO, o primeiro passo foi ins-
pecionar todos os tratadores de exce¸c˜ao existentes na classe tratadora de exce¸c˜ao
de cada pacote e procurar por tratadores similares, a fim de reus´a-los. M´etodos im-
plementando tratadores duplicados foram eliminados e as referˆencias aos m´etodos
exclu´ıdos foram modificadas para apontar para apenas um caso. Cada classe tra-
tadora de exce¸c˜oes foi revisada por pelo menos duas duplas diferentes. O pr´oximo
passo foi verificar a duplicidade de c´odigo, procurando tratadores de exce¸c˜oes, em
pacotes diferentes. Para esses casos, foram comparadas as classes existentes em pa-
cotes diferentes, olhando todo o sistema. Os casos de tratadores duplicados foram
movidos para uma classe respons´avel por tratadores globais, ou seja, que afetam
dois ou mais pacotes distintos. Classes tratadoras, interna nos pacotes, que necessi-
tassem desses tratamento deveriam estender essa classe a fim. Ao final dessa etapa,
classes tratadoras de exce¸c˜oes vazias, devido `a remo¸c˜ao de tratadores duplicados,
foram removidas. Na Figura 3.7 ´e apresentado um diagrama de classes para essa
solu¸c˜ao.
26
Figura 3.7: Diagrama de Classes das vers˜oes Ref. OO.
Para as vers˜oes refatoradas AO, o procedimento foi similar ao realizado para as
vers˜oes refatoradas OO. O primeiro passo foi a inspe¸c˜ao do c´odigo duplicado dentro
de cada aspecto, por pacote. Quando encontrados advice tratadores semelhantes,
esses s˜ao combinados em apenas um, verificando assim a possibilidade de reuso den-
tro de cada pacote. A complica¸c˜ao maior para esses casos ´e a relativa flexibilidade
de AspectJ. Por exemplo, quando diferentes tratadores precisam retornar valores
de tipos distintos, `as vezes, ´e poss´ıvel combin´a-los, dependendo da maneira como
funcionam. Esse tipo de combina¸c˜ao n˜ao ´e permitido para tratadores escritos pu-
ramente em Java, devido `a verifica¸c˜ao de tipos realizada pelo compilador de Java.
Essa flexibilidade faz com que o desenvolvedor tenha que levar mais quest˜oes em
considera¸c˜ao para combinar advice tratadores semelhantes. Adicionalmente, algu-
mas vezes, os conjuntos de blocos catch associados a diferentes blocos try n˜ao
puderam ser reusados em conjunto, mas blocos catch individuais puderam. Nessa
situa¸c˜ao, ´e necess´ario desagrupar os advice que possua v´arios blocos catch asso-
ciados a um ´unico bloco try, criando assim um advice, para cada bloco catch, o
que aumenta tanto o tamanho do sistema quanto o reuso de tratadores. Esse des-
membramento torna necess´ario ser expl´ıcito a ordem dos novos advice advindos dos
catch desmembrados.
Ap´os o reuso de tratadores em cada aspecto, dentro de cada pacote, o pr´oximo
passo foi semelhante ao reuso apresentado nas vers˜oes refatoradas OO. Um aspecto
geral global foi criado contendo c´odigo de tratadores de exce¸c˜oes similares, usados
em diferentes pacotes. Diferentemente das vers˜oes refatoradas orientadas a
objetos (Ver. Ref. OO), as vers˜oes refatoradas orientadas a aspectos (Ver.
Ref. AO) n˜ao podem usar heran¸ca para os aspectos de cada pacote herdarem os
27
tratadores semelhantes. N˜ao por limita¸c˜ao da linguagem, mas pelo motivo de nem
todos os aspectos concretos que estendem os aspectos abstratos n˜ao possuem a
necessidade de implementar os pointcut abstratos, pelo fato de n˜ao terem necessidade
do tratamento mais generalizado existente no aspecto abstrato. Os aspectos gerais
das aplica¸c˜oes interferem em cada classe Java, vindas da vers˜ao original, diretamente,
quando necess´ario. Na Figura 3.8 ´e apresentado o diagrama de classes dessa solu¸c˜ao,
mostrando onde cada pacote, aspectos e classes ficaram.
Figura 3.8: Diagrama de Classes das vers˜oes Ref. AO.
O trecho de c´odigo na Figura 3.9 mostra um m´etodo que ´e chamado por doze
diferentes blocos catch, em uma das aplica¸c˜oes. O trecho de c´odigo na Figura
3.10 apresenta o mesmo tratador de exce¸c˜oes do trecho de c´odigo na Figura 3.9, na
linguagem AspectJ. O tratador neste caso n˜ao ´e chamado por cada bloco catch. Ao
inv´es disso, o advice ´e associado a doze pontos de jun¸c˜oes diferentes no sistema.
1 ...
2 // Calle d by some code l ocat i on
3 public void r e thr o wCh e cks t yle P lug i nEx c ept i on ( Excepti o n e )
4 throws C heck s tyl e Plu g inEx cept ion {
5 Ch e cksty l eLog . log (e) ;
6 C h eck s tyle Plug inEx c ept i on . r e t h ro w (e) ;
7 }...
Figura 3.9: Exemplo de Reuso de Tratadores de Exce¸c˜ao nas Ver. Ref. OO.
28
1 ...
2 Object around () throws Ch e cks t yleP lugi nExc e pti o n :
3 R e tro w Exce ptio n_ru n Han d le () ||
4 P roj e ctC onf i gur ati o nFa cto r y_i nte r nal Loa d Fro mPe r sis ten c eHa ndl e r () ||
5 c heck Con f igu r ati onMi gra t or_ migr ate H and l er () ||
6 P roj e ctC onf i gur atio nEd i tor _in t ern alE n sur eFi l eEx ist s Han dle r () ||
7 E xte r nal Fil e Con figu rat i on_ int e rna lEn s ure Fil e Exi sts H and ler () ||
8 c heck Con f igu rat i onM igr a tor _ ens ure F ile Exis tsH a ndl er () ||
9 a u dito r_ru n Audi tHan d le () ||
10 P a cka geNa mesL oad e r_g e tPa c kag e Nam es () ||
11 C u sto m Lib r ari e sCl a ssL o ade r _ge t () ||
12 R e tro w Exc epti on_s etMo dule sHan dle () ||
13 R emo t eCo nfi g ura tio n Typ e_i n ter nal G etC hec k sty leC o nfi gur ati o nHa ndl e r () {
14 Object resu l t = null ;
15 try {
16 result = proceed () ;
17 } catch ( IO E xceptio n ioe ) {
18 Chec k style L og . log ( ioe ) ;
19 Ch e ckst yleP l ugi n Exc e ptio n . rethrow ( ioe );
20 }
21 return resu l t ;
22 }
23 ...
Figura 3.10: Exemplo de Reuso de Tratadores de Exce¸c˜ao na Ver. Ref. AO.
3.4 Conjunto de M´etricas
Para avaliar as refatora¸c˜oes, em cada um dos os trˆes sistemas e para cada vers˜ao
refatorada, foi utilizado um conjunto de m´etricas est´aticas de c´odigo. Para coletar
essas m´etricas foi utilizada uma ferramenta, desenvolvida a partir da AopMetrics
5
,
a EH-Meter. Mais informa¸c˜oes sobre a ferramenta s˜ao apresentadas no Cap´ıtulo 5.
Como o objetivo desse estudo ´e avaliar o reuso de c´odigo de tratadores de exce¸c˜oes,
foi escolhido um conjunto de m´etricas capaz de medir os efeitos do reuso de tra-
tadores de exce¸c˜oes. Uma premissa para a escolha desse conjunto de m´etricas ´e
que uma quantidade menor de c´odigo de tratamento de exce¸c˜oes duplicado ´e um
indicador confi´avel do reuso. Mais especificamente, foram selecionadas 11 m´etricas,
com 10 delas focadas em tratamento de exce¸c˜oes. Para todas as m´etricas, a redu¸c˜ao
dos seus valores indicam que o c´odigo obteve uma melhora, relativa a defini¸c˜ao de
cada uma das m´etricas.
As m´etricas selecionadas s˜ao divididas em dois grupos: m´etricas de tamanho e
m´etricas de interesse. A Tabela 3.1 descreve as m´etricas brevemente e as agrupa
pelo seus tipos. O primeiro grupo de m´etricas, m´etricas de tamanho, inclui as
m´etricas para atributos comuns dos sistemas (ex. N´umero de Linhas de C´odigo) e
quantidades relativas ao interesse tratamento de exce¸c˜oes (ex. N´umero de blocos
5
http://aopmetrics.tigris.org/
29
try). As m´etricas de tamanho selecionadas s˜ao: N´umero de Linhas de C´odigo (LOC
- Lines Of Code), N´umero de blocos try (NOT - Number Of Try blocks), N´umero
de blocos catch (NOC - Number Of Catch blocks), N´umero de blocos finally
(NOF - Number Of Finally blocks), N´umero de linhas de c´odigo que implementam o
tratamento de exce¸c˜oes (LOCEH - Lines Of Code pertaining to Exception Handling)
e n´umero de blocos tratadores de exce¸c˜oes (NEH - Number Exception Handlers).
Essa ´ultima conta o n´umero de blocos que implementam o interesse de tratamento de
exce¸c˜oes e ´e utilizado para quantificar o reuso dos tratadores de exce¸c˜oes nas vers˜oes
refatoradas. Essa m´etrica n˜ao conta a quantidade de blocos que capturam exce¸c˜oes,
ou seja, para as vers˜oes refatoradas OO, ele conta apenas os m´etodos tratadores e
n˜ao os blocos catch.
M´etricas de interesse indicam o quanto o c´odigo ´e direcionado a um interesse [40].
Foram utilizadas essas m´etricas para avaliar o quanto a modulariza¸c˜ao e o reuso de
tratadores de exce¸c˜oes est˜ao relacionados. Al´em disso, algumas dessas m´etricas
contam simplesmente o n´umero de ocorrˆencias de um determinado tipo de elemento
pertencente a um interesse espec´ıfico. Isso n˜ao difere das m´etricas de tamanho, mo-
stradas acima. Nesse estudo foram considerados apenas dois interesses: tratamento
de exce¸c˜oes e o comportamento normal do sistema. As primeiras trˆes m´etricas [37]
s˜ao bastantes conhecidas na comunidade de Desenvolvimento de Software Orientado
a Aspectos: Difus˜ao de Interesses sobre Componentes (CDC - Concern Diffusion
over Components), Difus˜ao de Interesses sobre Opera¸c˜oes (CDO - Concern Diffu-
sion over Operations) e Difus˜ao de interesse sobre Linhas de C´odigo (CDLOC -
Concern Diffusion over LOC ). A justificativa para o uso dessas m´etricas ´e verificar
a difus˜ao do interesse tratamento de exce¸c˜oes, analisando: (i) quantos componentes
(classes e aspectos) e (ii) opera¸c˜oes (m´etodos e advice) implementam o interesse tra-
tamento de exce¸c˜oes; e (iii) quantas transi¸c˜oes existem entre os interesses tratamento
de exce¸c˜oes e comportamento normal.
Adicionalmente, foram utilizadas mais duas m´etricas recentes, que foram pro-
postas a fim de contornar algumas das limita¸c˜oes das m´etricas de interesse citadas
anteriormente. A primeira ´e Perda de Foco (LOF - Lack Of Focus), que ´e uma
adapta¸c˜ao da m´etrica Grau de Foco (DOF - Degree of Focus), proposta por Eaddy
et al. [18]. DOF mede at´e que ponto as linhas de um componente de c´odigo (classe
e aspecto) s˜ao dedicadas `a implementa¸c˜ao de um interesse espec´ıfico. Os valores
variam entre 0 (completamente n˜ao focado) e 1 (completamente focado). O valor
de LOF para cada componente ´e igual a 1 - DOF. A ´ultima m´etrica de interesse,
Grau de Espalhamento (DOS - Degree of Scattering) [18] mede o quanto as linhas
de c´odigo de um determinado interesse est˜ao espalhados pelos componentes do sis-
30
tema. Mais informa¸c˜oes entre DOF e DOS est˜ao dispon´ıveis no trabalho de Eaddy
et al. [18].
3.5 Resultados
O principal objetivo desse estudo ´e verificar se POA promove maior reuso de c´odigo
relativo ao tratamento de exce¸c˜oes do que a abordagem tradicional, orientada a
objetos. O estudo tamb´em tenta, de certa forma, compreender a rela¸c˜ao entre o
reuso de c´odigo de tratadores de exce¸c˜oes e a modulariza¸c˜ao desses. As m´etricas
empregadas tentam apoiar a avalia¸c˜ao das mudan¸cas aplicadas ao c´odigo, tentando
levantar as vantagens e tamb´em desvantagens decorrentes dessas altera¸c˜oes. No
trabalho, foram investigados os impactos da reutiliza¸c˜ao e separa¸c˜ao de interesses,
usando programa¸c˜ao orientada a aspectos para modularizar a captura e o tratamento
das exce¸c˜oes. Al´em disso, uma vers˜ao refatorada orientada a objetos, para cada
aplicativo, foi desenvolvida a fim de garantir a verifica¸c˜ao de um melhor reuso. Essa
vers˜ao refatorada OO (Ver. Ref. OO) foi utilizada para tentar fazer um comparativo
de c´odigo modularizado em POO e POA, pois as vers˜oes originais dos sistemas n˜ao
foram projetadas e desenvolvidas para modularizar e reusar o c´odigo relativo ao
tratamento de exce¸c˜oes.
A Tabela 3.2 apresenta o resultado das m´etricas de tamanho para cada vers˜ao
de cada sistema utilizado no estudo. Na tabela, Ver. Original indica a vers˜ao
original de cada sistema, totalmente escrita na linguagem Java, orientada a objetos.
Ver. Ref. OO indica a vers˜ao que foi refatorada, com o tratamento de exce¸c˜oes
modularizado utilizando classes Java. Por ´ultimo, Ver. Ref. AO indica a vers˜ao
refatorada, mas com o tratamento de exce¸c˜oes dentro dos aspectos em AspectJ.
A coluna Valor mostra o valor obtido em cada m´etrica, para cada vers˜ao de cada
sistema, e (%Incr) ´e o incremento do valor da m´etrica, comparado com a Vers˜ao Ori-
ginal. Como mencionado na Se¸c˜ao 3.4, para todos os valores das m´etricas, menores
valores implicam melhores resultados em rela¸c˜ao ao c´odigo original.
Como mostrado na Tabela 3.2, o n´umero de blocos try (NOT), n´umero de blocos
catch (NOC) e n´umero de blocos finally (NOF) n˜ao apresentaram varia¸c˜oes entre
as vers˜oes Original e Ref. OO. Entretanto, esses valores diminu´ıram sensivelmente,
em cada sistema utilizado, comparando as vers˜oes Original com Ref. AO, com os
valores podendo chegar a mais de 40%. Isso indica que as quantidades de blocos try,
catch e finally ca´ıram com o reuso obtido nessa vers˜ao, assim como apresentado
no estudo anterior de Lippert e Loppes [30].
´
E importante ressaltar, por´em, que em
nenhum caso, a quantidade de reuso chegou a um patamar pr´oximo ao obtido desse
31
estudo anterior (em alguns casos, mais de 80%).
O n´umero de LOC cresceu em todas as vers˜oes refatoradas das aplica¸c˜oes. Mesmo
que o aumento percentual parecendo pequeno (entre 0,51% e 3,38%), ele ´e consi-
der´avel na pr´atica, j´a que apenas trechos de c´odigo relativos a tratamento de exce¸c˜oes
foram criados ou modificados. Na mesma linha de LOC, a m´etrica LOCEH aumen-
tou tamb´em para todas as vers˜oes refatoradas. Esse incremento, em LOC e LOCEH,
ocorreu porque: (a) as vers˜oes Ver. Ref. OO tem mais c´odigo fonte para chamar os
novos m´etodos, as novas classes, novas declara¸c˜oes de m´etodos; (b) nas vers˜oes Ver.
Ref. AO foi necess´ario criar novos aspectos, advice e pointcuts, al´em de ter sido
necess´ario usar a diretiva declare soft para suprimir as checagens de tipo reali-
zadas pelo compilador de Java, para tratamento de exce¸c˜oes. Esse resultado leva `a
conclus˜ao de que, diferentemente do que foi suposto por estudos anteriores [30][6],
redu¸c˜ao na quantidade de linhas de c´odigo n˜ao tem correla¸c˜ao com aumento no
reuso de tratadores de exce¸c˜oes.
A m´etrica do n´umero de tratadores de exce¸c˜oes (NEH) diminuiu em ambas
vers˜oes refatoradas. O motivo para o decremento nos valores dessa m´etrica ´e que
existe a separa¸c˜ao entre a captura e o tratamento da exce¸c˜ao. Como os tratadores
na Ver. Ref. OO s˜ao m´etodos cujos parˆametros s˜ao exce¸c˜oes para serem trata-
das, em muitos casos esses m´etodos podem ter como argumentos exce¸c˜oes de tipos
mais gen´ericos do que os tipos de exce¸c˜oes levantados e tratados, criando assim
bastante oportunidade de reuso. Isso ´e poss´ıvel porque as exce¸c˜oes s˜ao capturadas
pelos blocos catch ainda em termos de tipos espec´ıficos, evitando a subsun¸c˜ao das
exce¸c˜oes [34]. Na Ver. Ref. AO, tanto a captura quanto o tratamento da exce¸c˜ao s˜ao
implementados dentro dos advice. Em geral, os advice capturam exce¸c˜oes usando
tipos espec´ıficos, assim como na implementa¸c˜ao Java Original, a fim de n˜ao cap-
turar involuntariamente exce¸c˜oes n˜ao desejadas. Se, na Ver. Ref. AO, os blocos
try-catch dentro dos advice tratadores fossem respons´aveis exclusivamente pela
captura das exce¸c˜oes e novos m´etodos, dentro dos aspectos, tivessem a responsabi-
lidade de trat´a-las, seria poss´ıvel conseguir um reuso ainda maior, como os valores
pr´oximos ou superiores aos obtidos para as Vers˜oes Ref. OO. Mas essa abordagem
n˜ao foi levada em considera¸c˜ao no trabalho realizado. A Tabela 3.3 mostra os resul-
tados relativos `as m´etricas de interesse. As m´etricas CDC, CDO e CDLOC indicam
como o interesse tratamento de exce¸c˜oes est´a espalhado e misturado atrav´es das
aplica¸c˜oes. As Vers˜oes Ref. AO obtiveram os melhores resultados. Esses resultados
refor¸cam os estudos anteriores e exaltam a capacidade da POA de promover a se-
para¸c˜ao textual de interesses transversais, como tratamento de exce¸c˜oes. Os valores
de CDLOC para as vers˜oes Ref. AO dos sistemas utilizados ca´ıram em mais de 50%.
32
Os valores de CDO indicam que menos opera¸c˜oes no sistema implementam o inter-
esse tratamento de exce¸c˜oes (menos espalhado). Os valores obtidos para CDLOC
indicam o quanto o c´odigo de tratamento de exce¸c˜oes est´a entrela¸cado com c´odigo
relativo ao comportamento normal do sistema. Na Vers˜ao Ref. OO n˜ao houve mu-
dan¸ca. Como os comandos try-catch-finally permanecem do mesmo jeito, as
transi¸c˜oes entre os interesses n˜ao s˜ao modificadas. Diferentemente, na Vers˜ao AO,
onde houve a remo¸c˜ao desses comandos, transi¸c˜oes entre c´odigo relativo ao inter-
esse tratamento de exce¸c˜oes e c´odigo relativo ao comportamento normal do sistema
deixaram de existir. Ent˜ao, a consequˆencia das refatora¸c˜oes foi CDO diminuindo um
pouco, pois o tratamento foi apenas transferido para outros locais, enquanto CD-
LOC e CDC diminu´ıram bem mais, pois a modulariza¸c˜ao em menos componentes
fez diminu´ırem drasticamente as transi¸c˜oes e o n´umero de componentes afetados por
esse interesse.
A m´etrica LOF (falta de foco) ´e normalizada e na Tabela 3.3 apresentada em dois
modos diferentes. O primeiro modo apresenta uma m´edia da m´etrica LOF para todos
os componentes de cada sistema utilizado. A Tabela 3.3 tamb´em indica o n´umero de
componentes que possuem o valor de LOF igual a 0 (LOF=0). Essa m´etrica indica
o n´umero de componentes totalmente focados em somente um interesse, tratamento
de exce¸c˜oes ou comportamento normal do programa. Como n´umero de elementos
que tem LOF=0 ´e muito grande, n˜ao seria representativo usar a mediana, pois todos
os casos teriam o mesmo valor, oq eu n˜ao diferenciaria as vers˜oes analisadas. Ao
comparar o LOF=0, para cada vers˜ao de cada sistema utilizado, torna-se poss´ıvel
analisar se o resultado de LOF ´e uma tendˆencia no sistema inteiro ou decorre apenas
de casos isolados. A m´etrica LOF=0 ´e a ´unica para a qual um valor maior implica
em um resultado melhor.
Nas vers˜oes Ref. AO, tanto a m´edia de LOF quanto o n´umero de componentes
com LOF igual a 0 foram os melhores entre todas as vers˜oes. Isso significa que as
vers˜oes Ref. AO apresentam componentes mais focados no tratamento de exce¸c˜oes
ou no comportamento normal do programa. J´a para as vers˜oes Ref. OO, os valores
foram ligeiramente melhores que para as vers˜oes originais dos aplicativos. Esses
resultados devem ser analisados com cuidado. Como CDLOC n˜ao se alterou nas
vers˜oes Ref. OO, ´e poss´ıvel deduzir que os componentes do sistema que est˜ao pre-
sentes tanto nas vers˜oes Original quanto Ref. OO n˜ao tornaram-se substancialmente
mais focados, j´a que ainda incluem comandos try-catch-finally, embora estes
ocupem menos linhas. Entretanto, as vers˜oes Ref. OO incluem classes que s˜ao to-
talmente focadas e dedicadas exclusivamente ao tratamento de exce¸c˜oes.
´
E poss´ıvel
dizer que esse resultado ´e uma consequˆencia da modulariza¸c˜ao e reuso dos tratadores
33
de exce¸c˜oes.
A ´ultima m´etrica coletada e apresentada na Tabela 3.3 ´e a DOS (grau de espal-
hamento). Similarmente a LOF (e DOF), o valor dessa m´etrica ´e normalizado entre
0 e 1. O valor 0 para essa m´etrica significa que o interesse ´e inteiramente contido
em uma unidade do programa. O valor 1 significa que a implementa¸c˜ao do interesse
est´a espalhado por todos os componentes do sistema. Os resultados obtidos nessa
m´etrica indicam que a Ver. Ref. AO apresentou os melhores resultados, embora com
uma diferen¸ca pequena, com rela¸c˜ao `as outras vers˜oes. Isso porque o tratamento de
exce¸c˜oes ainda permanecem espalhados por alguns locais no c´odigo, mesmo tendo
diminuido os locais de existˆencia do c´odigo. Isso ´e compreens´ıvel, pois as vers˜oes Ver.
Ref. AO concentram a maioria do c´odigo relativo ao tratamento de exce¸c˜oes dentro
dos aspectos, assim reduzindo o n´umero de unidades do programa respons´aveis pela
implementa¸c˜ao de alguma parte de c´odigo desse interesse. Mas o tratamento de
exce¸c˜oes ainda existe em v´arios aspectos do sistema, o que embora tenha diminu´ıdo
o n´umero de componentes contendo o c´odigo desse interesse, ainda est´a espalhado.
A Ver. Ref. OO teve resultados pouco piores do que a vers˜ao Original, pois parte
do tratamento de erros, a captura, ainda continua espalhada um por grande n´umero
de componentes. Finalizando, para todas as vers˜oes de todos os sistemas utilizados,
os valores de DOS foram muitos elevados para o interesse tratametno de exce¸c˜oes,
mostrando que mesmo diminuindo em rela¸c˜ao a vers˜ao original, o c´odigo relativo ao
tratamento de exce¸c˜oes continua espalhado por v´arios locais do sistema.
O percentual de incremento para cada m´etrica ´e apresentado nas Figuras 3.11
e 3.12. As m´etricas de tamanho s˜ao retratadas na Figura 3.11 enquanto os incre-
mentos relativos `as m´etricas de interesse s˜ao apresentadas na Figura 3.12. Olhando
para esses valores, pode-se observar que ouve consistˆencia da abordagem de modu-
lariza¸c˜ao de tratamento de exce¸c˜oes, para cada aplica¸c˜ao, em uma mesma m´etrica
considerada. Por exemplo, todas as vers˜oes Ref. AO exibiram um n´umero menor
de blocos try e uma maior quantidade de linhas de c´odigo relativo ao tratamento
de exce¸c˜oes. Isso sugere que os resultados obtidos possam ser aplicados a outras
aplica¸c˜oes com caracter´ısticas similares.
Uma an´alise cuidadosa dos dados pode revelar alguns pontos interessantes. O
primeiro ponto ´e a existˆencia de uma rela¸c˜ao entre o incremento de LOC e reuso
quando POA ´e empregada. JHotDraw, o sistema onde a menor quantidade de reuso
foi obtida obteve um valor alto de LOCEH. Isso indica que o reuso de tratadores
de exce¸c˜ao de fato influenciam o n´umero final de LOC. No entanto, o overhead da
utiliza¸c˜ao de POA, em termos de LOC, ´e consider´avel. Para todos os sistemas, LO-
CEH cresceu pelo menos 25%. Mais importante ainda, esse overhead ´e, para todas
34
Figura 3.11: Incrementos nas M´etricas de Tamanho.
Figura 3.12: Incrementos nas M´etricas de Interesses.
as situa¸c˜oes que foram analisadas at´e agora, muito maior do que a economia em LOC
proporcionada por POA. Essas observa¸c˜oes levantaram outro ponto importante.
Esse estudo evidenciou que, quando aplicada `a modulariza¸c˜ao do interesse tra-
tamento de exce¸c˜oes, POA promove o reuso. No entanto, n˜ao est´a claro se isso
resulta em c´odigo mais f´acil de manter e mais compreens´ıvel. Indiscutivelmente, os
desenvolvedores ao tentar compreender um sistema onde o tratamento de exce¸c˜oes ´e
modularizado com aspectos, precisam compreender um maior n´umero de m´etodos,
maior n´umero de componentes e um maior n´umero de LOC. Al´em disso, a utiliza¸c˜ao
de aspecto de tratadores de exce¸c˜oes influencia o fluxo de controle dos programas
de maneira sutis que n˜ao s˜ao evidenciadas no c´odigo [3, 11].
35
3.6 Conclus˜oes sobre Reuso Intra-Aplica¸c˜ao
Este cap´ıtulo apresentou um estudo com o objetivo de verificar o potencial de abor-
dagens de modulariza¸c˜ao para promover o reuso intra-aplica¸c˜ao para o c´odigo re-
lativo ao tratamento de exce¸c˜oes. Mais especificamente, foram comparadas duas
implementa¸c˜oes, uma orientada a aspectos e outra orientada a objetos para trˆes
aplica¸c˜oes diferentes e empregado um conjunto de m´etricas espec´ıficas para o in-
teresse de tratamento de exce¸c˜oes. Os resultados do estudo mostraram que POA
promove reuso de c´odigo relativo ao tratamento de exce¸c˜oes e tamb´em melhora a
estrutura do c´odigo. Apesar de certa quantidade de modulariza¸c˜ao e reuso poderem
ser obtidos atrav´es do emprego de POO puramente, o estudo evidencia que o uso
de POA permite uma maior reuso e modulariza¸c˜ao: melhor separa¸c˜ao textual dos
interesses, menos dispers˜ao desses interesses e uma menor quantidade de blocos de
c´odigo relativo ao tratamento de exce¸c˜oes. Ao mesmo tempo, para os trˆes sistemas,
houve aumento no n´umero de linhas de c´odigo relacionado ao interesse tratamento
de exce¸c˜oes nas vers˜oes orientadas a aspectos do que nas vers˜oes orientadas a ob-
jetos. Esses resultados contradizem dois estudos anteriores [6] [30] que avaliam a
adequa¸c˜ao do uso de POA para modularizar o tratamento de exce¸c˜oes.
´
E importante deixar claro que o reuso de tratadores de exce¸c˜oes, abordado nesse
cap´ıtulo foi exclusivamente no interior de cada uma das aplica¸c˜oes. No Cap´ıtulo 4
´e abordado o reuso entre aplica¸c˜oes diferentes, inter-aplica¸c˜oes.
36
Grupo M´etrica Descri¸c˜ao
LOC Lines of Common Code: Linhas de c´odigo do sistema,
excluindo-se coment´arios e linhas em branco.
NOT Number of Try blocks: N´umero de blocos try.
M´etricas NOC Number of Catch blocks: N´umero de blocos catch.
de NOF Number of Finally blocks: N´umero de blocos finally.
Tamanho LOCEH Lines of Exception Handling Code: Linhas de c´odigo
relativo ao tratamento de exce¸c˜oes.
NEH Number of Exception Handlers: N´umero de blocos de c´odigo
relativos ao tratamento de exce¸c˜oes.
CDC Concern Diffusion over Component [37]: Conta o n´umero de
componentes(classes, aspectos, interfaces) que incluem c´odigo
de tratamento de exce¸c˜oes.
CDO Concern Diffusion over Operation [37]: Conta o n´umero de
opera¸c˜oes(m´etodos e advice) que incluem c´odigo de
tratamento de exce¸c˜oes.
CDLOC Concern Diffusion over Lines of Code [37]: Conta o n´umero de
M´etricas pontos de transi¸c˜ao para cada interesse atrav´es das linhas
de de c´odigo. O uso dessa m´etrica exige um processo
Interesse de sombreamento dentro do c´odigo, com ´areas sombreadas
e ´areas n˜ao-sombreadas.
LOF Lack of Focus: Essa ´e uma medida da ausˆencia de foco de cada
componente, para todos os interesses. O resultado ´e
normalizado entre 0 (completamente focado) e 1
(completamente sem foco). O resultado dessa m´etrica ´e obtido
a partir do valor da m´etrica DOF (Degree of Focus) [18].
LOF = 1 - DOF.
DOS Degree of scattering [18]: Essa m´etrica mede a varia¸c˜ao de
concentra¸c˜ao de um interesse por todos os componentes. O
resultado ´e normalizado entre 0 (completamento localizado)
e 1(completamente distribu´ıdo).
Tabela 3.1: Conjunto de M´etricas utilizadas
37
Sistema M´etrica Ver. Original Ver. Ref. OO Ver. Ref. AO
Valor Valor (%Incr) Valor (%Incr)
LOC 22820 22937 (0,51%) 23089 (1,18%)
NOT 64 64 (0%) 47 (-26,56%)
JHotDraw NOC 71 71 (0%) 56 (-21,13%)
NOF 4 4 (0%) 4 (0%)
LOCEH 293 375 (27,99%) 595 (103,07%)
NEH 65 34 (-47,69%) 47 (-27,69%)
LOC 19197 19475 (1,45%) 19845 (3,38%)
NOT 230 229 (-0,43%) 131 (-43,04%)
Checkstyle NOC 271 270 (-0,37%) 142 (-47,60%)
NOF 27 27 (0%) 22 (-18,52%)
LOCEH 1211 1379 (13,87%) 1700 (40,38%)
NEH 282 104 (-63,12%) 154 (-45,39%)
LOC 17177 17798 (3,62%) 17401 (1,30%)
NOT 294 294 (0%) 165 (-43,88%)
PetStore NOC 418 418 (0%) 218 (-47,85%)
NOF 13 13 (0%) 7 (-46,15%)
LOCEH 1709 2214 (29,55%) 2281 (33,47%)
NEH 397 205 (-48,36%) 210 (-47,10%)
Tabela 3.2: Resultado das M´etricas de Tamanho
38
Sistema M´etrica Ver. Original Ver. Ref. OO Ver. Ref. AO
Valor Valor (%Incr) Valor (%Incr)
CDO 62 81 (30,65%) 47 (-24,19%)
CDLOC 262 262 (0%) 20 (-92,37%)
JHotDraw CDC 40 49 (22,50%) 12 (-70,00%)
M´edia LOF 0,0333 0,0323 (-2,92%) 0,0025 (-92,43%)
LOF=0 90,10% 90,31% (0,24%) 99,52% (10,46%)
DOS 0,9601 0,9712 (1,16%) 0,8765 (-8,71%)
CDO 200 253 (26,50%) 127 (-36,50%)
CDLOC 870 870 (0%) 92 (-89,43%)
Checkstyle CDC 109 120 (10,09%) 27 (-75,23%)
M´edia LOF 0,1486 0,1353 (-8,91%) 0,0138 (-90,69%)
LOF=0 62,28% 64,36% (3,33%) 97,44% (56,44%)
DOS 0,9855 0,9863 (0,08%) 0,8983 (-8,85%)
CDO 237 365 (54,01%) 157 (-33,76%)
CDLOC 1012 1008 (-0,40%) 68 (-93,28%)
PetStore CDC 109 148 (35,78%) 51 (-53,21%)
M´edia LOF 0,1721 0,1461 (-15,13%) 0,0162 (-90,61%)
LOF=0 67,27% 70,97% (5,50%) 95,64% (42,18%)
DOS 0.9836 0.9886 (0.50%) 0.9578 (-2.62%)
Tabela 3.3: Resultado das M´etricas de Interesse
39
Cap´ıtulo 4
Reuso Inter-Applica¸c˜ao
Ap´os a verifica¸c˜ao do reuso de c´odigo tratadores de exce¸c˜oes para uma mesma
aplica¸c˜ao no Cap´ıtulo 3 (reuso Intra-Aplica¸c˜ao), neste cap´ıtulo um outro estudo
foca na verifica¸c˜ao de reuso de c´odigo entre aplica¸c˜oes diferentes, o reuso Inter-
Aplica¸c˜ao. Para essa avalia¸c˜ao foram utilizados sete sistemas bastante difundidos
na comunidade, com tamanho m´edio, alguns com funcionalidades semelhantes e
plataforma semelhantes.
Nas pr´oximas se¸c˜oes ser´a descrito como foi feito esse estudo. A seguir ´e apre-
sentado a metodologia do estudo (Se¸c˜ao 4.1) e os Sistemas Utilizados (Se¸c˜ao 4.2), a
Extra¸c˜ao e Reuso dos Tratadores de Exce¸c˜oes (Se¸c˜ao 4.3), a Metodologia de Busca
Aplicada (Se¸c˜ao 4.4) no reuso, os Resultados (Se¸c˜ao 4.5) do estudo, os Problemas
Relacionados (Se¸c˜ao 4.6) e as Conclus˜oes (Se¸c˜ao 4.7).
4.1 Metodologia
Esse trabalho ´e uma extens˜ao do trabalho apresentado no cap´ıtulo 3, agora focando
no reuso Inter-aplica¸c˜ao. A abordagem adotada nesse estudo ´e utiliza¸c˜ao de aspectos
com implementa¸c˜ao de c´odigo relativo ao tratamento de exce¸c˜oes a fim de avaliar
se esse c´odigo pode ser reusado em aplica¸c˜oes diferentes. Diferentemente do estudo
de reuso intra-aplica¸c˜ao, esse estudo utilizou somente duas alternativas de modula-
riza¸c˜ao: i) uma abordagem ’regular’, com o c´odigo original de cada aplica¸c˜ao, tendo
o c´odigo relativo ao tratamento de exce¸c˜oes junto com o c´odigo de comportamento
normal do sistema; e ii) uma segunda abordagem com os tratadores de exce¸c˜oes
dentro de aspectos, na linguagem AspectJ.
Trˆes dos sete sistemas foram reutilizados do estudo de reuso intra-aplica¸c˜ao, utili-
zando as extra¸c˜oes de tratadores e verifica¸c˜ao de reuso do estudo. Os outros quatros
restantes foram extra´ıdos e verificada a oportunidade de reuso por membros advindo
40
do estudo anterior, utilizando os procedimentos aplicados no primeiro estudo e sendo
feitas revis˜oes das extra¸c˜oes e reuso encontrado. Ap´os todas as aplica¸c˜oes terem os
tratadores de exce¸c˜oes dentro de aspectos e tendo o aplicado o reuso internamente
em cada uma, foi verificado o reuso entre todas aplica¸c˜oes, utilizando metodologias
de busca a serem explicadas na Se¸c˜ao 4.4.
A principal diferen¸ca entre os dois estudos ´e o foco onde o reuso ´e aplicado.
Embora esse novo estudo utilize todas as aplica¸c˜oes com os tratadores de exce¸c˜oes
reusados internamente, o objetivo ´e analisar o reuso entre todas elas. Outra dife-
ren¸ca ´e que apenas vamos utilizar aspectos para verificar a reusabilidade, diferente-
mente do estudo anterior que tamb´em utilizou uma com os tratadores de exce¸c˜oes
dentro de classes Java. As aplica¸c˜oes que foram utilizadas possuem possuem dis-
tintos atributos relativos a plataformas de desenvolvimento, finalidade e tamanho.
Algumas possuem atributos semelhantes e outras n˜ao. A partir desse estudo pode-
mos verificar se ´e poss´ıvel reusar ou n˜ao c´odigo relativo ao tratamento de exce¸c˜oes
em aplica¸c˜oes diferentes, quando esse c´odigo estiver dentro de aspectos e para os
sistemas escolhidos para esse estudo.
4.2 Sistemas Utilizados
Para este estudo foram utilizadas sete aplica¸c˜oes escritas em Java. Essas aplica¸c˜oes
s˜ao representativas por serem aplica¸c˜ao reais, de tamanho m´edio na ind´ustria e
possu´ırem algumas outras caracter´ısticas relevantes. A primeira ´e referente ao ta-
manho dos sistemas. A grande maioria possui pelo menos 10K LOC, pelo menos
1% do c´odigo referente ao tratamento de exce¸c˜oes e no m´ınimo 80 componentes
(classes e interfaces). Esses valores variam bastante de uma aplica¸c˜ao para outra,
com algumas dessas aplica¸c˜oes possuindo valores bem maiores, como mais de 23K
LOC ou aproximadamente 10% do c´odigo dedicado ao tratamento de exce¸c˜oes. A se-
gunda caracter´ıstica ´e referente `a heterogeneidade das aplica¸c˜oes:as sete aplica¸c˜oes
analisadas vˆem de seis dom´ınios diferentes, baseiam-se em diferentes plataformas
de desenvolvimento e foram desenvolvidas por diferentes organiza¸c˜oes. Ao mesmo
tempo, uma premissa deste trabalho ´e que ´e mais prov´avel que seja poss´ıvel reutili-
zar tratadores de exce¸c˜oes se os sistemas estudados tiverem algumas caracter´ısticas
em comum. Tendo isso em vista, quatro dos sistemas alvo deste estudo s˜ao plugins
para o Eclipse
1
e dois s˜ao aplica¸c˜oes Java para desktops, baseadas na plataforma
Java Standard Edition (Java SE). Al´em disso, dois dos sistemas alvo podem ser en-
quadrados em um mesmo dom´ınio: o das ferramentas de coleta de m´etricas est´aticas
1
http://www.eclipse.org/
41
de c´odigo. As aplica¸c˜oes selecionadas para este estudo s˜ao as seguintes:
• Checkstyle
2
. Ferramenta para checagem de estilo de programa¸c˜ao para pro-
gramas escritos na linguagem Java.
• TeXlipse
3
. Editor de LaTex para Eclipse.
• EIMP
4
. Ferramenta de mensagens instantˆaneas para GTalk, MSN e outros
protocolos de comunica¸c˜ao.
• JHotDraw
5
. Framework de GUI de Java, para desenhos t´ecnicos e estrutu-
rados.
• Java Pet Store
6
. Demo da plataforma Java Enterprise Edition para a
constru¸c˜ao de aplica¸c˜oes corporativas.
• AOPMetrics
7
. Ferramenta de coleta de m´etricas est´aticas de c´odigo Java e
AspectJ.
• Metrics
8
. Ferramenta de coleta de m´etricas est´aticas de c´odigo Java.
A Tabela 4.1 apresenta todas as sete aplica¸c˜oes, os tamanhos de cada em termos
de LOC total, LOC referentes ao tratamento de exce¸c˜oes, n´umero de componentes
(classes e interfaces), a plataforma de desenvolvimento e uma breve descri¸c˜ao das
funcionalidades. Esses valores foram obtidos para as vers˜oes originais, totalmente
implementadas em Java. Para cada uma dessas aplica¸c˜oes, uma nova vers˜ao foi
desenvolvida, com o tratamento de exce¸c˜oes extra´ıdo para aspectos implementados
em AspectJ.
4.3 Extra¸c˜ao e Reuso dos Tratadores de Exce¸c˜oes
Para chegar nas vers˜oes com todo o tratamento de exce¸c˜oes dentro dos aspectos, foi
necess´ario fazer refatora¸c˜oes para que todos os sistemas utilizados no estudo tenham
os tratadores de exce¸c˜oes dentro de aspectos e n˜ao mais em classes Java. Como no
estudo descrito no cap´ıtulo 3, para obter a vers˜ao refatorada a partir da original,
2
http://eclipse-cs.sourceforge.net/
3
http://texlipse.sourceforge.net
4
http://eimp.sourceforge.net
5
http://www.jhotdraw.org/
6
http://java.sun.com/developer/releases/petstore/
7
http://aopmetrics.tigris.org/
8
http://metrics.sourceforge.net/
42
Aplica¸c˜oes LOC Total LOC EH Num. Comp. Plat. Desenv.
Checkstyle 19.2K 1211 290 Eclipse Plugin
TeXclipse 31.7K 906 489 Eclipse Plugin
EIMP 9K 440 218 Eclipse Plugin
JHotDraw 23K 293 400 Java SE
Java Pet Store 17.5K 1709 330 Java EE
AOPMetrics 3K 61 80 Java SE
Metrics 16K 733 292 Eclipse Plugin
Tabela 4.1: Aplica¸c˜oes Usadas para reuso Inter-Aplica¸c˜oes.
foi levado em considera¸c˜ao somente o conte´udo dos blocos catch e finally. Parte
das refatora¸c˜oes foi feita em pares. Os resultados dessa atividade foram revisados
por outros pares, sistematicamente. Para alguns dos sistemas alvo do estudo, a
refatora¸c˜ao do tratamento de exce¸c˜oes para aspectos foi realizada por apenas um
componente da equipe, com experiˆencia na extra¸c˜ao de tratadores de exce¸c˜oes para
aspectos (Cap´ıtulo 3), e revisada por outro componente da equipe.
Diferentemente do estudo anterior, apresentado no Cap´ıtulo 3, esse estudo focou
em avaliar se ´e poss´ıvel reutilizar o c´odigo relativo ao tratamento de exce¸c˜oes apenas
entre aplica¸c˜oes distintas. A linguagem AspectJ foi usada como uma ferramenta
para atingir este fim. Outra op¸c˜ao seria mover os tratadores para m´etodos escritos
em Java mas, como descrito no cap´ıtulo anterior, essa solu¸c˜ao ´e inferior ao uso de
POA. A extra¸c˜ao dos tratadores de exce¸c˜ao, como tamb´em o reuso interno a cada
aplica¸c˜ao foi realizado da mesma forma do estudo anterior (Cap´ıtulo 3) e ´e descrito
na se¸c˜ao 3.3.
Ap´os a avaliar se o reuso ´e poss´ıvel dentro de cada aplica¸c˜ao alvo do estudo, foi
feita a verifica¸c˜ao da possibilidade de reusar os tratadores entre diferentes aplica¸c˜oes.
O primeiro passo, para reuso inter-aplica¸c˜oes foi a generaliza¸c˜ao dos aspectos de tra-
tamento de exce¸c˜oes pr´e-existentes para que possam ser usados em v´arias aplica¸c˜oes
ao mesmo tempo. Essa generaliza¸c˜ao foi necess´aria para que o c´odigo a ser reusado
n˜ao tivesse nenhum conhecimento de cada aplica¸c˜ao, atrav´es de aspectos abstratos
e interface. Mais informa¸c˜oes sobre a generaliza¸c˜ao ´e apresentada na Se¸c˜ao 4.5.
Usando uma metodologia de busca, descrita na Se¸c˜ao 4.4, foi realizada uma busca
por tratadores de exce¸c˜oes reus´aveis nas diferentes aplica¸c˜oes. Quando descoberta
a possibilidade de reuso, foi criado no c´odigo que ser´a reusado, um aspecto abstrato
com um pointcut abstrato e o c´odigo tratador da exce¸c˜oes concreto (e reutilizado)
dentro do advice. O pr´oximo passo foi, para cada aplica¸c˜ao onde existe tratador
de exce¸c˜ao que possa ser reusado entre aplica¸c˜oes, a cria¸c˜ao de um novo aspecto,
estendendo o aspecto abstrato e implementando somente o pointcut que definir´a a
43
1 public p ri vileged aspect F igur esEx c ept i onHa ndle r {
2 ...
3 declare soft : C lone NotS u ppo r ted E xce p tion : F i gur e Att r ibut es_c lone Hand ler () ;
4 poin t c ut F igur eAtt ribu t es_ c lon e Han d ler () :
5 ex e c ution ( Object Fi g ureA t tribu tes . clone (..) ) ;
6
7 Object around () throws Inte rnalEr r or : F igur eAtt ribu tes_ clon eHan dler () {
8 try {
9 return proceed () ;
10 }
11 catch ( C l one N otS u ppor tedE xcep t ion e ) {
12 th row new Int e rnalE r ror () ;
13 }
14 }
15 ...
16 }
Figura 4.1: C´odigo Original do Reuso Inter-Aplica¸c˜ao.
quais pontos de jun¸c˜ao os tratadores ser˜ao associados.
Os trechos de c´odigo apresentados nas figuras 4.1, 4.2 e 4.3 apresentam um
exemplo de c´odigo reusado. O trecho de c´odigo da Figura 4.1 apresenta um caso
inicial onde um aspecto ´e respons´avel por implementar o tratamento da exce¸c˜ao
CloneNotSupportedException para somente uma aplica¸c˜ao. Se esse tratamento
estiver duplicado em v´arias aplica¸c˜oes, esse aspecto precisar´a ser generalizado para
tornar poss´ıvel o reuso. J´a o trecho de c´odigo da Figura 4.2 apresenta o aspecto
reus´avel para o tratamento da exce¸c˜ao CloneNotSupportedException. Esse as-
pecto define o pointcut abstrato cloneNonSuportedGeneral(), usado por aspectos
concretos em diferentes aplica¸c˜oes para indicar pontos onde o tratador ser´a reusado.
E por fim, no trecho de c´odigo na Figura 4.3 ´e apresentado o aspecto que estende o
aspecto abstrato. Uma coisa que pode ser observada nesse exemplo e que ´e eviden-
ciada pelo trecho na Figura 4.2 ´e que a diretiva declare soft e o advice tratador
da exce¸c˜ao podem ser reusados sem qualquer modifica¸c˜ao.
4.4 Metodologia de Busca Utilizada
Esta se¸c˜ao descreve a metodologia utilizada para procurar por oportunidades de
reuso de c´odigo tratador de exce¸c˜oes, para cada aplica¸c˜ao. Inicialmente, uma
44
1 public a b s tract aspect Cl o neE rror Abst rac t Exc e pti o nHa ndli ng {
2 decla r e soft : Cl o neN o tSu p port edEx cept i on : cl o neNo nSup o rte d Gene ral () ;
3 // A s sin a tur a de p oint cuts ab stra t os
4 abs t r ac t pointc u t c l one N onSu port e dGe n eral () ;
5 // I mpl e men tan d o c ´odi g o do A dvice
6 Object arou n d () throws Int e rnalE r ror : c lone NonS upor t edGe nera l () {
7 try {
8 return procee d ();
9 }
10 catch ( C l one N otS u ppor tedE xcep t ion e ) {
11 thro w new In t ernalE rror () ;
12 }
13 }
14 }
Figura 4.2: Aspecto Abstrato no c´odigo reus´avel
1 public p ri vileged aspect C lon eErr orI m ple m ent ati o nEx c ept ionH and l ing extends
2 Cl o neE r ror A bst ract Exce pti o nHa n dli n g {
3 poin t c ut c l one N onSu port e dGe n eral () :
4 execu t i on ( Object F igure Attri butes . clone (..) );
5 }
Figura 4.3: Aspecto Concreto que estande do Aspecto Abstrato
aplica¸c˜ao de detec¸c˜ao de clones de c´odigo, o CCFinder
9
, ia ser utilizada para fa-
cilitar essa busca. O principal entrave foi da ferramenta n˜ao dar suporte a c´odigo
AspectJ, somente Java, onde foi realizada uma verifica¸c˜ao e o resultado na adicionou
nada relevante ao estudo. A limita¸c˜ao de n˜ao suportar AspectJ tornaria imposs´ıvel
procurar por tratadores duplicados extra´ıdos para aspectos, o que por sua vez exi-
giria que nem o reuso intra-aplica¸c˜ao fosse levado em considera¸c˜ao na busca.
4.4.1 Procurando Oportunidades de Reuso
A busca por oportunidades de reuso foi realizada manualmente, atrav´es de inspe¸c˜ao
manual do c´odigo das aplica¸c˜oes. Para essa busca foram utilizadas dois m´etodos: a)
verifica¸c˜ao direta se existiam casos de tipos de exce¸c˜oes e tratadores semelhantes e
b) verifica¸c˜ao agrupando por casos classificados no trabalho de Cabral e Marques [2].
A busca por reuso come¸cou com o cruzamento dos casos existentes nos aspectos
gerais da aplica¸c˜ao, que est˜ao contidos GeneralExceptionHandler, aspecto descrito
na Se¸c˜ao 3.3. Assim, a busca por tratadores reutiliz´aveis foi iniciada justamente nos
elementos mais reusados em cada sistema. O pr´oximo passo foi procurar por outros
tratadores que seriam poss´ıveis reusar, em cada pacote dos sistemas. Esse tipo de
busca ´e complicado, pois ´e necess´ario ter conhecimento de todos os tipos de exce¸c˜oes
9
http://www.ccfinder.net/
45
1 Object around () : Fi l eMa t chP a tte r n_c l one H and l er () ||
2 F ile M atc h Pat t ern _clo neF i leS e tHa n dle r () ||
3 F ile M atc h Pat t ern _clo neP r oje c tHa n dle r () ||
4 F ile M atc h Pat tern _cl o neW o rki ngC o pyH a ndl er () ||
5 A bstr actF ilte r _cl o neH a ndl e r () ||
6 cl on eHandl e () {
7 try {
8 return p r o ce e d () ;
9 } catch ( Cl o neNo tSup port edEx c ept i on e ) {
10 throw new In t ernal E rror () ;
11 }
12 }
Figura 4.4: Exemplo da estrat´egia Lan¸camento.
levantadas e todos os tratadores existentes nas aplica¸c˜oes, al´em das implementa¸c˜oes
destes ´ultimos. Al´em disso, a complexidade dessa tarefa cresce de forma exponencial
com o n´umero de aplica¸c˜oes avaliadas, o que a torna n˜ao-escal´avel e imprecisa.
A procura por tratadores de exce¸c˜oes candidatos ao reuso utilizando a classi-
fica¸c˜ao de Cabral e Marques [2] torna-se mais f´acil, pois diminui a necessidade de
conhecer todos os tratadores e de comparar todos eles entre si. Com esta abordagem,
s´o ´e necess´ario comparar tratadores cujas estrat´egias de tratamento de exce¸c˜ao se-
jam similares. O trabalho de Cabral e Marques define categorias de tratadores
de exce¸c˜oes com base em suas estrat´egias de tratamento. Nem todos as catego-
rias de exce¸c˜oes existentes podem ser implementadas em AspectJ, o que diminui
o n´umero de categorias de estrat´egias de tratamento de exce¸c˜oes e, consequente-
mente, o n´umero de candidatos ao reuso. As categorias levadas em conta neste
estudo s˜ao apresentadas na Tabela 4.2. Das categorias descritas no trabalho de
Cabral e Marques [2] a categoria Delegates s´o pode ser implementada em .NET
10
e no estudo n˜ao foram encontrados casos das categorias Assert e Rollback, que s˜ao
descritas no trabalho de Cabral e Marques [2].
Uma estrat´egia bastante utilizada ´e a estrat´egia de lan¸car outra exce¸c˜ao. No
trecho de c´odigo mostrado na Figura 4.4 mostra um exemplo dessa estrat´egia. A
Tabela 4.3 apresenta um mapeamento das exce¸c˜oes capturadas e exce¸c˜oes que s˜ao
novamente levantadas das aplica¸c˜oes listadas na Tabela 4.1.
´
E poss´ıvel notar na
Tabela 4.3 que em poucos casos existe um correspondˆencia entre exce¸c˜ao capturada
e exce¸c˜ao levantada novamente para aplica¸c˜oes distintas, o que minimiza os casos
poss´ıveis de reuso. Os casos onde essa correspondˆencia existe est˜ao marcados na
tabela com “*”.
10
http://www.microsoft.com/NET/
46
Categoria Descri¸c˜ao
Vazio O c´odigo do tratamento ´e vazio e nem faz nada al´em
de limpar a pilha.
Log Algum registro de erro ou notifica¸c˜ao ao usu´ario de situa¸c˜ao
inesperada.
Alternativo/ No caso de algum erro na execu¸c˜ao de um bloco finally
Configura¸c˜ao ou algum outro tipo de configura¸c˜ao (alternativa) de estado
est´atica de um objeto.
Lan¸camento Um novo objeto de exce¸c˜ao ´e criado e lan¸cado ou a
exce¸c˜ao original ´e re-lan¸cada.
Retorno O tratador da exce¸c˜ao for¸ca o m´etodo da execu¸c˜ao a retornar
ou a aplica¸c˜ao finalizar. Se o tratador estiver dentro de
um la¸co e a a¸c˜ao de execu¸c˜ao do la¸co ´e interrompida atrav´es
de um comando break, tratador tamb´em ´e incluso nesta categoria.
Fechar O c´odigo garante que uma conex˜ao aberta ou um fluxo (stream)
de dados ´e fechado. Uma outra a¸c˜ao que se enquadra nessa categoria
´e a libera¸c˜ao do bloqueio de algum recurso.
Outros Outros tipos de a¸c˜oes de tratamento de exce¸c˜oes que n˜ao se
enquadram nos descritos acima.
Tabela 4.2: As estrat´egias de tratamento de exce¸c˜oes propostas por Cabral e
Marques.
47
Aplica¸c˜ao Exce¸c˜ao Capturada Exce¸c˜ao Levantada
Checkstyle NumberFormatException IllegalArgumentException
Plugin CheckstyleException CheckstyleException
CloneNotSupportedException* CoreException
CheckstylePluginException IOException
SAXException
InternalError*
TeXclipse Exception SoftException
Plugin IOException TexDocumentParseException
CoreException BuilderCoreException
BadLocationException CoreException
InterruptedException RuntimeException
OperationCanceledException
EIMP Plugin MalformedURLException RuntimeException
JHotDraw CloneNotSupportedException* InternalError*
ClassNotFoundException JHotDrawRuntimeException
InstantiationException IOException
IllegalAccessException
NoSuchMethodError
Pet Store ServiceLocatorException AdminBDException
CreateException OPCAdminFacadeException
RemoteException EJBException
OPCAdminFacadeException FormatterException
XMLDocumentException GeneralFailureException
FinderException PopulateException
Exception ServletException
GeneralFailureException SAXException
CreateException SoftException
ServiceLocatorException CatalogException
SQLException TransitionException
JMSException RuntimeException
CatalogDAOSysException MailerAppException
NamingException JspTagException
Tabela 4.3: Mapeamento dos casos que levantam uma nova exce¸c˜ao.
48
4.4.2 Empacotamento e Ambiente de Compila¸c˜ao
Empacotamento ´e termo adotado neste trabalho para designar a atividade de tornar
um conjunto de tratadores de exce¸c˜oes pass´ıvel de ser associado a v´arias aplica¸c˜oes
distintas de forma simples. Para empacotar um grupo de tratadores reus´aveis, basta
colocar esses tratadores em um aspecto separado do restante do c´odigo da aplica¸c˜ao,
adotando a abordagem descrita na se¸c˜ao anterior. No momento da compila¸c˜ao
do c´odigo de cada aplica¸c˜ao, ´e colocado tamb´em o caminho contendo o c´odigo a
ser reusado como entrada nos parˆametros de compila¸c˜ao do projeto. O pr´oprio
compilador, no momento da compila¸c˜ao, al´em de compilar todos os arquivos fonte
passados como parˆametro de entrada tamb´em adiciona o c´odigo compilado referente
ao reuso inter-aplica¸c˜ao para dentro da pasta de sa´ıda dos arquivos .class, podendo
tamb´em adicionar ao novo arquivo .jar criado, caso seja op¸c˜ao desejada.
Uma outra solu¸c˜ao poss´ıvel para o empacotamento ´e fazer a compila¸c˜ao do c´odigo
de cada aplica¸c˜ao e do c´odigo a ser reusado separadamente. A primeira tarefa
desse modo de empacotamento ´e compilar o c´odigo a ser reusado separadamente,
sem ainda compilar o c´odigo das aplica¸c˜oes. Como os aspectos e os pointcuts s˜ao
abstratos, em alguns casos, eles n˜ao necessitam de informa¸c˜oes do projeto para a
compila¸c˜ao, sendo as vezes necess´ario apenas definir bibliotecas a serem utiliza-
das. Depois de compilado o c´odigo reusado, ´e necess´ario em cada projeto inserir
os arquivos .class compilados anteriormente, para poder compilar as aplica¸c˜oes que
utilizar˜ao desse c´odigo reus´avel.
Uma parte importante do reuso inter-aplica¸c˜oes ´e o ambiente de compila¸c˜ao
das aplica¸c˜oes. Em alguns casos, pode ser estrat´egia do reuso utilizar c´odigo j´a
compilado anteriormente. Para isso precisam ser observadas as vers˜oes dos com-
piladores empregados para n˜ao utilizar c´odigo reus´avel compilado com uma vers˜ao
superior `a do compilador empregado para compilar o restante da aplica¸c˜ao. Al´em
disso, existem dois compiladores maduros para AspectJ: ajc
11
e abc
12
. O primeiro
compilador, ajc, ´e o mais comum. Ele ´e baseado no compilador Java com suporte
para compila¸c˜ao de AspectJ usando o padr˜ao da linguagem, enquanto o segundo ´e
mais focado para pesquisas.
´
E importante verificar a compatibilidade entre esses
compiladores e suas limita¸c˜oes. O abc ´e um compilador extens´ıvel para novas fun-
cionalidades, mas tem limita¸c˜ao na evolu¸c˜ao da linguagem e diferen¸cas no uso. Al´em
disso, possui funcionalidades adicionais, que n˜ao est˜ao dispon´ıveis no ajc.
11
http://www.eclipse.org/aspectj/doc/next/devguide/ajc-ref.html
12
http://abc.comlab.ox.ac.uk/
49
4.5 Resultados
Para os sete sistemas utilizados neste estudo (Se¸c˜ao 4.2), em apenas trˆes situa¸c˜oes
foi poss´ıvel reutilizar tratadores de exce¸c˜oes. O primeiro ´e o caso mais simples,
uso de tratadores de exce¸c˜oes em branco, onde a ´unica a¸c˜ao realizada, implicita-
mente, ´e a limpeza da pilha. Foi poss´ıvel juntar todos os tratadores de exce¸c˜oes em
branco no c´odigo reusado. O segundo caso foi para duas aplica¸c˜oes que capturam
a exce¸c˜ao do tipo CloneNotSupportedException e relan¸cam uma nova exce¸c˜ao do
tipo InternalError. Para essas duas aplica¸c˜oes, em alguns casos, quando um pro-
grama tenta clonar um objeto e falha, ele trata a exce¸c˜ao lan¸cada no momento da
clonagem levantando uma nova exce¸c˜ao (que sinaliza que a execu¸c˜ao do programa
deve ser interrompida, por ser um Error). Esse exemplo foi apresentado na se¸c˜ao
anterior, na Tabela 4.3.
O terceiro caso, e o mais significativo, foi a possibilidade de reusar o c´odigo que
trata exce¸c˜oes usando a estrat´egia Log (Se¸c˜ao 4.2) para trˆes aplica¸c˜oes. A estrat´egia
de Log, definida por Cabral e Marques [2], pode guardar informa¸c˜oes de erro, mensa-
gem, advertˆencia em arquivos onde o administrador do sistema pode verificar depois,
ou at´e mesmo retornar ao usu´ario algum alerta. Cada aplica¸c˜ao pode ter uma a¸c˜ao
ou finalidade para o Log a sua escolha. Para isso, se fez necess´aria uma pequena
modifica¸c˜ao na estrutura inicial das classes Java desses sistemas. Inicialmente, cada
aplica¸c˜ao possui uma classe que disponibiliza um m´etodo respons´avel por fazer o
logging. Cada uma dessas classes deve implementar uma interface, ILogObject,
que pertence ao c´odigo reus´avel de tratamento de exce¸c˜ao. Essa interface define
a assinatura para um m´etodo log(), que ´e o que o advice que implementa o trata-
mento de exce¸c˜ao no c´odigo reus´avel deve conhecer. Tamb´em no c´odigo reus´avel,
existe o aspecto abstrato LogAbstractHandler. Esse aspecto cont´em o tratamento
de exce¸c˜oes que ser´a reutilizado. No trecho de c´odigo da Figura 4.5 ´e apresentado
esse aspecto. Assim, o m´etodo log() deve chamar o m´etodo que a interface imple-
menta, fazendo o c´odigo reus´avel somente chamar os m´etodos dessa interface sem
necessidade de conhecer o c´odigo.
No aspecto apresentado no trecho de c´odigo da Figura 4.5, existem dois point-
cuts abstratos, como tamb´em dois m´etodos abstratos. Esses pointcuts e m´etodos
devem ser implementados nos aspectos concretos. Os dois pointcut lidam com duas
situa¸c˜oes distintas que podem mais bem entendidas mediante o estudo dos advice
aos quais est˜ao associados (explicados abaixo). Os m´etodos getMessageText() e
getLogObject() servem para pegar o texto da mensagem, indexado pela ordem
do pointcuts , definido no aspecto concreto, e para pegar o objeto que possui o
m´etodo de Log, respectivamente. Os dois advice apresentam o tratamento de erro
50
quando o tratador registra uma mensagem de erro. Esses dois advice implemen-
tam um tratamento semelhante, com uma pequena diferen¸ca quanto `a captura da
exce¸c˜ao. O primeiro trata qualquer exce¸c˜ao, pois captura Exception. Assim, qual-
quer ponto de jun¸c˜ao selecionado por esse pointcuts implementa c´odigo para tratar
qualquer tipo de exce¸c˜ao, pois Exception ´e a super classe para todas as exce¸c˜oes
em Java, ficando abaixo apenas de Throwable que tamb´em engloba os erros, que
idealmente n˜ao devem ser capturados. A segunda s´o captura todas as exce¸c˜oes
checadas, as exce¸c˜oes que herdam de Exception, mas relan¸ca as exce¸c˜oes que her-
dam de RuntimeException. Vale lembrar que cada aplica¸c˜ao deve especificar os
pontos de jun¸c˜ao para esse tratamento. A diferen¸ca dos dois casos ´e que o pri-
meiro tamb´em tratam de exce¸c˜oes que herdam de RuntimeException enquanto o
segundo n˜ao. Uma atributo importante para essa solu¸c˜ao ´e saber qual o pointcut
associado ao ponto de jun¸c˜ao que interceptou o fluxo de execu¸c˜ao. A necessidade de
saber do pointcut ´e para saber qual a mensagem que dever´a ser enviada ao m´etodo
logGeneral(logText, e), nas linhas 14 e 26. Um n´umero identificando o pointcut
´e obtido pelo m´etodo thisEnclosingJoinPointStaticPart.getId().
Do lado do c´odigo de cada sistema que vai utilizar o c´odigo reus´avel, o primeiro
passo, conforme descrito antes, ´e fazer a classe que precisa registrar informa¸c˜oes im-
plementar a interface ILogObject, que ´e definida dentro do c´odigo reus´avel. Dessa
forma, o c´odigo reus´avel s´o precisa conhecer o objeto que far´a o logging , atrav´es da
interface, sem necessidade de saber de particularidades da aplica¸c˜ao. As outras mo-
difica¸c˜oes s˜ao no aspecto concreto, que estende LogAbstractHandler. Esse aspecto
deve implementar os pointcuts e m´etodos supracitados. No segundo caso, deve
especificar qual mensagem dever´a ser registrada para cada ID de pointcuts e qual ´e
o objeto que possui o m´etodo de Log. Assim, foi poss´ıvel reusar esse mesmo tratador
21 vezes na aplica¸c˜ao Checkstyle Plugin, 42 vezes no TeXlipse e 25 na Metrics.
4.5.1 Estrat´egias de Cada Aplica¸c˜ao
No estudo tamb´em foi levantada a quantidade de tratadores que adotam cada es-
trat´egia apresentada no trabalho de Cabral e Marques [2]. A Tabela 4.4 apresenta
esses valores levantados. Com esses valores pode-se observar que h´a uma grande
variedade de tratadores de exce¸c˜oes nas aplica¸c˜oes alvo do estudo.
51
1 public a b s tract p r iv ileged aspect L ogAbs tract Hand l er {
2 // A s sin a tur a de p oint cuts ab stra t os
3 public a b st ract poi n t cu t ch e cked Excep tion L og () ;
4 public a b st ract poi n t cu t exc e ptionL og () ;
5 // I mpl e men tan d o A d vice 1
6 Object arou n d () : c heck e dExc epti o nLog () {
7 Object resu l t = null ;
8 try { result = p r o ce e d () ;
9 } catch ( Ru ntime Excep t ion re ) {
10 throw re ;
11 } catch ( Exc e p tion e) {
12 String logTex t = ge t Messa g eText (
13 t h isE n clo s ing J oin P oin t Sta ticP art . g etId () );
14 get L ogObje c t () . logGen e ral ( logText , e );
15 }
16 return resu l t ;
17 }
18 // I mpl e men tan d o A d vice 2
19 Object arou n d () : e x cepti o nLog () {
20 Object resu l t = null ;
21 try {
22 result = proceed () ;
23 } catch ( Exc e p tion e) {
24 String logTex t = ge t Messa g eText (
25 t h isE n clo s ing J oin P oin tSta ticP art . g etId () );
26 get L ogObje c t () . logGen e ral ( logText , e );
27 }
28 return resu l t ;
29 }
30 // A s sin a tur a de m ´etod os a b stra tos
31 public a b st ract String g etMe s sageT e xt ( int p oi ntcutId );
32 public a b st ract IL o gObject ge t LogObj e ct () ;
33 }
Figura 4.5: Exemplo da estrat´egia throws.
Aplica¸c˜ao Estrat´egia
Vazio Log A./C.E. Lan¸camento Retorno Fechar Outros
Checkstyle 8 57 12 35 22 16 4
TeXclipse 68 53 4 34 38 2 9
EIMP 6 33 4 1 5 4 2
JHotDraw 14 22 2 9 6 2 2
PetStore 10 94 2 99 57 6 5
AOPMetrics 2 5 9 1 0 0 1
Metrics 15 59 6 7 16 0 4
Tabela 4.4: Quantidade de tratadores para cada estrat´egia.
52
Foi realizado tamb´em um comparativo dos tipos de exce¸c˜oes que cada aplica¸c˜ao
levanta, com o tratamento adotado, para se ter uma id´eia sobre como cada tipo
da exce¸c˜ao ´e tratado. Em cada aplica¸c˜ao, os tipos de exce¸c˜oes foram divididos em
trˆes grupos: i) exce¸c˜ao da pr´opria aplica¸c˜ao; ii) exce¸c˜ao encontrada em bibliotecas
utilizadas pelo projeto; iii) exce¸c˜ao existente em Java e AspectJ. Assim, foi feito
o mapeamento de cada tipo de exce¸c˜ao, de acordo com os grupos aqui definidos.
A Tabela 4.5 apresenta, para duas aplica¸c˜oes pertencentes ao mesmo dom´ınio, Me-
trics e AOPMetrics, os tipos de exce¸c˜oes pelos grupos. H´a apenas quatro casos
de exce¸c˜oes em comum entre as duas aplica¸c˜oes e as aplica¸c˜oes adotam estrat´egias
de tratamento bem distintas para elas. Isso fornece evidˆencia de que um mesmo
dom´ınio (funcionalidade) n˜ao ´e um fator relevante na an´alise da similaridade dos
tratadores de exce¸c˜oes de aplica¸c˜oes distintas. Evidˆencia essa encontrada pelos dois
sistemas de coleta de m´etricas utilizados no estudo.
53
Aplica¸c˜ao
Grupo Tipo da Exce¸c˜ao
AOPMetrics
Definida na org.tigris.aopmetrics.ajdt.AjdtBuilderException
Aplica¸c˜ao org.tigris.aopmetrics.AopMetricsRunnerException
org.tigris.aopmetrics.export.ExporterException
Importada de org.apache.commons.cli.MissingArgumentException
Biblioeta org.apache.commons.cli.MissingOptionException
org.apache.commons.cli.ParseException
java.lang.IllegalArgumentException(
Definidas em java.lang.InterruptedException
Java e AspectJ java.io.IOException
java.lang.Throwable
Metrics
Definida na com.touchgraph.graphlayout.TGException
Aplica¸c˜ao net.sourceforge.metrics.ui.EnableMetrics.MetricsNatureException
org.apache.tools.ant.BuildException
org.eclipse.core.runtime.CoreException
Importada de org.eclipse.core.runtime.OperationCanceledException
Biblioeta org.eclipse.jdt.core.compiler.InvalidInputException
org.eclipse.jdt.core.JavaModelException
org.eclipse.ui.PartInitException
java.net.MalformedURLException
java.io.FileNotFoundException
java.io.IOException
java.lang.Exception
java.lang.IllegalAccessException
java.lang.IllegalArgumentException
java.lang.InstantiationException
Definidas em java.lang.InterruptedException
Java e AspectJ java.lang.NumberFormatException
java.lang.reflect.InvocationTargetException
java.lang.RuntimeException
java.lang.StringIndexOutOfBoundsException
java.lang.OutOfMemoryError
java.lang.Throwable
java.util.MissingResourceException
jdbm.helper.IterationException
Tabela 4.5: Mapeamento de cada tipo de exce¸c˜ao com seu respectivo grupo.
54
4.6 Problemas Relacionados
Al´em dos fatores encontrados em trabalhos anteriores, que mostram algumas di-
ficuldades da tarefa de reusar tratadores intra-aplica¸c˜oes [6][30][42], o reuso inter-
aplica¸c˜oes possui um conjunto de problemas espec´ıficos. Vale destacar que esses
problemas encontrados s˜ao referentes a refatora¸c˜oes de sistemas de software reais,
utilizados na pr´atica e com tamanho m´edio. Alguns desses problemas provavelmente
podem tamb´em ser encontrados em fase de desenvolvimento.
Podemos citar inicialmente o conjunto de bibliotecas existente em cada projeto.
O uso de bibliotecas distintas em cada projeto faz haver diferentes problemas. Es-
trat´egias de tratamento em programas que necessitam ler algum tipo de informa¸c˜ao
contida em um arquivo (input/output) s˜ao diferentes das de programas que fazem
transa¸c˜oes em banco de dados e transa¸c˜oes que recebem entrada pela interface gr´afica
com o usu´ario (GUI). Isso ´e relacionado com o dom´ınio espec´ıfico da aplica¸c˜ao, pois
cada dom´ınio necessita de bibliotecas diferentes.
Al´em do dom´ınio espec´ıfico, tamb´em ´e levado em considera¸c˜ao a plataforma de
desenvolvimento para cada aplica¸c˜ao. Aplica¸c˜oes com o mesmo dom´ınio podem
ter bibliotecas diferentes, a depender de cada plataforma. Uma aplica¸c˜ao desen-
volvida para ambiente m´ovel necessita de bibliotecas espec´ıficas, diferentemente de
um mesmo tipo de aplica¸c˜ao desenvolvida para ambiente desktop. Problemas para
o mesmo dom´ınio e plataformas semelhantes podem ser ainda encontrados pela
diversidade de bibliotecas distintas que possuem a mesma funcionalidade, mas a im-
plementam de maneiras distintas. Exemplo disso s˜ao as bibliotecas de parsing para
arquivos XML, a DOM e a SAX. Cada uma utiliza estrat´egias diferentes para rea-
lizar a leitura dos arquivos XML, a depender da necessidade e escolha no momento
de desenvolvimento.
Caso n˜ao existam problemas relativos ao dom´ınio, plataforma e utiliza¸c˜ao de
bibliotecas, existe um outro fator. A estrat´egia de tratamento da mesma exce¸c˜ao,
para cada aplica¸c˜ao. Isso est´a relacionado a fatores diversos como a equipe de desen-
volvimento, a cultura da empresa onde o sistema foi desenvolvido, os requisitos do
sistema at´e a cada pessoa que participou do desenvolvimento. Tratadores para uma
mesma exce¸c˜ao podem ter estrat´egias diferentes em um mesmo sistema, devido aos
membros da equipe que o implementou e at´e mesmo ao momento da implementa¸c˜ao,
como proximidade ou n˜ao de uma entrega, por exemplo. Esse problema pode ser
ainda mais discrepante em aplica¸c˜oes distintas, com equipes distintas e ambientes
de desenvolvimento completamente diferentes.
Alguns problemas n˜ao s˜ao inerentes ao ambiente mas sim a constru¸c˜oes da lingua-
gem. Como este estudo teve como objetivo reusar c´odigo de tratadores de exce¸c˜oes
55
com AspectJ, ent˜ao alguns problemas s˜ao relacionados `as linguagens Java e As-
pectJ. Um problema bem simples, f´acil de ser contornado, mas que necessita de
modifica¸c˜oes no c´odigo original, ´e o uso de palavras reservadas em cada linguagem,
podendo variar at´e em uma mesma linguagem. AspectJ possui algumas palavras
reservadas diferentes das de Java e pode haver a adi¸c˜ao de novas palavras reservadas
de uma vers˜ao da linguagem para a outra. Em uma aplica¸c˜ao utilizada no estudo,
o programa Java original utilizava uma vari´avel com o nome before. Em Java isso
´e v´alido, mas before ´e, em AspectJ, uma palavra reservada, o que significa que
compiladores para AspectJ consideram tal programa inv´alido. Uma das solu¸c˜oes
para esse problema ´e o uso do pr´e-processamento.
4.7 Conclus˜oes do Reuso Inter-Aplica¸c˜ao
Nesse cap´ıtulo, foi apresentado um estudo focando no ganho potencial que a mo-
dulariza¸c˜ao do c´odigo relativo ao tratamento de exce¸c˜oes pode proporcionar, em
diferentes aplica¸c˜oes. Para isso, o c´odigo de tratamento de exce¸c˜oes de sete sistema
foi extra´ıdo para aspectos, reusado internamente a cada aplica¸c˜ao e, em seguida,
foi analisada a possibilidade de reusar tais aspectos entre as sete aplica¸c˜oes. Os
resultados do estudo mostraram que ´e poss´ıvel reusar aspectos de tratamento de
exce¸c˜oes apenas em poucos casos, e esses casos foram muito simples. Neste estudo,
em nenhuma situa¸c˜ao foi poss´ıvel reutilizar tratadores com mais que uma linha de
c´odigo entre diferentes aplica¸c˜oes. Em poucos casos foi poss´ıvel reusar e, nesses ca-
sos, foi necess´ario levar em considera¸c˜ao sete aplica¸c˜oes diferentes, com finalidades
e plataformas diferentes, desenvolvidas independente por organiza¸c˜oes distintas, em
momentos diferentes e com equipes diferentes. Essa grande complexidade pode ter
sido o motivo do baixo reuso. Outro ponto ´e que os tratadores de exce¸c˜oes analisa-
dos n˜ao foram projetados para ser reusados, o que pode tamb´em ter interferido nos
resultados. Esses tratadores foram reutilizados a partir de sistemas j´a existentes.
56
Cap´ıtulo 5
EH-Meter
M´etricas est´aticas de c´odigo s˜ao amplamente utilizadas para avaliar atributos de
qualidade de sistemas de software [39]. M´etricas de c´odigo podem fornecer desde
informa¸c˜oes b´asicas, como n´umero de linhas de c´odigo e de m´odulos no sistema, at´e
informa¸c˜oes mais refinadas como as dependˆencias entre os elementos do sistema e
o qu˜ao focados esses elementos s˜ao [9]. Idealmente, m´etricas de c´odigo devem ser
coletadas de maneira autom´atica, a fim de acelerar o processo de medi¸c˜ao, evitar os
erros inerentes `a coleta manual e garantir a uniformidade dos resultados, tornando
poss´ıvel a realiza¸c˜ao de compara¸c˜oes.
Existem diversas ferramentas capazes de coletar m´etricas est´aticas de c´odigo a
partir de programas escritos em diferentes linguagens de programa¸c˜ao. Por exem-
plo, Metrics
1
e FindBugs
2
coletam diversas m´etricas a partir de programas escritos
em Java. Tamb´em existem Resource Standard Metrics
3
, que possuem como alvo
sistemas escritos em C, C++, C# e Java.
Apesar da crescente popularidade da Programa¸c˜ao Orientada a Aspectos (POA)
[27], h´a poucas ferramentas de coleta de m´etricas capazes de medir programas escri-
tos em linguagens de POA de forma autom´atica. Um exemplo de tais ferramentas
´e o AOPMetrics, que coleta m´etricas de programas em AspectJ [29], uma extens˜ao
orientada a aspectos da linguagem Java. Para que POA possa se consolidar como
o pr´oximo passo na evolu¸c˜ao das linguagens de programa¸c˜ao, essa t´ecnica precisa
ser avaliada exaustivamente, tanto qualitativa quanto quantitativamente e melhor
ainda de forma automatizada.
At´e onde foi poss´ıvel averiguar, todas as ferramentas de coleta de m´etricas exis-
tentes trabalham com m´etricas gerais, aplic´aveis a todos os interesses de um sistema.
Consequentemente, n˜ao ´e poss´ıvel avaliar alguns atributos de qualidade no contexto
1
http://metrics.sourceforge.net/
2
http://findbugs.sourceforge.net/
3
http://msquaredtechnologies.com/
57
de interesses espec´ıficos. Entretanto, alguns autores [7, 19, 16, 42] acreditam que,
para avaliar o impacto de novas abordagens de desenvolvimento, como POA, em
atributos de qualidade como reuso, m´etricas focadas em interesses espec´ıficos s˜ao
mais eficazes do que as independentes de interesse. Utilizar apenas m´etricas que se
aplicam ao sistema como um todo, sem levar em conta os interesses que o comp˜oem,
pode fazer com que a avalia¸c˜ao de tais abordagens n˜ao reflita adequadamente seus
benef´ıcios e limita¸c˜oes.
N˜ao ´e uma tarefa simples fazer a adapta¸c˜ao de uma ferramenta que coleta
m´etricas gen´ericas para tamb´em coletar m´etricas de interesse espec´ıfico. Atual-
mente, existe uma ferramenta dispon´ıvel que conta c´odigo relativo a um interesse
(concern) especificamente: ConcernTagger
4
, um plugin para o Eclipse. Apesar de
suas muitas vantagens, ConcernTagger exige que os usu´arios tenham que selecio-
nar manualmente quais partes (m´etodos ou classe) do c´odigo referem-se ao interesse
que se deseja computar. Ela tamb´em imp˜oe algumas limita¸c˜oes sobre as linhas de
c´odigo, deixando seus usu´arios sem poder selecionar linhas dentro de um m´etodo.
Isso impede a coleta de algumas m´etricas de granularidade mais fina, como CD-
LOC [37]. Outra limita¸c˜ao do ConcernTagger ´e que ele s´o pode fazer a medi¸c˜ao de
programas Java. Outra ferramenta similar ao ConcernTagger ´e a AJATO
5
, onde o
usu´ario precisa selecionar manualmente quais partes do c´odigo fonte do programa
s˜ao relativas ao interesse espec´ıfico.
Para melhor convencer a academia e ind´ustria de software sobre os benef´ıcios da
POA, avalia¸c˜oes exaustivas e profundas, tanto qualitativas como quantitativas, s˜ao
necess´arias. Argumentamos que um interesse espec´ıfico, a abordagem de medi¸c˜ao
automatizada deve ser empregada para obter resultados melhores e mais precisos,
em estudos emp´ıricos. Este cap´ıtulo apresenta uma ferramenta de coleta de m´etricas
que visa preencher parcialmente essa lacuna. A ferramenta proposta, chamada de
EH-Meter (Exception Handler Meter), ´e capaz de coletar 11 m´etricas descritas em
diferentes trabalhos na literatura [18, 37] a partir de programas escritos em Java
ou AspectJ. Dez dessas m´etricas lidam com um interesse espec´ıfico ( tratamento
de exce¸c˜oes. Uma facilidade de tratar com esse interesse (tratamento de exce¸c˜oes),
al´em de ser o foco desse trabalho de mestrado, ´e o dato de que ´e um interesse
demarcado sintaticamente no c´odigo do programa, o que evita dificuldades ligadas
`a minera¸c˜ao de interesses [34] e permite que o foco se mantenha na atividade de
medi¸c˜ao. Essa ferramenta foi usada nos estudos apresentados nos Cap´ıtulos 3 e 4
para realizar diversas medi¸c˜oes de forma autom´atica.
4
http://www1.cs.columbia.edu/ eaddy/concerntagger/
5
http://www.teccomm.les.inf.puc-rio.br/emagno/ajato/
58
Esse trabalho gerou um artigo que foi aceito, publicado e apresentado no 3
o
ACoM [43] (3rd Workshop on Assessment of Contemporary Modularization Tech-
niques - ACoM.09), em OOPSLA.
Nas pr´oximas se¸c˜oes s˜ao apresentadas as m´etricas coletadas pelo EH-Meter
(Se¸c˜ao 5.1), sua estrutura¸c˜ao interna (Se¸c˜ao 5.2), como ela pode ser usada para
medir programas em Java e AspectJ (Se¸c˜ao 5.3), uma avalia¸c˜ao preliminar (Se¸c˜ao
5.4) e as conclus˜oes (Se¸c˜ao 5.5) do cap´ıtulo.
5.1 M´etricas Implementadas
O EH-Meter ´e capaz de colher diversas m´etricas relativas ao interesse de tratamento
de exce¸c˜oes. As m´etricas escolhidas s˜ao divididas em dois grupos: m´etricas de
tamanho e m´etricas de interesses. O primeiro grupo engloba diversas m´etricas que
visam determinar a quantidade de c´odigo em um sistema relativa ao interesse de
tratamento de exce¸c˜oes. Para tanto, h´a desde m´etricas tradicionais, como n´umero
de linhas de c´odigo (tanto total quanto espec´ıficas de tratamento de exce¸c˜oes) e
outras menos comuns, como n´umeros de blocos catch e finally. Essas m´etricas
s˜ao listadas na Tabela 5.1. e foram apresentadas e descritasno Cap´ıtulo 3. Para as
m´etricas NOT, NOC e NOF, caso o bloco try (-catch, -finally) apare¸ca dentro
de outro bloco catch ou finally (mas n˜ao try), ele n˜ao ´e levado em conta. A
justificativa para isso ´e que, para fins de separa¸c˜ao de interesses, tal bloco n˜ao
precisaria ser separado pois n˜ao est´a misturado a outros interesses. Essa decis˜ao
est´a em conformidade com o que foi seguido nos estudos descritos nos cap´ıtulos
anteriores.
59
Grupo M´etrica Descri¸c˜ao
LOC Lines of Common Code: Linhas de c´odigo do sistema,
excluindo-se coment´arios e linhas em branco.
NOT Number of Try blocks: N´umero de blocos try.
M´etricas NOC Number of Catch blocks: N´umero de blocos catch.
de NOF Number of Finally blocks: N´umero de blocos finally.
Tamanho LOCEH Lines of Exception Handling Code: Linhas de c´odigo
relativo ao tratamento de exce¸c˜oes.
NEH Number of Exception Handlers: N´umero de blocos de c´odigo
relativos ao tratamento de exce¸c˜oes.
CDC Concern Diffusion over Component [37]: Conta o n´umero de
componentes(classes, aspectos, interfaces) que incluem c´odigo
de tratamento de exce¸c˜oes.
CDO Concern Diffusion over Operation [37]: Conta o n´umero de
opera¸c˜oes(m´etodos e advice) que incluem c´odigo de
tratamento de exce¸c˜oes.
CDLOC Concern Diffusion over Lines of Code [37]: Conta o n´umero de
M´etricas pontos de transi¸c˜ao para cada interesse atrav´es das linhas
de de c´odigo. O uso dessa m´etrica exige um processo
Interesse de sombreamento dentro do c´odigo, com ´areas sombreadas
e ´areas n˜ao-sombreadas.
LOF Lack of Focus: Essa ´e uma medida da ausˆencia de foco de cada
componente, para todos os interesses. O resultado ´e
normalizado entre 0 (completamente focado) e 1
(completamente sem foco). O resultado dessa m´etrica ´e obtido
a partir do valor da m´etrica DOF (Degree of Focus) [18].
LOF = 1 - DOF.
DOS Degree of scattering [18]: Essa m´etrica mede a varia¸c˜ao de
concentra¸c˜ao de um interesse por todos os componentes. O
resultado ´e normalizado entre 0 (completamento localizado)
e 1(completamente distribu´ıdo).
Tabela 5.1: Conjunto de M´etricas implementadas no EH-Meter
60
O outro grupo de m´etricas, relativas a separa¸c˜ao de interesses e tamb´em apre-
sentadas na Se¸c˜ao 3.4, tem o intuito de medir o quanto o c´odigo est´a direcionado
aos interesses analisados, que no caso desse trabalho ´e o tratamento de exce¸c˜oes,
e separado do c´odigo relativo aos outros interesses do sistema. As trˆes primeiras
delas mostram valores absolutos. As duas ´ultimas m´etricas relativas a interesses
contabilizam de forma normalizada os valores apresentados. Para todas as m´etricas,
um valor menor implica em um resultado melhor.
5.2 Implementa¸c˜ao
O EH-Meter ´e uma extens˜ao da ferramenta AopMetrics
6
. Para facilitar a imple-
menta¸c˜ao do EH-Meter, recursos como os parsers para Java e AspectJ e o engenho de
coleta de m´etricas do AopMetrics foram utilizados. Para a maior parte das m´etricas,
foi necess´ario apenas implementar as classes respons´aveis pelas novas m´etricas. Al-
gumas delas, por´em, exigem que a medi¸c˜ao seja feita de um modo diferente do que
acontece no AopMetrics, levando em conta o sistema como um todo e n˜ao apenas os
valores individuais da m´etrica para cada componente analisado. Para estes casos,
foi necess´ario modificar o engenho de medi¸c˜ao do AopMetrics.
5.2.1 Arquitetura e Modifica¸c˜oes no C´odigo Original
A arquitetura da ferramenta ´e simples, dividida em m´odulos (pacotes) com prop´ositos
bem definidos. No pacote principal se encontram o c´odigo respons´avel por receber
entradas do usu´ario para execu¸c˜ao da ferramenta e outros recursos comuns a toda
a ferramenta, como o engine de coleta de m´etricas. Em outros pacotes, source e
ajdt, s˜ao encontrados elementos que fazem referˆencia a um projeto Java e AspectJ
e transforma¸c˜oes necess´arias, respectivamente. O pacote metrics cont´em as classes
que implementam as m´etricas a serem coletadas. A maior parte das altera¸c˜oes apli-
cadas ao AopMetrics resultaram em novas classes sendo inclu´ıdas neste pacote. Os
´ultimos pacotes, export e results, cont´em o c´odigo respons´avel por exportar os
resultados da medi¸c˜ao para planilhas em formato XLS e como s˜ao as sa´ıdas das
m´etricas, quando executadas. A Figura 5.1 mostra as dependˆencias entre os pacotes
do sistema.
A primeira modifica¸c˜ao para dar suporte aos novos tipos de m´etricas diz respeito
a como ´e calculado o valor para cada uma. Normalmente, as medi¸c˜oes s˜ao execu-
tadas individualmente para cada componente (classe, interface e aspecto). Assim,
6
http://aopmetrics.tigris.org/
61
Figura 5.1: Hierarquia de Pacotes do EH-Meter.
cada m´etrica ´e coletada uma vez para cada componente sem o valor de um compo-
nente interferir no valor de outro. O resultado total da medi¸c˜ao ´e o somat´orio dos
valores da m´etrica para cada componente. A m´etrica DOS, por´em, ´e calculada para
todos os componentes do sistema. Logo, foi necess´ario levar em conta os valores
relativos a cada componente do sistema para poder fazer o c´alculo da m´etrica. Esse
comportamento precisou ser incorporado ao engenho de coleta do AopMetrics, j´a
que este ´e constru´ıdo partindo da suposi¸c˜ao de que todas as m´etricas podem ser
coletadas de forma independente, para cada componente.
A segunda modifica¸c˜ao diz respeito `a listagem de todas as m´etricas. A classe
Metrics cont´em um ´ındice de todas as m´etricas que devem ser coletadas. Para
o EH-Meter, foram adicionadas as novas m´etricas implementadas e suas respecti-
vas Strings de identifica¸c˜ao. Ponto comum entre todas as m´etricas ´e a interface
MetricsCalculator. Entretanto, essa interface ´e aplic´avel apenas para m´etricas
que n˜ao precisam ser coletadas globalmente, sendo apenas para c´alculo em cada
componente. Logo, a ´ultima modifica¸c˜ao consistiu na cria¸c˜ao de uma interface para
abranger as m´etricas que s˜ao calculadas utilizando dados de todo o sistema. Essa
interface foi denominada de MetricsCalculatorGeneral e pode ser usada na im-
plementa¸c˜ao de novas m´etricas com essa caracter´ıstica. No Trecho de C´odigo 5.2 ´e
apresentada a classe Metrics.java, que cont´em a lista das m´etricas que ser˜ao exe-
cutadas. Em resumo, o EH-Meter ´e capaz de medir dois tipos de m´etricas: m´etricas
por unidade de compila¸c˜ao (compilation unit - um arquivo fonte) e m´etricas gerais.
Uma m´etrica que medir apenas uma unidade de compila¸c˜ao, deve implementar a in-
terface MetricsCalculator e para implementar m´etricas gerais, deve implementar
a interface MetricsCalculatorGeneral.
62
1 package br . upe . dsc . ehmeter . metrics ;
2
3 public class Met r i c s {
4 // ... mode code
5 public stat i c final Me t rics C alcu l ator [] t ype M etri csCa l cula tors = {
6 new L ines O fClas sCode () ,
7 new NOT () ,
8 new NOC () ,
9 new NOF () ,
10 new LOCEH () ,
11 new CDO () ,
12 new CDLOC () ,
13 new CDC () ,
14 new NOEH () ,
15 new DOF () ,
16 new NOEHE ()
17 };
18 public stat i c final Me tric s Cal c ulat orGe n era l [] t ypeM e tric sGene ral = {
19 new DOS ()
20 };
21 // ...
22 }
Figura 5.2: C´odigo da Classe Metrics.java
5.2.2 Novas M´etricas
Para as novas m´etricas implementadas, na maioria dos casos foi estendida a classe
ASTVisitor para detectar ocorrˆencias de trechos de c´odigo relativos ao tratamento
de exce¸c˜oes. Esses trechos de c´odigo na maioria dos casos foram ocorrˆencias de
blocos try (catch, finally), declara¸c˜oes de m´etodos e blocos de c´odigo. Para as
m´etricas de tamanho, os resultados foram obtidos apenas atrav´es da contagem das
ocorrˆencias do peda¸co de c´odigo desejado. Para m´etricas de interesses, interfaces
n˜ao foram consideradas por n˜ao inclu´ırem comportamento, sendo apenas analisadas
classes e aspectos. CDC e CDO foram bem simples, bastando apenas marcar para
cada componente e opera¸c˜ao, respectivamente, a existˆencia de c´odigo tratador de
exce¸c˜oes. Para LOF (medida utilizando DOF) e DOS, apenas foi necess´ario utilizar
informa¸c˜oes de outras m´etricas, como linhas de c´odigo, linhas de c´odigo relativas ao
tratamento de exce¸c˜oes e n´umero de componentes de cada interesse.
A M´etrica CDLOC ´e a que apresenta a implementa¸c˜ao mais complexa. Essa com-
plexidade decorre da dificuldade de lidar com todos os casos poss´ıveis de transi¸c˜oes
entre interesses no c´odigo de um sistema. Em todos os trabalhos anteriores sobre
m´etricas de separa¸c˜ao de interesses [6, 7, 24, 37], essa m´etrica foi coletada manual-
mente. Al´em disso, nenhuma ferramenta de coleta de m´etricas estudadas (Metrics,
AOPMetrics e Resource Standard Metrics), mesmo as que realizam medi¸c˜ao de
forma semi-autom´atica (nas quais o usu´ario precisa indicar o c´odigo relativo a cada
63
interesse), como ConcernTagger e AJATO, ´e capaz de coletar essa m´etrica. A Fi-
gura 5.3 mostra um exemplo de como s˜ao diferenciadas as ´areas de transi¸c˜ao entre o
tratamento de exce¸c˜oes (fundo cinza) e o comportamento normal do sistema (fundo
branco). Na implementa¸c˜ao, foi necess´ario detectar e marcar essas ´areas, a fim de
calcular as transi¸c˜oes. Para essa m´etrica, tˆem que ser levados em conta diversos
casos de transi¸c˜ao entre o c´odigo referente ao tratamento de exce¸c˜oes e o c´odigo
relativo ao comportamento normal do sistema. Fatores complicadores incluem a
existˆencia de diversos blocos de tratamento de exce¸c˜oes, potencialmente aninhados,
blocos de la¸cos (while, for), blocos condicionais (if, switch) e situa¸c˜oes bem
particulares.
Figura 5.3: Transi¸c˜oes entre os interesses.
5.3 Execu¸c˜ao e Resultados da Ferramenta
Do mesmo modo que a ferramenta AopMetrics, a ferramenta EH-Meter funciona
atrav´es de tasks do Apache Ant
7
. Atrav´es de um arquivo de configura¸c˜ao XML ´e
especificado quais ser˜ao os programas Java e AspectJ que a ferramenta vai analisar,
7
http://ant.apache.org/
64
1 <? xml version = " 1.0 " enco d i ng =" UTF -8 "? >
2 < project name =" run - eh - meter " defau l t =" run " >
3 <! -- Def i ni¸c ~ao de P r opr i eda des -->
4 < p roperty name =" dir . build " value = " ../ ehmeter " / >
5 < p roperty name =" dir . work " value =" ${ dir . build }/ work " / >
6 < p roperty name =" dir . libr a ries E HMet e r " value =" ${ dir . build }/ libs " / >
7 < p roperty name =" dir . lib " value = " ../ lib " / >
8 < p roperty name =" dir . src " value = " ../ src " / >
9 < p roperty name =" dir . src2 " value =" ../ nls " / >
10 <! -- L ista n do b ibl iote cas p a r a ser u sa das -- >
11 <path id =" clas s path . common " >
12 < f i le se t dir =" ${ dir . lib } " > < include name =" *. jar " / > </ fileset >
13 < f i le se t dir =" ${ dir . l i brar i esEH M eter } " >
14 < include name =" *. jar " / >
15 </ fileset >
16 < f i le se t dir =" . ./ ../../ plu g i n s ">
17 < include name =" *. jar " / >
18 </ fileset >
19 </ path >
20 <! -- E xecu ¸c~ao do EH - M et e r - - >
21 < t a r g e t name = " run " des c riptio n =" Co m p utes metric s on the project . " >
22 < t a sk de f name = " ehmeter " c la ssname = "br . upe . dsc . ehmet e r . EHM e terTask "
23 class p at h =" ${ dir . l i brari esEHM e ter }/ ehmeter - 0 . 4 .1 . jar "/ >
24
25 < e h me te r workdir = " ${ dir . work } " s ourcel e vel =" 1.5 " e x p o r t =" xls "
26 res u ltsfil e =" ${ dir . work }/ metrics - results . xls " >
27 < fileset dir =" ${ dir . src }" i n cludes = " * * / *. java "/ >
28 < fileset dir =" ${ dir . src }" i n cludes = " * * / *. aj "/ >
29 < fileset dir =" ${ dir . src2 } " i nc lu de s =" **/*. java " />
30 < fileset dir =" ${ dir . src2 } " i nc lu de s =" **/*. aj "/ >
31 < clas s path refid =" c lasspath . common "/ >
32 </ ehmeter >
33 </ target >
34 </ p r o je c t >
Figura 5.4: Exemplo de um arquivo de configura¸c˜ao para executar o EH-Meter.
quais as bibliotecas que devem ser utilizadas como referˆencia, vers˜ao da linguagem e
o nome do arquivo de sa´ıda. Um exemplo do arquivo XML que pode ser empregado
´e apresentado no Trecho de C´odigo da Figura 5.4. Esse trecho de c´odigo mostra
a defini¸c˜ao da task a ser executada e os parˆametros necess´arios para a execu¸c˜ao e
coleta de m´etricas.
Arquivo de sa´ıda produzido pela ferramenta ´e uma planilha eletrˆonica no padr˜ao
do Microsoft Excel (XLS), embora tamb´em possa ser produzido um arquivo no
padr˜ao XML. Essa planilha cont´em, para cada componente do sistema, o valor de
cada uma das m´etricas, descritas na Se¸c˜ao 5.1, assim como os valores para o sistema
inteiro. Como dito anteriormente, a exce¸c˜ao ´e a m´etrica DOS, que depende do
65
sistema completo e, por isso, n˜ao tem valores individuais para os componentes do
sistema. A Figura 5.5 apresenta um exemplo dos resultados de sa´ıda do EH-Meter.
Pode-se observar que todas as m´etricas apresentam um valor para cada componente,
enquanto DOS s´o apresenta um valor geral, para todo o sistema.
Figura 5.5: Resultado das M´etricas Coletadas.
5.4 Avalia¸c˜ao
Existem algumas ferramentas para coletar m´etricas e avaliar atributos de quali-
dade do software. As m´etricas expressam uma avalia¸c˜ao quantitativa para ajudar
a tomada de decis˜oes estrat´egicas sobre como atividades ser˜ao realizadas, o mo-
nitoramento do progresso durante o desenvolvimento do software e o controle de
qualidade do produto. Nesse contexto, a automatiza¸c˜ao ´e muito importante para
acelerar o processo de medi¸c˜ao e prover resultados consistentes e uniformes. Entre-
tanto, ´e dif´ıcil coletar m´etricas para interesses de forma automatizada. Por isso, as
ferramentas existentes capazes de medir programas orientados a aspectos de forma
autom´atica coletam apenas m´etricas gerais. EH-Meter sacrifica a generalidade, a
fim de automatizar a medi¸c˜ao de um interesse espec´ıfico: tratamento de exce¸c˜oes.
Nessa se¸c˜ao ´e descrita uma avalia¸c˜ao do EH-Meter. Ele foi comparado com ou-
tras ferramentas de coleta de m´etricas usando como principal crit´erio a economia
de tempo para coletar m´etricas de tratamento de exce¸c˜oes. Como dito anterior-
mente, EH-Meter tamb´em foi utilizada para apoiar os estudos emp´ıricos descritos
nos Cap´ıtulos 3, e 4,.
5.4.1 Comparando Abordagens de Medi¸c˜oes
Foram feitos testes comparativos para avaliar os benef´ıcios obtidos a partir de uma
abordagem de medi¸c˜ao baseada no EH-Meter. Inicialmente, foram verificados os
tempos gastos para coletar m´etricas especificamente para o tratamento de exce¸c˜oes,
66
utilizando trˆes abordagens diferentes. A primeira consiste na coleta manual das
m´etricas. A segunda e a terceiras foram parcialmente e completamente automa-
tizadas, utilizando o ConcernTagger e o EH-Meter, respectivamente. Trˆes vers˜oes
de um sistema usado no estudo de caso foram escolhidas para comparar as coletas
de m´etricas. A utilizada foi o JHotDraw, apresentado na Se¸c˜ao 3.2 do Cap´ıtulo 3.
A compara¸c˜ao envolveu apenas as m´etricas de interesses, mais especificamente em
CDC, CDO e CDLOC, j´a que algumas ferramentas existentes ap´oiam a coleta delas.
A Tabela 5.2 apresenta os resultados obtidos. As colunas apresentam a aborda-
gem de coleta de m´etricas adotada e as linhas apresentam as vers˜oes dos sistemas. Os
n´umeros na tabela indicam os tempo (em minutos) necess´arios para fazer a medi¸c˜ao
usando cada abordagem. N/A indica que n˜ao foi poss´ıvel colher a m´etrica para
essa vers˜ao, com a referida abordagem.
Manual ConcernTagger EH-Meter
C´odigo Original 10 15 1
Vers˜ao Ref. OO 10 15 1
Vers˜ao Ref. AO 10 N/A 1
Tabela 5.2: Comparativo de coleta de m´etricas. Os n´umeros representam o tempo,
em minutos.
Os resultados mostram que EH-Meter foi mais eficiente do que os outros meios
de coletas de m´etricas abordados. A Coleta manual obteve melhores resultados
do que a ferramenta ConcernTagger, mas a coleta manual ´e bem mais sucet´ıvel a
erros. Outra quest˜ao importante ´e que ConcernTagger n˜ao pode coletar a m´etrica
CDLOC, pois ´e necess´ario analisar o programa linha a linha e o ConcernTagger n˜ao
implementa essa funcionalidade. Adicionalmente, o ConcernTagger n˜ao consegue
fazer a medi¸c˜ao de programas em AspectJ, somente classes Java.
Uma quest˜ao que tem que ser deixada clara ´e que essa compara¸c˜ao foi realizada
apenas uma vez. Em caso de necessidade de re-coletar as m´etricas, devido a alguma
modifica¸c˜ao, a coleta manual pode ser mais onerosa do que o ConcernTagger. O
processo de medi¸c˜ao usando esta ´ultima envolve a marca¸c˜ao manual dos trechos de
c´odigo relativos a cada interesse, mas essa marca¸c˜ao s´o precisa ser realizada uma
vez. J´a na medi¸c˜ao manual, ´e necess´ario identificar as transi¸c˜oes entre interesses toda
vez que for necess´ario medir CDLOC. Al´em disso, ´e importante enfatizar que o EH-
Meter n˜ao ´e capaz de coletar m´etricas para qualquer interesse al´em de tratamento
de exce¸c˜oes, o que limita o seu escopo de aplica¸c˜ao.
67
5.5 Conclus˜ao
Neste cap´ıtulo foi apresentada a ferramenta EH-Meter, que implementa m´etricas
espec´ıficas de tratamento de exce¸c˜oes. Foram descritas as m´etricas implementadas
pela ferramenta, bem como sua arquitetura e as principais escolhas de projeto en-
volvidas no seu desenvolvimento. O EH-Meter ´e capaz de coletar m´etricas tanto a
partir de programas escritos em Java quanto de programas em AspectJ. At´e onde
se pode averiguar, o EH-Meter ´e a primeira ferramenta capaz de coletar m´etricas
para um interesse espec´ıfico de forma completamente autom´atica.
Uma poss´ıvel extens˜ao da ferramenta EH-Meter ´e a possibilidade de sugerir opor-
tunidades de reuso, procurando inicialmente por c´odigo duplicado. Assim, al´em de
fazer a coleta de m´etricas, poderia tamb´em sugerir melhorias de c´odigo a fim de
melhorar os valores das mesmas com o c´odigo mais reus´avel. A ferramenta EH-
Meter est´a dispon´ıvel no endere¸co http://www.cin.ufpe.br/∼fjclf/eh-meter.
No mesmo endere¸co tamb´em est´a dispon´ıvel o c´odigo fonte e tamb´em outras in-
forma¸c˜oes. A licen¸ca do EH-Meter ´e a GPL.
68
Cap´ıtulo 6
Conclus˜oes e Trabalhos Futuros
Neste trabalho foi abordado o reuso de c´odigo referente ao tratamento de exce¸c˜oes,
quando esse c´odigo ´e modularizado atrav´es de aspectos. Foram analisadas duas
situa¸c˜oes, atrav´es de dois estudos diferentes: reuso intra-aplica¸c˜ao e reuso inter-
aplica¸c˜ao.
O primeiro estudo abordou reuso intra-aplica¸c˜ao (Cap´ıtulo 3), ou seja, aborda o
reuso de c´odigo de tratadores de exce¸c˜oes dentro de uma mesma aplica¸c˜ao. Foram
utilizados trˆes sistemas relevantes na ind´ustria, com tamanho e atributos inter-
nos que proporcionaram um resultado significativo. Foram utilizadas onze m´etricas
de software para avaliar como o emprego de diferentes abordagens para a imple-
menta¸c˜ao de tratadores afetou o reuso. O principal resultado foi a confirma¸c˜ao de
que o uso de Programa¸c˜ao Orientada a Aspectos (POA) promove o reuso, dentro de
uma mesma aplica¸c˜ao. Esses resultados complementaram os resultados de Lippert
e Lopes [30] e contradisseram em parte o resultado de Castor et al. [6], em rela¸c˜ao
`a possibilidade de reuso de c´odigo de tratamento de exce¸c˜oes. Tal estudo tamb´em
confirmou estudos anteriores que afirmam que POA promove uma boa separa¸c˜ao
textual de c´odigo relativo ao interesse tratamento de exce¸c˜oes.
O segundo estudo abordou o reuso inter-aplica¸c˜ao (Cap´ıtulo 4), ou seja, o reuso
de tratadores de exce¸c˜oes entre aplica¸c˜oes diferentes. Para esse outro estudo foram
utilizados sete sistemas, com tamanhos em LOC, n´umero de tratadores e outras
caracter´ısticas que tamb´em foram levadas em considera¸c˜ao em rela¸c˜ao aos sistemas
utilizados no primeiro estudo. Um dos motivos dessa quantidade de sistemas foi
a necessidade de avaliar sistemas de software com finalidades e plataformas de de-
senvolvimento semelhantes e distintas. O resultado desse estudo evidenciou pouco
reuso de c´odigo de tratamento de exce¸c˜oes, ou seja, quando aplica¸c˜oes diferentes
est˜ao envolvidas, poucas situa¸c˜oes de reuso foram encontradas. A situa¸c˜ao onde a
maior quantidade de reuso foi obtida aplicou-se apenas a tratadores triviais, com
69
n˜ao mais que uma linha de c´odigo, al´em de exigir modifica¸c˜oes ao c´odigo original,
com implementa¸c˜oes de interfaces adicionais.
Os dois estudos utilizaram uma ferramenta desenvolvida no escopo deste tra-
balho, a EH-Meter (Cap´ıtulo 6). O EH-Meter foi desenvolvido tomando como base
a ferramenta AOPMetrics e ajudou na coleta de m´etricas espec´ıficas para o inter-
esse tratamento de exce¸c˜oes. Embora esse interesse seja f´acil de ser identificado
no c´odigo, a medi¸c˜ao de diversos sistemas n˜ao-triviais ´e uma tarefa demorada e
trabalhosa e, consequentemente, pass´ıvel de erro. A ferramenta automatiza esse
processo, facilitando o processo de medi¸c˜ao e evitando distor¸c˜oes devido a diferentes
abordagens de medi¸c˜ao.
6.1 Publica¸c˜oes Resultantes
Foram publicados trˆes trabalhos com resultado do esfor¸co desta pesquisa. A primeira
publica¸c˜ao foi referente ao estudo apresentado no Cap´ıtulo 3, onde foi avaliado o
reuso de c´odigo de tratamento de exce¸c˜oes intra-aplica¸c˜ao. O mesmo foi publicado
no XXIII Simp´osio Brasileiro de Engenharia de Software(SBES’09) [42]. Esse tra-
balho aborda estudos recentes que tentaram avaliar os benef´ıcios e desvantagens de
se empregar a programa¸c˜ao orientada a aspectos (POA) para modularizar c´odigo de
tratamento de exce¸c˜oes. O artigo descreve um novo estudo cujo objetivo ´e respon-
der se aspectos realmente promovem a implementa¸c˜ao de tratamento de exce¸c˜oes
reus´avel. Reuso ´e analisado em um contexto espec´ıfico: em termos do numero de
tratadores de erros duplicados ou muito similares que podem ser removidos de um
programa quando c´odigo de tratamento de exce¸c˜oes ´e extra´ıdo para aspectos.
A segunda publica¸c˜ao foi referente `a ferramenta desenvolvida durante o trabalho
de avalia¸c˜ao de reuso. O artigo aborda n˜ao apenas a ferramenta EH-Meter, como
tamb´em a id´eia de desenvolver ferramenta para coleta de m´etricas espec´ıficas para
um determinado interesse. Esse trabalho foi apresentado no Cap´ıtulo 5. O mesmo
foi publicado no 3
o
ACoM [43] (3rd Workshop on Assessment of Contemporary Mo-
dularization Techniques - ACoM.09), um workshop da OOPSLA (Object-Oriented
Programming, Systems, Languages and Applications.
A terceira publica¸c˜ao se refere ao estudo de reuso inter-aplica¸c˜ao, apresentado
no Cap´ıtulo 4. Esse artigo apresenta como foi aplicado o reuso entre sete aplica¸c˜oes
diferentes.
´
E uma continua¸c˜ao do estudo referente ao reuso intra-aplica¸c˜ao, por´em
abordando apenas vers˜oes com os tratadores de exce¸c˜oes modularizados em aspec-
tos, na linguagem AspectJ. O artigo foi submetido ao Empirical Evaluation of Soft-
ware Composition Techniques (ESCOT 2010) [41], um workshop da Conferˆencia de
70
Aspect-Oriented Software Development, e est´a aguardando resultado da avalia¸c˜ao
pelo comitˆe de programa.
6.2 Trabalhos Futuros
Os resultados e limita¸c˜oes deste trabalho apontam para outros trabalhos a serem
desenvolvidos no futuro.
O primeiro diz respeito a reusar c´odigo de vers˜oes diferentes de um mesmo sis-
tema. Neste caso, a id´eia ´e avaliar se tratadores de exce¸c˜oes modularizados atrav´es
de aspectos podem ser reusados entre vers˜oes diferentes de um mesmo sistema e at´e
que ponto. O segundo diz respeito `a modulariza¸c˜ao do tratamento de exce¸c˜oes de
aplica¸c˜oes desde o in´ıcio do seu desenvolvimento. Seria interessante ver os resulta-
dos de uma aplica¸c˜ao cujo c´odigo de tratamento de exce¸c˜oes ´e projetado para ser
reusado.
Tamb´em seria interessante a cria¸c˜ao de um cat´alogo de cen´arios de reuso. As-
sim, com estudos j´a realizados, junto com outros que ainda ser˜ao realizados, esse
cat´alogo poderia ser um resumo de todo o conhecimento obtido ao longo dessa s´erie
de estudos. Com esse cat´alogo ficaria mais f´acil fazer uma ferramenta de sugest˜oes
de reuso e at´e mesmo uma capaz de refatorar tratadores de forma autom´atica, de
modo a maximizar o reuso.
Um outro trabalho ´e avaliar at´e que ponto os mecanismos providos por dife-
rentes linguagens orientadas a aspectos auxiliariam ou n˜ao o reuso de tratadores de
exce¸c˜oes. Uma abordagem interessante seria um comparativo de linguagens como
CesarJ
1
, EJFlow [4] e alguma outra linguagem com suporte a Pontos de Jun¸c˜ao
Expl´ıcitos [25] para avaliar a influˆencia dos mecanismo no reuso de tratadores de
exce¸c˜oes.
1
scriptsizehttp://www.caesarj.org/
71
Referˆencias
[1] Carlos Andrade, Andr´e Santos, and Paulo Borba. Aspecth: Uma extens˜ao
orientada a aspectos de haskell. In I Workshop Brasileiro de Desenvolvimento
de Software Orientado a Aspectos, Bras´ılia, Brazil, 2004.
[2] Bruno Cabral and Paulo Marques. Exception handling: A field study in java and
.net. In 21st European Conference on Object Oriented Programming (ECOOP),
Berlin, Germany, 2007.
[3] N´elio Cacho, Francisco Dantas, Alessandro Garcia, and Fernando Castor Fillho.
Exception flows made explicit: An exploratory study. In 23rd Brazilian Sym-
posium on Software Engineering (SBES’2009), Fortaleza, Brazil, 2009.
[4] N´elio Cacho, Fernando Castor Fillho, Alessandro Garcia, and Eduardo Fi-
gueiredo. Ejflow: Taming exceptional control flows in aspect-oriented pro-
gramming. In 7th ACM Conference on Aspect-Oriented Software Development
(AOSD’2008), pages 152–162, Brussels, 2008.
[5] N´elio Cacho, Cl´audio Sant’Anna, Eduardo Figueiredo, Alessandro Garcia, and
Carlos Lucena. Composing design patterns: A scalability study of aspect-
oriented programming. In 5th ACM Conference on Aspect-Oriented Software
Development (AOSD’2006), pages 109–121, 2006.
[6] Fernando Castor, Nelio Cacho, Eduardo Figueiredo, Raquel Maranhao, Ales-
sandro Garcia, and Cecilia Mary F. Rubira. Exceptions and aspects: The devil
is in the details. In 14th SIGSOFT FSE, pages 152–162, 2006.
[7] Fernando Castor, Nelio Cacho, Eduardo Figueredo, Alessandro Garcia, Cec´ılia
M. F. Rubira, Jefferson Silva de Amorim, and H´ıtalo Oliveira da Silva. On the
modularization and reuse of exception handling with aspects. In Submitted to
Software - Practice & Experience, 2009.
[8] Fernando Castor, Alessandro Garcia, and Cecilia Mary F. Rubira. Extracting
72
error handling to aspects: A cookbook. In 23rd IEEE International Conference
on Software Maintenance, pages 152–162, 2007.
[9] Mariano Ceccato and Paolo Tonella. Measuring the effects of software aspecti-
zation. In 1st Workshop on Aspect Reverse Engineering (WARE 2004), 2004.
[10] Roberta Coelho, Uir´a Kulesza, Arndt von Staa, and Carlos Lucena. Unveiling
and taming the liabilities of aspect libraries reuse. In 22rd Brazilian Symposium
on Software Engineering (SBES’2008), 2008.
[11] Roberta Coelho, Awais Rashid, Alessandro Garcia, Fabiano Ferrari, N´elio Ca-
cho, Uir´a Kulesza, Arndt von Staa, and Carlos Lucena. Assessing the impact
of aspects on exception flows: An exploratory study. In 21st European Conf.
Object-Oriented Programming (ECOOP.08), Cyprus, 2008.
[12] JBoss Community. JBoss AOP. http://www.jboss.org/jbossaop, Apr 2010.
[13] Spring Source Community. The Spring FrameWork.
http://www.springsource.org/, Apr 2010.
[14] Spring.Net Community. Spring.Net Application Framework.
http://www.springframework.net//, Apr 2010.
[15] Flaviu Cristian. A recovery mechanism for modular software. In 4th ICSE,
pages 42–51, 1979.
[16] C´esar Francisco de Moura Couto, Jaqueline Faria, and Marco T´ulio Valente.
Estimativa de m´etricas de separa¸c˜ao de interesses em processos de refatora¸c˜ao
para extra¸c˜ao de aspectos. In VI Workshop de Manuten¸c˜ao de Software Mo-
derna, pages 1–8, 2009.
[17] Edsger W. Dijkstra. On the role of scientific thought. In Selected writings on
Computing: A Personal Perspective, pages 60––66, 1982.
[18] Marc Eaddy, Alfred Aho, and Gail C. Murphy. Identifying, assigning, and quan-
tifying crosscutting concerns. In 1st Workshop on Assessment of Contemporary
Modularization Techniques, Minneapolis, USA, 2007.
[19] Marc Eaddy, Thomas Zimmermann, Kaitlin D. Sherwood, Vibhav Garg, Gail C.
Murphy, Nachiappan Nagappan, and Alfred V. Aho. Do crosscutting concerns
cause defects? In IEEE Transactions on Software Engineering (34), July 2008.
73
[20] Christof Fetzer, Pascal Felber, and Karin Hogstedt. Automatic detection and
masking of nonatomic exception handling. In IEEE Trans. Sw. Eng., pages
547—-560, 2004.
[21] Eduardo Figueiredo, N´elio Cacho, Cl´audio Sant’Anna, M. Monteiro, Uir´a Ku-
lesza, Alessandro Garcia, S´ergio Soares, Fabiano Ferrari, Safoora Khan, Fer-
nando Castor Filho, and Franscisco Dantas. Evolving software product lines
with aspects: An empirical study on design stability. In Proceedings of the 30th
International Conference on Software Engineering, Leipzig, Germany., pages
547–560, 2008.
[22] Robert E. Filman and Daniel P. Friedman. Aspect-oriented programming is
quantification and obliviousness. In RIACS., 2000.
[23] Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-
Wesley, 1999.
[24] Alessandro Garcia, Cec´ılia Rubira, Alexander Romanovsky, and Jie Xu. A
comparative study of exception handling mechanisms for building dependable
object-oriented software. In Journal of Systems and Software, pages 197–222,
2001.
[25] Kevin Hoffman and Patrick Eugster. Towards reusable components with as-
pects: An empirical study on modularity and obliviousness. In Proceedings of
the International Conference on Software Engineering (ICSE), pages 197–222,
2008.
[26] Elmar Juergens, Florian Deissenboeck, Benjamin Hummel, and Stefan Wag-
ner. Do code clones matter? In 31st International Conference on Software
Engineering (ICSE’2009), pages 485–495, May 2009.
[27] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina
Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In
ECOOP, 1997.
[28] Rainer Koschke. Survey of research on software clones. In In Duplication,
Redundancy, and Similarity in Software, Dagstuhl Seminar Proceedings., 2007.
[29] Ramnivas Laddad. AspectJ in Action, Second Edition. Manning, 2009.
[30] Martin Lippert and Cristina Videira Lopes. A study on exception detection
and handling using aspect-oriented programming. In ICSE’2000, pages 418–
427, 2000.
74
[31] Thomas J. McCabe. A complexity measure. In ICSE’1976, page 407, 1976.
[32] Bertrand Meyer. Object-oriented Software Construction, 2nd Edition. Eiffel,
1997.
[33] Darrell Reimer and Harini Srinivasan. Analyzing exception usage in large java
applications. In In Proceedings of ECOOP’2003 Workshop on Exception Hand-
ling in Object-Oriented Systems, 2003.
[34] Martin P. Robillard and Gail C. Murphy. Static analysis to support the evolu-
tion of exception structure in object-oriented systems. In ACM Trans. Softw.
Eng. Methodol, pages 191–221, 2003.
[35] Chanchal Kumar Roy and James R. Cordy. A survey of software clone detec-
tion research. In Technical report, School of Computing, Queen’s University at
Kingston, Ontario, Candada, 2007.
[36] Vladimir Safonov. Aspect.net – a new approach to aspect-oriented program-
ming. In .NET Developer’s Journal, April 2003.
[37] Cl´audio Sant’Anna, Alessandro Garcia, Cristina Chavez, Carlos Lucena, and
Arndt von Staa. On the reuse and maintenance of aspect-oriented software: An
assessment framework. In XVII Brazilian Symposium on Software Engineering,
Manaus, Brazil, 2003.
[38] Robert W. Sebesta. Conceitos de Linguagens de Programa¸c˜ao, 5
a
ed. Bookman,
S˜ao Paulo, Brasil, 2003.
[39] Yan Sommerville. Engenharia de Software, 8
a
edi¸c˜ao. Pearson Adson Wesley,
S˜ao Paulo, 2007.
[40] Peri Tarr, Harold Ossher, William Harrison, , and Stanley M. J. Sutton. N
degrees of separation: Multi-dimensional separation of concerns. In 21st Inter-
national Conference on Software Engineering (ICSE), pages 107—-119, 1999.
[41] J´ulio C´esar Taveira, Hitalo Oliveira, Fernando Castor, and S´ergio Soares. On
inter-application reuse of exception handling aspects. In Submited to Empirical
Evaluation of Software Composition Techniques (ESCOT 2010), 2010.
[42] J´ulio C´esar Taveira, Cristiane Queiroz, Rˆomulo Lima, Juliana Saraiva, Fer-
nando Castor, S´ergio Soares, H´ıtalo Oliveira, Nathalia Temudo, Emanuel Bar-
reiros, Amanda Ara´ujo, and Jefferson Amorim. Assessing intra-application
75
exception handling reuse with aspects. In XXIII Simp´osio Brasileiro de Engen-
haria de Software - SBES’2009, October 2009.
[43] J´ulio C´esar Taveira, Juliana Saraiva, Fernando Castor, and S´ergio Soares. A
concern-specific metrics collection tool. In Proceedings of AcoM.09 - Workshop
in OOPSLA, October 2009.
[44] AOSD Team. Aspect-Oriented Software Development. http://aosd.net/, Apr
2010.
[45] AspectC Team. AspectC. http://www.cs.ubc.ca/labs/spl/projects/aspectc.html,
Apr 2010.
[46] AspectC++ Team. The Home of AspectC++. http://www.aspectc.org/, Apr
2010.
[47] AspectDNG Team. AspectDNG. http://aspectdng.tigris.org/, Apr 2010.
[48] AspectLua Team. Aspect Oriented Programming in The Lua Language.
http://aspectlua.luaforge.net/, Apr 2010.
[49] AspectWerkz Team. AspectWerkz Plain Java AOP.
http://aspectwerkz.codehaus.org/, Apr 2010.
[50] CaesarJ Team. CaesarJ Project. http://www.caesarj.org/, Apr 2010.
[51] EOS Team. EOS Compiler Tool. http://ect.jate.hu/, Apr 2010.
[52] Java Team. Java API. http://java.sun.com/j2se/1.6.0/docs/api/, Apr 2010.
[53] LogicAJ Team. Logic Aspects for Java. http://roots.iai.uni-
bonn.de/research/logicaj/, Apr 2010.
[54] Seasar Team. S2Container.NET. http://s2container.net.seasar.org/en/index.html,
Apr 2010.
[55] XWeaver Team. XWeaver. http://www.xweaver.org/, Apr 2010.
[56] Marko van Dooren and Eric Steegmans. Combining the robustness of checked
exceptions with the flexibility of unchecked exceptions using anchored exception
declarations. In Proceedings of OOPSLA’05, pages 455––471, 2005.
[57] Westley Weimer and George C. Necula. Finding and preventing run-time error
handling mistakes. In OOPSLA’04, pages 419—-433, October 2004.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
