reuso de tratadores de exce˘c~oes em programas orientados...
TRANSCRIPT
Universidade de Pernambuco
Escola Politecnica de Pernambuco
Departamento de Sistemas e Computacao
Programa de Pos-Graduacao em Engenharia da Computacao
Julio Cesar de Freitas Taveira
Reuso de Tratadores de Excecoes em
Programas Orientados a Aspectos
Recife, abril de 2010
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE DE PERNAMBUCO
DEPARTAMENTO DE SISTEMAS E COMPUTACAO
PROGRAMA DE POS-GRADUACAO EM ENGENHARIA DA COMPUTACAO
JULIO CESAR DE FREITAS TAVEIRA
Reuso de Tratadores de Excecoes em
Programas Orientados a Aspectos
Dissertacao apresentada como requisito parcial
para a obtencao do grau de Mestre em
Engenharia da Computacao
Prof. Dr. Fernando Jose Castor de Lima
Filho
Orientador
Prof. Dr. Sergio Castelo Branco Soares
Co-orientador
Recife, abril de 2010
CIP – CATALOGACAO NA PUBLICACAO
Taveira, Julio Cesar de Freitas
Reuso de Tratadores de Excecoes em Programas Orien-
tados a Aspectos / Julio Cesar de Freitas Taveira. – Recife:
PPGEC da UPE, 2010.
75 f.: il.
Dissertacao (mestrado) – Universidade de Pernambuco.
Programa de Pos-Graduacao em Engenharia da Computacao,
Recife, BR–PE, 2010. Orientador: Fernando Jose Castor de
Lima Filho; Co-orientador: Sergio Castelo Branco Soares.
1. Tratamento de excecoes. 2. Reuso. 3. Aspectos. I. Fer-
nando Jose Castor de Lima Filho, . II. Sergio Castelo Branco
Soares, . III. Tıtulo.
Dedico esse trabalho ao meu irmao, que me viu comecar, mas nao esta presente na
minha conclusao.
Tambem dedico esse trabalho a area de Engenharia de Software e a todos os
desenvolvedores. Lembro-me dos meus primeiros codigos de programacao, ainda
adolescente, usando apenas um livro emprestado, em um 486DX2 com 80MB de
HD, 4MB de memoria e interpretando no QBasic.
Agradecimentos
Sei que nao vou conseguir lembrar de todos para essa dedicatoria, mas vou tentar
lembrar. Vou utilizar uma ordem para me ajudar.
Primeiramente a Deus, pela oportunidade da vida, saude, inteligencia e situacoes
que aconteceram em minha vida, para eu poder chegar ate aqui. Com todos dos
desafios de vida, consegui chegar. As pessoas que estao perto dele agora, que ate
pouco tempo estava junto conosco.
Aos meus pais, Severino Taveira e Ma Betania. Principalmente a minha mae
que me incentivou em tudo e me dando sempre apoio em todas as decisoes 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 necessario.
Aos meus irmaos mais proximos, Caio e Joao Lucas e outros dois mais distantes,
Enzo e Ma Vitoria.
A minha avo, tios, tias e primos. Dando me forca desde o dia da inscricao, as
minhas primas Ble e Georgina (ainda doutoranda em Eng. Eletrica). Aos meus
amigos da vida, que sempre me incentivando e algumas vezes tendo em mim um
exemplo de estudo e competencia. Tambem 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 academico, inicialmente a Universidade de Pernambuco e ao Depar-
tamento de Sistemas e Computacao. Local onde fiz minha graduacao e aqui concluo
meu mestrado academico. A todos os professores com quem tive o prazer de ter
aula. Tanto aos existentes hoje no departamento, quanto aos egressos. Tambem
aos membros participantes do departamento. Alguns nomes nao posso deixar de
citar, como Carlos Alexandre, Marcio Cornelio, Tiago Massoni,..., e Ana Georgina
(Secretaria da Pos).
Agora a quem esta diretamente ligado ao meu mestrado. Em primeiro ao meu
orientador, Fernando Castor. Mesmo antes de fazer minha inscricao, nao o conhecia
mas ja havıamos tido a primeira conversa e vi que seria uma boa o trabalho proposto.
Ao meu co-orientador, Sergio Soares, que roncou muito no SBES’09, mas tambem
nao deixei por menos. Agradeco ao acompanhamento, sugestoes, ajuda e orientacao
dos dois, que me fizeram finalizar o mestrado, de uma forma ate tranquila.
Nao poderia deixar de fora os meus colegas. Primeiro a Robson, que vem me
acompanhando desde a graduacao. No Orkut dele tem foto tanto do listao da
graduacao, quanto ao do mestrado, os nossos nomes. A minha ”parea”de mestrado,
Cristiane Queiroz, que estivemos juntos desde a primeira reuniao, antes das aulas
e ate hoje sempre mantendo contato e um ajudando o outro. Sem duvida uma
amiga que arrumei para sempre. Aos outros colegas como Romulo, 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 nao lembrei ate a versao final, desculpa.
Sumario
LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . vii
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Tratamento de Excecoes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Tratamento de Excecoes em Java . . . . . . . . . . . . . . . . . . . . . 8
2.3 Programacao Orientada a Aspectos e AspectJ . . . . . . . . . . . . . . 11
2.3.1 Conceitos Fundamentais da Orientacao a Aspectos . . . . . . . . . . . . 12
2.3.2 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Tratamento de Excecoes em AspectJ . . . . . . . . . . . . . . . . . . . . 15
2.4 Metricas Estaticas de Codigo . . . . . . . . . . . . . . . . . . . . . . . . 17
3 REUSO INTRA-APPLICACAO . . . . . . . . . . . . . . . . . . . 19
3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Sistemas Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Extracao e Reutilizacao de Tratadores de
Excecoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Extracao do Tratamento de Excecoes . . . . . . . . . . . . . . . . . . . 21
3.3.2 Reuso dos Tratadores de Excecao . . . . . . . . . . . . . . . . . . . . . 25
3.4 Conjunto de Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Conclusoes sobre Reuso Intra-Aplicacao . . . . . . . . . . . . . . . . . . 35
4 REUSO INTER-APPLICACAO . . . . . . . . . . . . . . . . . . . 39
4.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Sistemas Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Extracao e Reuso dos Tratadores de Excecoes . . . . . . . . . . . . . . . 41
4.4 Metodologia de Busca Utilizada . . . . . . . . . . . . . . . . . . . . . . 43
4.4.1 Procurando Oportunidades de Reuso . . . . . . . . . . . . . . . . . . . 44
4.4.2 Empacotamento e Ambiente de Compilacao . . . . . . . . . . . . . . . . 48
4.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5.1 Estrategias de Cada Aplicacao . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 Problemas Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Conclusoes do Reuso Inter-Aplicacao . . . . . . . . . . . . . . . . . . . 55
5 EH-METER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1 Metricas Implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Arquitetura e Modificacoes no Codigo Original . . . . . . . . . . . . . . 60
5.2.2 Novas Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Execucao e Resultados da Ferramenta . . . . . . . . . . . . . . . . . . . 63
5.4 Avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1 Comparando Abordagens de Medicoes . . . . . . . . . . . . . . . . . . . 65
5.5 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 CONCLUSOES E TRABALHOS FUTUROS . . . . . . . . . . . 68
6.1 Publicacoes Resultantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Lista de Abreviaturas e Siglas
B2B Bussines to Bussiness
GUI Interface Grafica com o Usuario (Graphic User Interface)
LOC Linhas de Codigo (Lines Of Code)
POA Programacao Orientada a Aspectos
POO Programacao Orientada a Objetos
XML Linguagem de Marcacao Extensıvel (eXtensible Marckup Language)
Lista de Figuras
Figura 2.1: Exemplo do tratamento de excecoes 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 Excecoes em AspectJ. . . . . . . . . . 16
Figura 3.1: Fluxo das Refatoracoes. . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 3.2: Codigo Original da Classe CheckSelectedFilesAction. . . . . . . . 23
Figura 3.3: Codigo da Classe CheckSelectedFilesAction Refatorada OO. . . . . 23
Figura 3.4: Codigo da Classe ActionExceptionHandler. . . . . . . . . . . . . . 24
Figura 3.5: Codigo da Classe CheckSelectedFilesAction Refatorada AO. . . . . 25
Figura 3.6: Codigo do Aspecto ActionAspectExceptionHandler. . . . . . . . . 25
Figura 3.7: Diagrama de Classes das versoes Ref. OO. . . . . . . . . . . . . . 26
Figura 3.8: Diagrama de Classes das versoes Ref. AO. . . . . . . . . . . . . . 27
Figura 3.9: Exemplo de Reuso de Tratadores de Excecao nas Ver. Ref. OO. . 27
Figura 3.10: Exemplo de Reuso de Tratadores de Excecao na Ver. Ref. AO. . . 28
Figura 3.11: Incrementos nas Metricas de Tamanho. . . . . . . . . . . . . . . . 34
Figura 3.12: Incrementos nas Metricas de Interesses. . . . . . . . . . . . . . . . 34
Figura 4.1: Codigo Original do Reuso Inter-Aplicacao. . . . . . . . . . . . . . 43
Figura 4.2: Aspecto Abstrato no codigo reusavel . . . . . . . . . . . . . . . . . 44
Figura 4.3: Aspecto Concreto que estande do Aspecto Abstrato . . . . . . . . . 44
Figura 4.4: Exemplo da estrategia Lancamento. . . . . . . . . . . . . . . . . . 45
Figura 4.5: Exemplo da estrategia throws. . . . . . . . . . . . . . . . . . . . . 51
Figura 5.1: Hierarquia de Pacotes do EH-Meter. . . . . . . . . . . . . . . . . 61
Figura 5.2: Codigo da Classe Metrics.java . . . . . . . . . . . . . . . . . . . . 62
Figura 5.3: Transicoes entre os interesses. . . . . . . . . . . . . . . . . . . . . 63
Figura 5.4: Exemplo de um arquivo de configuracao para executar o EH-Meter. 64
Figura 5.5: Resultado das Metricas Coletadas. . . . . . . . . . . . . . . . . . 65
Lista de Tabelas
Tabela 2.1: Algumas Linguagens de Programacao e suas Extensoes para POA [44]. 12
Tabela 3.1: Conjunto de Metricas utilizadas . . . . . . . . . . . . . . . . . . . 36
Tabela 3.2: Resultado das Metricas de Tamanho . . . . . . . . . . . . . . . . 37
Tabela 3.3: Resultado das Metricas de Interesse . . . . . . . . . . . . . . . . . 38
Tabela 4.1: Aplicacoes Usadas para reuso Inter-Aplicacoes. . . . . . . . . . . 42
Tabela 4.2: As estrategias de tratamento de excecoes propostas por Cabral e
Marques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tabela 4.3: Mapeamento dos casos que levantam uma nova excecao. . . . . . 47
Tabela 4.4: Quantidade de tratadores para cada estrategia. . . . . . . . . . . 51
Tabela 4.5: Mapeamento de cada tipo de excecao com seu respectivo grupo. . 53
Tabela 5.1: Conjunto de Metricas implementadas no EH-Meter . . . . . . . . 59
Tabela 5.2: Comparativo de coleta de metricas. Os numeros representam o
tempo, em minutos. . . . . . . . . . . . . . . . . . . . . . . . . . 66
Resumo
Tratamento de excecoes e uma tecnica bastante utilizada no desenvolvimento de sis-
temas e diversas linguagens de programacoes modernas ja incluem esse mecanismo
nas suas definicoes. Um dos objetivos principais de um mecanismo de tratamento
de excecoes e separar o codigo responsavel pela atividade normal de um sistema
do codigo de tratamento de erros. Apesar disso, os mecanismos de tratamento de
excecoes das linguagens mais difundidas na pratica propiciam o aparecimento de
codigo de tratamento de excecoes misturado textualmente com o codigo de compor-
tamento normal dos sistemas. Esses mecanismos tambem produzem codigo dupli-
cado, o que dificulta a manutencao e evolucao dos sistemas de software e os torna
mais difıceis de compreender. O interesse do tratamento de excecoes e um interesse
transversal (crosscutting concern) porque esta normalmente misturado com outros
interesses de um sistema e espalhado pelos seus modulos. A Programacao Orientada
a Aspectos tem o objetivo de modularizar o codigo de interesses transversais, sendo
AspectJ uma das linguagens orientadas a aspetos mais difundidas. O trabalho aqui
proposto aborda o reuso de codigo do tratamento de excecoes, modularizando esse
codigo em aspectos AspectJ. Tambem sao discutidas limitacoes de estudos ja rea-
lizados com objetivos similares. Diferente destes, esse trabalho utilizou de varias
aplicacoes com tamanhos relevantes. A reusabilidade do codigo de tratamento de
excecoes foi avaliada de duas formas: a primeira para reuso dentro de uma mesma
aplicacao e a segunda para reuso entre aplicacoes diferentes. Os resultados mos-
tram que a abordagem de reuso de codigo para uma mesma aplicacao e bastante
relevante, pois diminui o numero de tratadores de excecoes, gerando assim melhor
modularizacao e separacao de interesses. Entretanto, reusar codigo em aplicacoes
diferentes e bastante difıcil e com resultados nao tao satisfatorios, para a abordagem
adotada nesse estudo. Outra contribuicao foi o desenvolvimento de uma ferramenta,
para coleta de metricas para um interesse especıfico, o tratamento de excecoes.
Palavras-chave: Tratamento de excecoes, 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
Introducao
O Tratamento de excecoes [15] e uma tecnica bastante utilizada no desenvolvimento
de sistemas de computacao atuais. E comum que uma parte consideravel do codigo
de um sistema seja dedicada a deteccao e ao tratamento de erros [6, 15, 33, 57].
Diversas linguagens de programacao modernas usadas na industria, como Java, C#,
C++ e Ada, incluem mecanismos de tratamento de excecoes. Tais mecanismos
permitem que programas indiquem a ocorrencia de situacoes erroneas, atraves do
lancamento de excecoes, e capturem e tratem tais excecoes, de modo a retornar para
um estado consistente.
No projeto do mecanismo de tratamento de excecoes [38] de uma linguagem de
programacao, diversas questoes precisam ser consideradas [24]. Excecoes represen-
tando erros comuns devem ser nativas da linguagem enquanto o usuario deve poder
criar novos tipos de excecoes. Tambem e importante considerar a maneira como
o fluxo de execucao sera afetado pelo tratamento da excecao. Uma outra questao
de projeto importante diz respeito a como as unidades de codigo responsaveis por
tratar excecoes (tratadores de excecoes) sao associadas a elementos do programa.
Java, por exemplo, permite apenas que tratadores sejam associados a blocos dentro
de um metodo, enquanto Guide [24] torna possıvel associar tratadores a chamadas
de metodos, metodos e classes. Outra consideracao importante e quanto aos tipos
de excecoes. Em algumas linguagens, como C++, as excecoes so podem ser defini-
das pelo usuario. Ja em Java podem ser utilizadas tanto excecoes definidas pelos
usuarios, como excecoes nativas da propria linguagem.
Apesar de toda essa variacao, observa-se que a utilizacao de tratamento de
excecoes na construcao de sistemas reais pode resultar na criacao de varios tra-
tadores com o mesmo codigo e ou com o mesmo comportamento [2], espalhados
pelos modulos do sistema, gerando assim os conhecidos clones de codigo [28] de tra-
tamento de excecoes. A existencia de codigo duplicado em sistemas de software tem
2
impacto em diversos aspectos relativos a qualidade do sistema [35, 26]. Abaixo sao
listadas algumas desvantagens da existencia de codigo duplicado em um sistema:
• Aumento na probabilidade de propagacao de erros;
• Aumento na probabilidade de insercao de novos erros;
• Aumento na probabilidade de um projeto (design) mal definido;
• Aumento na dificuldade e, portanto, nos custos de manutencao e evolucao.
Alguns trabalhos [30, 56, 20] apresentaram novas tecnicas de programacao ten-
tando obter benefıcios adicionais dos mecanismos de tratamento de excecoes exis-
tentes. Apesar disso, a obtencao de um codigo de tratamento de excecoes modular
nao e uma tarefa facil para os desenvolvedores. O maior problema e o grande e
complexo relacionamento entre o codigo de comportamento normal da aplicacao e o
codigo que manipula excecoes, nos sistemas de software. Alem disso, o tratamento
de excecoes e um requisito do projeto (design) de um sistema [24], afetando todos
os seus modulos [30]. Em alguns sistemas, a parte do codigo para tratamento de
excecoes e bastante grande [15, 57], mesmo assim nem todos os casos de tratamento
de excecoes sao faceis de ser entendidos, documentados [15] e testados.
Nos sistema de software, o tratamento de excecoes e um interesse que pode ser
encontrado em diversas partes do codigo [30], normalmente entrelacado ao codigo
relativo a outros interesses. Interesses que tem essas caracterısticas sao conhecidos
como interesses transversais (crosscutting concerns) [27]. Nos anos 90, foi proposta
uma tecnica de desenvolvimento cujo objetivo e tornar possıvel a modularizacao
desses interesses transversais, separando-os dos demais interesses do sistema. Essa
tecnica chama-se Programacao Orientada a Aspectos (POA) [27]. Alguns trabalhos
propoem que o uso de POA ajuda a modularizacao do codigo referente ao tratamento
de excecoes [27, 29, 30, 6].
Varios trabalhos [30, 6, 8, 5, 21, 4] mostram que a modularizacao do tratamento
de excecoes de um programa com aspectos gera alguns benefıcios, tais como se-
paracao de interesses transversais, localizacao da implementacao de tais interesses
e diminuicao no acoplamento. Em todo esses trabalhos, sistemas pre-existentes,
escritos em Java, foram refatorados de modo a extrair todo o seu codigo de trata-
mento de excecoes para aspectos escritos na linguagem AspectJ [29]. A avaliacao da
qualidade das versoes OO e AO de cada sistema se deu pela utilizacao de algumas
metricas estaticas de codigo, genericas.
Lippert e Lopes [30], no trabalho seminal sobre POA e tratamento de excecoes,
realizaram um estudo cujo objetivo era modularizar o tratamento de excecoes de
3
um sistema de medio porte utilizando aspectos escritos em AspectJ, deixando esse
interesse separado do restante do codigo do sistema. Para esse trabalho, foi utilizado
o codigo do framework JWAM 1.4, escrito originalmente na linguagem Java. Os re-
sultados obtidos nesse experimento mostram que houve uma reducao no numero de
linha de codigo relacionado com o tratamento de excecoes. No melhor caso o fator
de reducao foi de 4. Tambem foram verificadas algumas propriedades promovidas
pelo uso de AspectJ, como melhor suporte a diferentes comportamentos de excecoes,
maior tolerancia a mudancas em especificacoes do comportamento de excecoes, 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 adequacao da linguagem AspectJ para modularizacao
do tratamento de excecoes. Nesse estudo foram refatorados quatro sistemas, remo-
vendo o tratamento de excecoes para aspectos. Dos quatro sistemas refatorados, tres
eram orientados a objetos e um era orientado a aspectos. Para comparacao do re-
sultado da refatoracao obtida com o codigo original, foram usadas algumas metricas
estaticas tanto de tamanho de codigo, como numero de linhas de codigo e tamanho
de vocabulario. Alem de tambem levar algumas questoes qualitativas, como aco-
plamento, coesao e sobre reusabilidade. Com os resultados obtidos, foram tiradas
algumas conclusoes sobre os benefıcios da modularizacao de tratamento de excecoes
usando aspectos. Assim como Lippert e Lopes, Castor et al. [6] comprovaram que
o uso de aspectos diminuiu a interferencia entre interesses do sistema. Embora os
valores de algumas metricas, como numeros de operacoes, tenham crescido, isso nao
e um fator negativo, pois os tratadores se tornaram mais simples e nao se misturam
com o codigo normal do sistema.
Resultado importante do estudo de Castor et al. [6] e sobre o reuso de codigo.
Esse estudo menciona que reuso de codigo nao e o principal benefıcio da modula-
rizacao de interesses transversais de sistemas de software, mas uma consequencia
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 cenarios, classificando os casos onde foi possıvel fazer a extracao
dos tratadores de excecoes para aspectos. Para cada um dos itens apontados nos
cruzamentos de informacoes referentes ao codigo a ser refatorado, e dito se o cenario
podera ser aspectizado ou nao, com base nos experimentos realizados nos estudos.
No trabalho realizado por Cacho et al. [4] e apresentado um modelo inovador
para tratar excecoes utilizando aspectos. Diferente de outros trabalhos, esse modelo
proposto faz a abstracao da visao global dos fluxos para tratamento de excecao,
4
sendo necessario apenas observar uma parte do programa. As avaliacoes quanti-
tativa e qualitativa desse novo modelo basearam-se em um estudo de caso utili-
zando uma aplicacao movel real. Em outro trabalho [25] foi apresentado o resultado
de um estudo empırico fazendo uma comparacao dos tradeoffs entre transparencia
(obliviousness [22]) e modularidade. No estudo, os tratadores de excecoes de tres
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 metricas de codigo usadas em estudos previos. Os dois trabalhos citados nesse
paragrafo [4, 25] mostram novas maneiras de aumentar reuso de codigo para trata-
mento de excecoes, utilizando novas construcoes para linguagens de POA. Porem,
eles mostram duas limitacoes: (i) necessidade de novas construcoes, nao se apli-
cando a nenhuma abordagem de POA utilizada atualmente no desenvolvimento; e
(ii) nao conseguem resolver problemas de reuso de sistemas de grande porte, pois
nao mostram como combinacao de tratadores similares poderia ser feita de maneira
automatizada.
Coelho et al. [11] apresentaram um estudo sistematico sobre a propensao a erros
do uso de POA, levando em conta os fluxos de excecoes em sistemas. Esse trabalho
faz a verificacao dos efeitos positivos e negativos da modularizacao do tratamento
de excecoes em aspectos. O estudo foi realizado utilizando tres sistemas de tamanho
medio e pertencentes a diferentes domınios de aplicacao. Para esse estudo foi desen-
volvida uma ferramenta de analise de fluxo de excecoes para auxiliar a avaliacao do
codigo estudado, tambem sendo feitas inspecoes sobre o codigo, nas versoes originais
em Java e com o tratamento de excecoes implementado com aspectos, em AspectJ.
Neste trabalho, varios resultados negativos foram encontrados, investigados, apre-
sentados e catalogados. Os principais foram evidencias de que existem excecoes nao
tratadas, quando ha o tratamento de excecoes estiver dentro de aspectos e excecoes
que sao lancadas pelos aspectos e capturadas por tratadores existentes no codigo
base. Em outro trabalho, Coelho et al. [10] apresentam possıveis cenarios 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 excecoes. Tambem apresenta uma abordagem de reuso, apoiada por uma
ferramenta de analise estatica que proporciona melhorias.
1.1 Motivacao
Na engenharia de software, a busca por reuso vem se tornando cada vez mais
constante. Nas ultimas decadas, muitas tecnicas foram desenvolvidas para apoiar
5
o reuso de software [39]. O uso de codigo especıfico para tratadores de excecoes
e bastante encontrado atualmente. Alguns trabalhos mostram que o numero de
tratadores de excecoes por operacoes, para aplicacoes desenvolvidas em Java EE 5,
varia entre 0,058 e 1,79 [33]. Outro trabalho aponta que entre 1 e 5% do codigo, em
aplicacoes open source, e relativos ao tratamento de excecoes [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 pratica de desenvolvimento
de software, o codigo referente ao tratamento de excecoes esta fortemente acoplado
ao codigo que implementa o comportamento normal do sistema. O codigo duplicado
acaba sendo entao uma consequencia desse relacionamento, ja que se torna difıcil
empregar o mesmo tratador de excecoes em diferentes partes do sistema. Mas codigo
duplicado, como apresentado em alguns trabalhos [28, 35], diminui alguns atributos
de qualidade e influencia negativamente a manutencao e evolucao do codigo, como
tambem a legibilidade. Assim a modularizacao do codigo referente ao tratamento de
excecoes, a fim de obter reuso, visa diminuir os impactos negativos da duplicacao do
codigo de tratamento de excecoes e tenta melhorar a manutenabilidade e legibilidade.
1.2 Objetivos do Trabalho
O problema foco desse trabalho e o codigo de tratamento de excecoes duplicado,
pois gera maior possibilidade de propagacao e insersao de erros, tambem podendo
aumentar o custo e tempo de manutencao desses sistemas. Assim, o objetivo e fazer
um estudo amplo com foco na analise sobre reusabilidade de codigo de tratamento
de excecoes, quando esse interesse estiver modularizado atraves de aspectos AspectJ.
Embora haja alguns estudos que afirmem que AOP promove reuso de tratadores de
excecoes, esses estudos foram aplicados a sistemas tratadores muitos simples [30].
Ha tambem estudos que afirmam que reutilizar aspectos de tratamento de excecoes
nao-triviais e difıcil, mas tais estudos nao avaliaram o impacto de AspectJ no reuso
de tratadores de maneira aprofundada [6]. O ponto inicial do trabalho e abordar as
limitacoes de dois estudos ja descritos [30, 6], buscando reutilizar codigo relativo ao
tratamento de excecoes em sistemas de medio porte e com tratadores de excecoes
mais complexos. Tambem a utilizacao de novas metricas a fim de aferir os impactos
das modificacoes no codigo, modificacoes essas com intencao de possibilitar o reuso.
Para o estudo sao abordadas duas perspectivas: intra e inter-aplicacoes. Na
primeira perspectiva abordada, foi avaliado o quanto de reuso pode ser obtido dentro
6
de uma mesma aplicacao. A avaliacao lanca mao de um conjunto de metricas de
codigo que focam especificamente no interesse de tratamento de excecoes. Ja no
ultimo caso, foram avaliados os fatores que propiciam ou dificultam a reutilizacao de
tratadores de excecoes entre aplicacoes diferentes. Com isso sao propostas solucoes
para aumentar o grau de reuso que pode ser obtido com o uso de aspectos para
modularizacao do interesse de tratamento de excecoes. Tambem sao levantados
alguns problemas advindos da tentativa do reuso do codigo de tratadores de excecoes.
Pela necessidade de fazer a coleta de metricas em varias versoes de varios sis-
temas diferentes, foi desenvolvida uma ferramenta para coletar essas metricas dese-
jadas. Essa ferramenta implementa metricas especıficas focadas no tratamento de
excecoes. Tais metricas medem tanto tamanho de codigo, como linhas de codigo
(LOC) e numero de blocos try, como tambem implementa novas metricas relativas
a interesses, definidas em trabalhos recentes como DOF [18] e CDLOC [37]. Essa
ultima nao se tem conhecimento de ferramentas com essa metrica implementada.
1.3 Organizacao do Trabalho
Esse documento esta organizado em seis capıtulos. No Capıtulo 2 sao apresentados
os principais conceitos de tratamento de excecoes, AspectJ e metricas estaticas de
codigo. No Capıtulo 3 e descrito o trabalho realizado referente ao reuso intra-
applicacao. O estudo que foi realizado com o intuito de avaliar o uso de AspectJ
para reutilizar tratadores de excecoes entre aplicacoes 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 sao
mostradas as conclusoes do trabalho.
7
Capıtulo 2
Background
Esse capıtulo faz uma contextualizacao de assuntos abordados nessa dissertacao. A
Secao 2.1 aborda o tratamento de excecoes, explanando conceitos relacionados a
captura e o tratamento de excecoes e a recuperacao do sistema. A implementacao
do tratamento de excecoes na linguagem de programacao Java e mostrada na Secao
2.2. A Secao 2.3 apresenta os conceitos fundamentais da Programacao Orientada
a Aspectos, alem de introduzir a linguagem orientada a aspectos empregada neste
trabalho, AspectJ. Esta secao tambem mostra como tratamento de excecoes pode
ser implementado usando AspectJ. A Secao 2.4 fornece uma breve introducao a
metricas estaticas de codigo, bem como algumas ferramentas e algumas metricas
encontradas na literatura.
2.1 Tratamento de Excecoes
Varios sistemas possuem modo de deteccao de erros, tanto implementados em hard-
ware quanto implementados em software. Um exemplo das implementacoes em hard-
ware sao os sistemas de calculo, que possuem verificacao de overflow, em operacoes
de ponto flutuantes. As implementacoes em software sao as mais comuns, pelo
numero de abstracoes possıveis dentro do sitema. Muitas vezes as linguagens pos-
suem estruturas de transferencia de informacoes, com os sistemas operacionais, para
tratar algumas situacoes de erros, como problemas de impressao e falta de memoria.
Outras vezes, o controle da aplicacao tambem pode ser transferido para o proprio
sistema operacional, podendo ser devolvido em seguida. Outros erros podem ser de-
tectados previamente, no momento da compilacao do sistema. Mas existem alguns
erros que so podem aparecer no momento da execucao do sistema.
Uma excecao e um evento incomum, de erro ou nao, 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
excecao (exception handling) [38]. O codigo referente a esse processamento e
chamado de tratador de excecao (exception handler). Assim, apos o erro em
determinada parte de codigo, uma excecao e um tratador de excecoes geralmente
sao 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 nao da suporte ao tratamento de excecoes, algu-
mas vezes o desenvolvedor pode controlar situacoes anormais atraves dos mecanis-
mos existentes na linguagem. Um exemplo disso e a linguagem C, onde costuma-se
usar codigos de retorno para indicar sucesso ou falha na execucao de uma funcao.
Uma outra abordagem e passagem de rotulo (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 excecoes
como subprogramas separados, passados como parametros a unidade chamada.
Outra abordagem e manipular a excecao na mesma unidade onde a excecao foi
detectada. Assim, o tratador e um segmento do codigo da propria unidade. Essa
e definida por alguns como uma melhor abordagem [24], pois consegue realmente
descrever onde cada tratador e aplicado, e o codigo fica com uma melhor legibili-
dade. Porem, o codigo de comportamento normal do sistema se mistura com o do
tratamento de excecoes. Nesse caso uma solucao de separacao mais clara do codigo
relativo tratamento de excecao com o uso de blocos distintos para comportamento
normal e para o tratamento de excecao. Daı algumas linguagens como Java, C++ e
C# possuem as divisoes dos codigos com diretivas try-catch-finally. Tambem e
possıvel levantar a excecao a uma unidade antecessora de onde a excecao foi levan-
tada, como o metodo ou funcao que chamou o local onde a excecao foi levantada.
Nesse caso um metodo ou funcao, a depender da linguagem de programacao, le-
vanta a excecao para o metodo ou funcao que a chamou. Exemplo disso e a clausula
throws de Java. Com isso torna possıvel tratar e reusar codigo tratador de um
mesmo tipo de excecao,
2.2 Tratamento de Excecoes em Java
Em Java, todas as excecoes sao objetos que herdam da classe Throwable [52]. Os
tipos que herdam diretamente de Throwable, e definidos pelo sistema, sao Error
e Exception. As excecoes que herdam de Error e suas descendentes sao gera-
9
das pela maquina virtual e jamais dever ser geradas pelo programa do usuario e
nem devem ser tratadas. Exception e a classe base para as excecoes existentes
que podem ser levantadas e tratadas pelos programas escritos em Java. Toda
excecao subtipo de Exception deve ser tratada pelo programa, exceto subtipos
de RuntimeException para os quais o tratamento nao e obrigatorio. As excecoes
do tipo RuntimeException indicam erros de programacao e sao levantadas quando
ocorrem erros como variaveis locais ou atributos apontando para um objeto nulo,
tentativas de acessar uma posicao invalida de um array, entre outros. Excecoes
bastante comuns nos sistemas sao as que herdam de IOException, como o proprio
nome diz, e relativa a operacoes de entrada e saıda de dados, como arquivos em
disco e conexoes de rede. Cada sistema pode possuir seus proprios tipos de excecoes,
convencionalmente as classes desses novos tipos devem herdar de Exception ou de
algum de seus subtipos.
Dois pontos sao importantes no sistema de tipos da linguagem Java. O primeiro e
da obrigatoriedade da excecao ter codigo tratador ou nao. Assim as excecoes podem
ser divididas em excecoes checadas e excecoes nao checadas. As excecoes
do tipo Exception devem obrigatoriamente possuir o codigo tratador da excecao,
sendo verificado a existencia desse codigo no momento da compilacao. Ja excecoes
do tipo RuntimeException nao sao obrigadas a possuırem o codigo tratador de
excecao dentro do metodo ou levantar para o metodo que as chamaram, portanto,
sao as excecoes que nao sao checadas no momento da compilacao. O outro ponto
importante diz respeito a tratar uma excecao ou levanta-la para que seja tratada
pelo metodo que chamou o metodo onde ela foi levantada. Assim, um metodo que
tem codigo que pode levantar uma excecao nao tem obrigacao de trata-la, podendo
tambem levantar para o metodo que o chamou. Desta forma, a assinatura do metodo
deve conter a diretiva throws junto com o tipo da excecao a ser propagada.
Em Java (assim como em C++ e C#), um bloco try define um contexto de
tratamento de excecoes, uma regiao de um programa onde as mesmas excecoes sao
sempre tratadas da mesma forma. Associados a um bloco try, podem haver zero ou
mais tratadores de excecoes, definidos por blocos catch. Cada bloco catch e um tra-
tador para uma excecao no contexto ao qual esta associado. Uma excecao levantada
dentro de um escopo de tratamento de excecoes que nao seja tratada por nenhum
de seus tratadores e propagada para o escopo mais externo, onde e levantada. Esse
processo acontece ate que a excecao seja tratada ou nao haja mais escopos de trata-
mento de excecoes, o que significa que a aplicacao falhou (em terminologia de Java,
diz-se que a excecao nao foi capturada). O trecho de codigo mostrado na Figura
2.1 ha um exemplo do tratamento de excecoes. Na linha 4 podem ser levantados
10
dois tipos de excecao. O primeiro tipo e NullPointerException, caso o atributo
filename nao tenha sido inicializado com algum valor nao-nulo. Essa excecao sera
tratada no bloco catch da linha 7. Outro tipo de excecao que pode ser levantada na
linha 4 e IOException, caso nao seja possıvel abrir o arquivo com nome filename.
Essa excecao sera tratada pelo bloco do catch da linha 9. Por ultimo, caso a linha 5
levante a excecao CloneNotSupportedException, esta sera propagada para o bloco
try mais externo, onde sera capturada pelo bloco catch referente ao tipo correto
da excecao, na linha 13. Caso a excecao CloneNotSupportedException nao seja
lancada, a execucao da chamada ao metodo showScreen (linha 12) vai ocorrer. Mas
caso a excecao CloneNotSupportedException seja levantada nao ocorre a chamada
ao metodo. Por outro lado, as excecoes NullPointerException e IOException que
podem ser levantadas nas linhas 4 e 5 nao mudam a possibilidade da chamada ao
metodo showScreen, pois o escopo onde essas excecoes estao sendo tratadas e um
escopo diferente do escopo de execucao do metodo showScreen.
1 try{
2 try{
3 ...
4 FileReader fr = new FileReader(filename);
5 FileReader fr2 = fr.clone ();
6 ...
7 } catch (NullPointerException npe) {
8 System.out.println("Null Pointer Exception handling ...");
9 } catch (IOException npe) {
10 System.out.println("I/O Exception handling ...");
11 }
12 showScreen ();
13 } catch (CloneNotSupportedException npe) {
14 System.out.println("Clone Not Supported Exception handling ...");
15 } finally {
16 System.out.println("Finally block code executing ...");
17 }
Figura 2.1: Exemplo do tratamento de excecoes em Java.
Quando uma linha de codigo levanta uma excecao, automaticamente a infra-
estrutura de tempo de execucao de Java procura o tratador daquele tipo de excecao
no escopo mais proximo, ou a aplicacao encerra, caso nenhum tratador seja encon-
trado. Quando encontra o codigo tratador da excecao, comeca a sua execucao ate
o final do codigo contido no bloco, e quando acaba a execucao o fluxo volta para
depois do ultimo catch vinculados ao bloco try que levantou a excecao. Alem disso,
a linguagem Java tambem possui a diretiva finally, que possui um bloco de codigo
11
que sempre e executado, caso uma excecao seja levantada ou nao ou mesmo que nao
haja um tratador especıfico para uma excecao levantada. O codigo apresentado na
Figura 2.1 tambem apresenta um bloco de codigo com a diretiva finally associado.
2.3 Programacao Orientada a Aspectos e AspectJ
A separacao de interesses e um dos principais fundamentos do projeto (design) e
da implementacao no desenvolvimento de software [17]. Esse princıpio determina
que a organizacao do software deve ser tal que cada elemento (classe, metodo, 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 separacao 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 nocao
funcional que precisa abranger todo o sistema. Assim, os interesses sao mais do que
simples elementos funcionais e a definicao mais geral e tao vaga que e praticamente
inutil [39]. Muitos dos interesses possuem implementacao que afetam varios modulos
dos sitemas [29]. Esses interesses sao chamados de interesses tranversais. Usando os
metodos de programacoes da atualidade, os interesses transversais tendem a se es-
palhar por diversos modulos do sistema, podendo deixar o sistema com difıcil projeto
(design), entendimento e desenvolvimento. A Programacao 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 laboratorios da Xerox (Xerox PARC). O objetivo
dessa nova abordagem de desenvolvimento e tornar possıvel as linguagens de pro-
gramacao expressar de forma ideal as caracterısticas ortogonais ou transversais do
comportamento do programa.
POA estende outras linguagens e tecnicas de programacao, como linguagens
orientadas a objetos e programacao estruturada, propondo nao apenas uma de-
composicao funcional, mas tambem sistemica do problema. Assim, POA permite a
separacao de implementacao de interesses transversais do sistema, sendo os aspectos
a abstracao para separacao dos interesses transversais, enquanto os demais interesses
(nao transversais) utilizam os recursos da propria linguagem estendida pela lingua-
gem de POA. A orientacao 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 logico. Na Tabela 2.1 sao apresentadas algumas
linguagens de programacao e extensoes dessas linguagens para POA [44].
Linguagem Extensao 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 Programacao e suas Extensoes para POA [44].
2.3.1 Conceitos Fundamentais da Orientacao a Aspectos
A orientacao a aspectos possui quatro conceitos fundamentais. Esses conceitos sao:
• 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 codigo referentes aos
componentes transversais em uma unidade no sistema, e que, sem os aspec-
tos, estariam implementados de forma espalhada e entrelacada com outros
interesses.
• Pontos de juncao (join points). Os pontos de juncao sao locais bem
definidos na execucao de um programa onde a execucao de um interesse trans-
versal e de um nao-transversal se sobrepoem. Exemplos de pontos de juncao
incluem chamadas a metodos ou ocorrencias de excecoes, entre outros. Pontos
de juncao tem contexto associado, como, por exemplo, os argumentos de um
metodo.
• Pontos de corte (pointcuts). Pontos de corte sao elementos de uma lingua-
gem de programacao orientada a aspectos usados para selecionar um conjunto
de pontos de juncao. A forma como pontos de corte sao especificados, bem
como seu poder expressivo, dependem do modelo de pontos de juncao da lin-
guagem orientada a aspectos empregada.
• Advice. Os advice sao unidades de implementacao definidas por um aspecto e
executados em pontos bem definidos do programa principal (pontos de juncao).
13
O advice contem o ponto de corte que captura o contexto de execucao de codigo
e o codigo a ser executado, caso o ponto de juncao venha ocorrer. Um advice
tem comportamento semelhante a um metodo, mas sua funcao e declarar o
codigo que deve ser executado a cada ponto de juncao em um ponto de corte.
2.3.2 AspectJ
AspectJ e uma extensao orientada a aspectos da linguagem Java. Assim, e necessaria
uma preocupacao com a compatibilidade de quatro itens importantes:
• Compatibilidade Total: Todo programa Java valido e necessariamente
tambem um programa AspectJ valido.
• Compatibilidade de Plataforma: Todo programa AspectJ pode ser exe-
cutado em uma maquina 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 documentacao e ferramentas de projeto.
• Compatibilidade para o Programador: Ao programar com AspectJ, o
programador deve sentir-se como estivesse utilizando uma extensao da lingua-
gem Java.
AspectJ implementa dois tipos de composicao: dinamica e estatica. A com-
binacao dinamica adiciona novos comportamentos a execucao de um programa, au-
mentando ou substituindo partes de seu fluxo de execucao. Ja a composicao estatica
consiste na combinacao modificacao da estrutura de um programa, atraves da criacao
de novos elementos (classes, interfaces e aspectos) ou de novos relacionamentos entre
esses elementos. Esses interesses nao alteram diretamente o comportamento de um
sistema, mas dao suporte para que este seja alterado pela implementacao de inter-
esses introduzidos atraves de composicao dinamica.
A linguagem AspectJ implementa os quatro conceitos basicos de uma linguagem
orientada a aspectos. Esses conceitos, com descrito anteriormente, sao os Aspectos,
Pontos de Juncao, 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
alcancar os pontos de corte definidos pelo pointcuts. Um pointcut e composto por
um nome, que e sua identificacao, junto com pontos de juncao associados e tambem
pode conter outros pointcuts. A composicao de pontos de juncao e pointcuts pode
14
1 public class ClassA{
2 // Metodo 1
3 public void method1 (){
4 // ... corpo do metodo 1
5 }
6 // Metodo 2
7 public void method2 (){
8 // ... corpo do metodo 2
9 }
10 // Metodo 3
11 public String method3 (){
12 // ... corpo do metodo 2
13 }
14 }
Figura 2.2: Classe Java afetada por um Aspecto.
ser dada junto com os operadores && (e), —— (ou) e !(nao). Ja um advice e a
implementacao de codigo que sera executada quando um determinado fluxo for exe-
cutado. O advice pode executar antes da execucao do fluxo indicada no ponto de
juncao (before), depois da execucao (after) ou ate mesmo pegar todo o controle
de execucao (around). Esse ultimo, possui a diretiva proceed() que devolve o fluxo
de excucao ao local interceptado no codigo, recebendo novamente o fluxo quando a
execucao do local afetado termina.
Nos trechos de codigo mostrados nas Figuras 2.2 e 2.3 sao apresentados uma
classe Java e um aspecto AspectJ que afeta essa classe. O trecho de codigo da
Figura 2.2 apresenta uma classe Java com tres metodos. O trecho de codigo da Fi-
gura 2.3 apresenta tres pointcut’s que interceptam o codigo da classe A. O primeiro
pointcut, linha 3, captura a execucao do metodo method1(). O segundo pointcut,
linhas 5 e 6, captura chamadas ao metodo method3(), mas somente quando aconte-
cem dentro do metodo method2(). O ultimo pointcut, linha 8, captura a execucao
do metodo method3(). O advice associado ao pointcut pcMethod1() e mostrado
nas linhas 10-14. Esse advice executa antes da execucao de todo o metodo, pois o
tipo modificador do advice e around.
A diretiva proceed(), como mostrado na linha 11, passa a execucao do advice do
aspecto para o metodo interceptado no ponto de juncao associado. Apos a execucao
do metodo que tem o ponto de juncao associado, ou caso o metodo levante alguma
excecao, o fluxo de execucao 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 // Pointcut 1
3 pointcut pcMethod1 (): execution (* ClassA.method1 ());
4 // Pointcut 2
5 pointcut pcMethod2 (): call (* ClassA.method3 ())
6 && withincode (* ClassA.method2 ());
7 // Pointcut 3
8 pointcut pcMethod3 (): call (* ClassA.method3 ());
9 // Advice 1
10 void around (): pcMethod1 (){
11 proceed ();
12 // ... Corpo do advice que implementa o pointcut pcMethod1 ()
13 }
14 // Advice 2
15 before (): pcMethod2 (){
16 // ... Corpo do advice que implementa o pointcut pcMethod2 ()
17 }
18 // Advice 3
19 after(): pcMethod3 (){
20 // ... Corpo do advice que implementa o pointcut pcMethod3 ()
21 }
22 }
Figura 2.3: Aspecto que afeta a ClasseA.
O primeiro executa antes do ponto de juncao do pointcut vinculado e o segundo
depois. O advice after pode executar depois da execucao com sucesso do pointcut
vinculado after returning; depois da execucao do pointcut vinculado quando
uma excecao for levantada after throwing, passando a execucao para o advice
sempre que for levantada uma excecao e ela nao for tratada no codigo; ou ainda
independente de se a execucao do pointcut vinculado com sucesso ou nao.
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 Excecoes em AspectJ
Assim como programas escritos na linguagem Java, AspectJ tambem disponibiliza
tratamento de excecoes, 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 excecoes e um interesse transversal, o codigo contido do
aspecto pode substituir o codigo tratador de excecoes nos programas Java, deixando
as classes Java somente com a responsabilidade de implementar o comportamento
normal (sem excecoes) da aplicacao.
Existem dois modos de capturar uma excecao advinda da execucao de codigo
Java. A primeira e utilizando o advice do tipo after throwing. Esse tipo de advice
comeca sua execucao quando o ponto de juncao associado levanta uma excecao e
16
1 public aspect AspectB {
2 // Pointcut 1
3 pointcut pcMethodA (): call (* ClassB.methodB ())
4 && withincode (* ClassB.methodA ());
5 // Pointcut 2
6 pointcut pcMethodB (): execution (* ClassB.methodB ());
7 // Advice 1
8 void around (): pcMethodB () {
9 try{
10 proceed ();
11 }catch (Exception e){
12 e.printStackTrace ();
13 }
14 }
15 // Advice 2
16 after() throwing(Exception e):pcMethodA () {
17 e.printStackTrace ();
18 }
19 }
Figura 2.4: Exemplo de Tratamento de Excecoes em AspectJ.
nao a trata. Assim, toda vez que o codigo Java lanca uma excecao e nao trata, o
fluxo de execucao 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 juncao associado
e executado quando o comando proceed() e chamado. Caso uma excecao ocorra,
ela e levantada no contexto de tratamento de excecoes 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
excecoes em AspectJ. O primeiro modo de captura e tratamento de excecoes e apre-
sentado com o pointcut na linha 3 e o advice associado, nas linhas 16-18. Para
esse caso, o fluxo de execucao so e transferido para o advice caso seja levantada uma
excecao do tipo Exception. Ja no segundo caso, onde o pointcut e apresentado na
linha 6 e o advice nas linhas 8-14, o fluxo de execucao passa primeiro para o advice.
Apos a chamada do proceed() e que o controle passa para o metodo que vai ser
executado (o ponto de juncao selecionado). Caso uma excecao do tipo Exception
seja levantada em methodB() e este nao a trate, a execucao volta para o advice e
e tratada dentro do bloco catch (linhas 11-13).
17
2.4 Metricas Estaticas de Codigo
Metrica estatica de codigo e um modo de medir alguma propriedade de uma parte
de um codigo, ou de sua especificacao. Diferente de alguns outros tipos de metricas
como, por exemplo, tempo de execucao e uso de memoria, metricas estaticas de
codigo nao necessitam da execucao do codigo. Ao inves da execucao, e feita uma
analise estatica do codigo, que e utilizada para auxiliar na analise de atributos de
qualidade do codigo de um sistema. Assim, e possıvel inferir alguns valores referentes
a qualidade do codigo, comparando com algum valor previamente definido. Tambem
e possıvel prever algum erro que ocorreria durante a execucao do codigo. Existe uma
vasta gama de atributos que podem ser analisados usando-se metricas estaticas de
codigo como: usabilidade, seguranca, corretude do codigo, complexidade, facilidade
de compreensao, entre muitas outras.
Grandes empresas, como Hewlett-Packard, AT&T, e Nokia introduziram pro-
gramas de metricas e estao usando-as para coletar principalmente defeitos em seus
programas [39]. Muitas empresas ainda nao utilizam metricas de codigo, porem.
Geralmente essas empresas nao 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 manutencao, legibilidade e outros, sao refe-
rentes a atributos externos, que estao ligados a como os desenvolvedores e usuarios
veem o sistema de software. Os atributos que podem ser medidos diretamente sao
os atributos internos dos sistemas de software, como tamanho, estrutura do codigo
e caracterısticas que podem ser obtidas de maneira direta a partir do codigo. Ideal-
mente, deve haver um relacionamento claro e validade entre os atributos internos e
externos do codigo [32].
Abaixo sao descritas algumas das metricas estaticas de codigo mais comuns e
outras novas relativas a separacao de interesses:
• Tamanho do Codigo: e o tamanho do sistema todo. Geralmente, quanto
maior o programa, mais difıcil de entende-lo e modifica-lo e mais propıcio a
erros. Essa relacao nao e universal, porem.
• Complexidade ciclomatica [31]: e uma metrica muito popular originaria
do paradigma procedimental ou estruturado. Indica o numero de caminhos
que podem ser seguidos dentro de um procedimento: numero de comandos
if/else, switches, ciclos. Esta metrica, adaptada ao paradigma OO, tanto
pode ser utilizada para metodos quanto para classes, somando a complexidade
ciclomatica dos seus metodos.
18
• Profundidade de aninhamento [9]: e a medida de aninhamento entre blo-
cos de codigo. Pode ser dada por blocos condicionais, dentro de blocos de lacos,
blocos try, etc. Essa metrica ajuda a determinar o quao complexa e a com-
putacao realizada por determinado trecho de codigo, tanto do ponto de vista
de consumo de recursos computacionais quanto de facilidade de compreensao.
• Degree of Focus [18]: verifica o quanto as linhas de codigo de um deter-
minado componente estao direcionadas a um interesse especıfico, podendo o
codigo ser totalmente focado ou totalmente desfocado.
• Concern Diffusion of Components [24]: verifica a quantidade de compo-
nentes primarios que possui codigo que implementa o interesse medido.
19
Capıtulo 3
Reuso Intra-Applicacao
Esse capıtulo aborda o reuso de codigo para tratamento de excecoes, dentro do
contexto de uma mesma aplicacao, ou seja, reuso intra-aplicacao. Para ava-
liar a possibilidade de se reusar codigo de tratamento de excecoes dentro de uma
aplicacao usando programacao orientada a aspectos (POA), foi feito um estudo
utilizando algumas aplicacoes do mundo real pertencentes a diferentes domınios.
Os resultados desse estudo apontam que e possıvel reusar codigo de tratamento de
excecoes dentro de uma mesma aplicacao, como tambem a confirmacao da separacao
do interesse tratamento de excecoes, em relacao ao comportamento normal do sis-
tema. Esse estudo foi publicado no XXIII Simposio Brasileiro de Engenharia de
Software(SBES’09) [42].
Nas proximas secoes o estudo proposto e descrito em detalhes. A Secao 3.1 mos-
tra a metodologia do estudo. Na Secao 3.2 sao apresentados os sistemas utilizados
no estudo. Na Secao 3.4 apresenta o conjunto de metricas utilizadas nesse estudo
para analisar o codigo e fazer um comparativo numerico entre as versoes dos siste-
mas utilizadas. As refatoracoes para se estruturar codigo de tratamento de excecoes
a fim de reusar, incluindo uma explicacao sobre como o tratamento de excecoes foi
reusado, e apresentadas na Secao 3.3. Por ultimo sao mostrados os resultados (Secao
3.5) do estudo e as conclusoes (Secao 3.6) obtidas.
3.1 Metodologia
Esse trabalho aborda as limitacoes de estudos anteriores [30, 6], apresentando um
novo estudo com o objetivo de avaliar se a utilizacao de aspectos para modulari-
zar tratadores de excecoes possa promover reuso de codigo relativo a esse interesse.
Foram comparadas duas alternativas para modularizar o tratamento de excecoes,
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 excecoes
em novas classes Java e uma segunda abordagem com os tratadores de excecoes den-
tro de aspectos, na linguagem AspectJ. Para as duas ultimas abordagens, o codigo
foi completamente analisado e revisado a fim de identificar ao maximo oportuni-
dades de reuso e combinacao de tratadores de excecoes. No estudo foram verificadas
situacoes em que POA cria oportunidades de reuso contrapondo com POO e vice-
versa. Foram tambem analisadas construcoes de linguagens que influenciaram essas
oportunidades de reuso, ou limitacoes que influenciaram o nao reuso. A avaliacao
foi feita com utilizacao de metricas especıficas para avaliar o codigo de tratamento
de excecao, tanto ao reuso quanto a modularizacao, exceto apenas em uma metrica
que e bastante generica.
Os tres sistemas utilizados no estudo e apresentados na Secao 3.2 foram imple-
mentados originalmente na linguagem Java. As refatoracoes necessarias no codigo
desses sistemas foram feitas por 8 pessoas, divididas em quatro grupos de duas pes-
soas e fazendo programacao em pares, a fim de garantir uma melhor qualidade na
refatoracao. Alem disso, os grupos eram alternados frequentemente, a fim de se
evitar vıcios em determinada atividade e produzindo uma melhor difusao de conhe-
cimento entres os membros da equipe.
E importante salientar as principais diferencas entre esse estudo e os estudos
anteriores que abordaram a utilizacao de POA para combinar tratadores de excecao.
Em primeiro lugar, foram utilizados sistemas de reais de tamanho medio, enquanto
o estudo de Lippert e Lopes [30] empregou uma infraestrutura com tratadores de
excecoes muito simples. O segundo e que diferentemente do trabalho de Castor
Filho et al. [6], esse trabalho empregou desenvolvedores em pares na tentativa de
reutilizacao sistematica de tratadores de excecao, tanto quanto possıvel. Alem disso
os pares foram alternados frequentemente e os pares revisaram o trabalho de outros,
a fim de oportunidades de reuso nao serem perdidas.
3.2 Sistemas Utilizados
O estudo abordando o reuso intra-aplicacao focou em tres aplicacoes Java. Essas
aplicacoes sao relevantes para o estudo por diversas razoes. Primeiro, sao sistemas
reais e desenvolvidas de forma independente na industria. Segundo, porque cada
um desses sistemas possui pelo menos 15.000 LOC e pelo menos 1% dessas linhas de
codigos sao relativas ao tratamento de excecoes. Terceiro, porque as tres aplicacoes
possuem domınio e plataforma diferentes e foram escritas em Java. Este ultimo
fator e importante porque as principais implementacoes de POA sao extensoes de
21
Java. Por fim, as aplicacoes possuem diversos tratadores de excecoes nao-triviais.
A primeira aplicacao e o Checkstyle Plugin1, um plugin para a plataforma
Eclipse2 que verifica estilo de codificacao de programas escritos em Java. A versao
original da aplicacao possui 19.197 LOC (linhas compilaveis, excluindo linhas em
branco e comentarios) e mais de 290 classes e interfaces. A segunda aplicacao, a
Java PetStore3, e um demo para a plataforma Java Enterprise Edition (Java EE),
uma representacao de solucoes Java para aplicacoes B2B e similares. Essa aplicacao
implementa varias tecnologias disponıveis na plataforma Java EE. A versao original
da Java PetStore possui aproximadamente 17.500 LOC e 330 classes e interfaces. A
terceira aplicacao e o JHotDraw4, um framework de GUI Java para graficos tecnicos
e estruturados. A versao original da aplicacao possui aproximadamente 23.000 LOC
e mais de 400 classes e interfaces.
3.3 Extracao e Reutilizacao de Tratadores de
Excecoes
Para avaliar os benefıcios da utilizacao de POA no tratamento de excecoes, uma
nova abordagem foi utilizada, consistindo na a extracao dos tratadores de excecoes e
reuso para novas classes Java, responsaveis por implementar somente o tratamento
de excecoes. Assim, pode-se obter duas versoes: (i) versao com o tratamento de
excecoes em novas classes Java e (ii) versao com o tratamento de excecoes dentro de
aspectos AspectJ. A ideia de extrair tratadores para novas classes Java e motivada
pela intencao de reutilizar tratadores tanto quanto possıvel, tanto em Java quanto
em AspectJ. As refatoracoes foram feitas em duas etapas. A primeira diz respeito
a extracao dos tratadores de excecoes 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
versao de extracoes e etapas utilizadas. Nas secoes subsequentes sao descritos os
procedimentos realizados para a extracao do tratamento de excecao (Secao 3.3.1) e
para reusar esses tratadores (Secao 3.3.2).
3.3.1 Extracao do Tratamento de Excecoes
Como descrito na Secao 3.3, esse estudo comparou tres versoes de cada sistema alvo:
(i) uma versao original, implementada em Java; (ii) uma versao refatorada OO,
1http://eclipse-cs.sourceforge.net/2http://www.eclipse.org/3http://java.sun.com/developer/releases/petstore/4http://www.jhotdraw.org/
22
Figura 3.1: Fluxo das Refatoracoes.
tambem implementada em Java; e (iii) uma versao refatorada AO, implementada
em AspectJ. As tres versoes possuem as mesmas funcionalidades. A diferenca e
que, nas duas ultimas versoes, os tratadores de excecoes foram movidos para novas
classes e novos aspectos, respectivamente.
Foi considerado codigo de tratamento de excecoes todo o codigo que so existe
para prover uma solucao para um erro (excecao) e que poderia ser removido, caso
tratar tal erro nao fosse mais necessario. Essa definicao esta de acordo com as ideias
apresentadas por Eaddy et al. [18]. A definicao inclui os blocos catch e finally,
junto com a linha em que o blocos try e declarado (mas nao o codigo interno a
ele, que pertence a atividade normal da aplicacao). A clausula throws, bem como
o comando throw nao sao considerados pertencentes ao interesse de tratamento de
excecoes. E importante enfatizar que, em cada versao refatorada OO, o codigo de
captura de excecoes (blocos try-catch-finally) nao pode ser extraıdo para as
novas classes, diferentemente da versao refatorada AO, por limitacao tecnologica.
Para essas versoes, somente o codigo interno aos blocos catch e finally foi movido
para as novas classes, com cada bloco catch ou finally resultando na criacao de
um novo metodo nessas classes.
O primeiro passo para extracao do codigo foi mover todos os tratadores, quando
possıvel, das classes regulares Java para dentro das classes que somente se referem
ao tratamento de excecoes. Uma classe foi criada para cada pacote dos sistemas
que possui algum tratamento de excecao. Somente o conteudo interno dos blocos
23
catch e finally foi movido para dentro de novos metodos e dentro desses blocos
foram adicionadas chamadas ao novo metodo criado. Em alguns casos, foi necessario
adicionar parametros aos metodos tratadores de excecoes criados, a fim de enviar
algumas informacoes necessarias ao tratamento. O trecho de codigo na Figura 3.2
apresenta um exemplo de codigo Java que foi extraıdo. O trecho de codigo na Figura
3.3 apresenta o resultado de se extrair o codigo de tratamento de excecoes, incluindo
uma chamada a um novo metodo da nova classe que foi criada (apresentada no trecho
de codigo na Figura 3.4). Se um bloco try ou catch escrever em algum atributo
de tipo primitivo privado, variavel local, ou parametro do metodo, essa refatoracao
nao e possıvel pois esses elementos nao sao acessıveis aos novos metodos que tratam
as excecoes. Essa limitacao e por conta de que uma alteracao em uma variavel pode
nao refletir na parte original.
1 public class CheckSelectedFilesAction {
2 ... public void run(IAction action) {
3 ... try{
4 addFileResources(mSelection.toList (), filesToCheck);
5 } catch () {
6 CheckstyleLog.errorDialog(mPart.getSite ().getShell (), e, true);
7 // one or more lines
8 }...
9 }...
10 }
Figura 3.2: Codigo Original da Classe CheckSelectedFilesAction.
1 public class CheckSelectedFilesAction {
2 ActionHandler actionH = new ActionHandler ();
3 ... public void run(IAction action) {
4 ... try{
5 addFileResources(mSelection.toList (), filesToCheck);
6 } catch () {
7 actionH.errorDialogCheckstyleLog(
8 mPart.getSite ().getShell (),e, true);
9 } ...
10 } ...
11 }
Figura 3.3: Codigo da Classe CheckSelectedFilesAction Refatorada OO.
24
1 public class ActionExceptionHandler {
2 ... public void errorDialogCheckstyleLog(Shell shell , Exception e,
3 boolean b) {
4 CheckstyleLog.errorDialog(shell , e, b);
5 }...
6 }
Figura 3.4: Codigo da Classe ActionExceptionHandler.
O segundo passo da extracao consistiu em mover os tratadores de excecoes para
dentro dos aspectos, a partir da versao original de cada sistema utilizado. Para cada
pacote existente em cada sistema, foi criado um novo aspecto para ser responsavel
pelo tratamento de excecoes. Para uniformizar o trabalho, foram utilizados somente
advice do tipo around para os novos tratadores de excecoes, uma vez que eles tem
poder suficiente para implementar uma variedade de estrategias de tratamento de
excecoes [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
codigo foram movidos para o mesmo advice. Adicionalmente, os blocos finally
foram movidos para um outro advice, a fim de separar o tratamento de excecoes
(blocos catch) das acoes de limpeza associadas (blocos finally). O trecho de
codigo na Figura 3.5 apresenta o resultado de extrair os tratadores do trecho de
codigo na Figura 3.2 para aspectos. Observa-se que o comando try, junto com o
bloco catch tambem foram removidos. Caso a necessidade de na refatoracao haver
desmembramento de um advice, por conta de existir mais de um bloco catch, e
necessario explicitar a ordem da execucao dos advice. A Figura 3.6 apresenta o advice
resultante da extracao, responsavel por tratar a excecao do tipo CoreException.
Para os casos em que advice tratadores de excecoes necessitam de atributos e
campos privados da classe, e necessario declarar os aspectos como privileged para
ter acesso a essas informacoes. Em outro caso, quando o advice tratador de excecao
necessita de variaveis locais ao metodo, e necessario uma extrair um trecho de codigo
como um novo metodo [23], a fim de expor essas variaveis locais aos aspectos como
argumentos dos novos metodos criados. Em poucas situacoes, por exemplo, os advice
tratadores de excecoes leem duas ou mais variaveis locais dos metodos extraıdos, nao
e possıvel fazer a extracao sem comprometer o comportamento normal do sistema.
Assim, os tratadores de excecoes permanecem do mesmo modo.
25
1 public class CheckSelectedFilesAction {
2 ... public void run(IAction action) {
3 ...
4 addFileResources(mSelection.toList (), filesToCheck);
5 ...
67 } ...
8 }
Figura 3.5: Codigo da Classe CheckSelectedFilesAction Refatorada AO.
1 public privileged aspect ActionAspectExceptionHandler
2 {
3 ... declare soft: CoreException : CheckSelectedFilesActionHandle_runHandle ();
4 ... pointcut CheckSelectedFilesActionHandle_runHandle ():
5 execution (public void CheckSelectedFilesAction.run (..)) ;
6 ... void around (): CheckSelectedFilesActionHandle_runHandle (){
7 try { proceed (); } catch (CoreException e) {
8 CheckSelectedFilesAction c =
9 (CheckSelectedFilesAction) thisJoinPoint.getThis ();
10 CheckstyleLog.errorDialog(c.mPart.getSite ().getShell (), e, true);
11 }
12 }...
13 }
Figura 3.6: Codigo do Aspecto ActionAspectExceptionHandler.
3.3.2 Reuso dos Tratadores de Excecao
Para reusar os tratadores de excecao, uma abordagem similar foi conduzida com as
versoes refatoradas OO e refatoradas AO, levando-se em conta as diferencas entre
os diferentes paradigmas. Para as versoes refatoradas OO, o primeiro passo foi ins-
pecionar todos os tratadores de excecao existentes na classe tratadora de excecao
de cada pacote e procurar por tratadores similares, a fim de reusa-los. Metodos im-
plementando tratadores duplicados foram eliminados e as referencias aos metodos
excluıdos foram modificadas para apontar para apenas um caso. Cada classe tra-
tadora de excecoes foi revisada por pelo menos duas duplas diferentes. O proximo
passo foi verificar a duplicidade de codigo, procurando tratadores de excecoes, 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 responsavel 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 excecoes vazias, devido a remocao de tratadores duplicados,
foram removidas. Na Figura 3.7 e apresentado um diagrama de classes para essa
solucao.
26
Figura 3.7: Diagrama de Classes das versoes Ref. OO.
Para as versoes refatoradas AO, o procedimento foi similar ao realizado para as
versoes refatoradas OO. O primeiro passo foi a inspecao do codigo duplicado dentro
de cada aspecto, por pacote. Quando encontrados advice tratadores semelhantes,
esses sao combinados em apenas um, verificando assim a possibilidade de reuso den-
tro de cada pacote. A complicacao 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 combina-los, dependendo da maneira como
funcionam. Esse tipo de combinacao nao e permitido para tratadores escritos pu-
ramente em Java, devido a verificacao de tipos realizada pelo compilador de Java.
Essa flexibilidade faz com que o desenvolvedor tenha que levar mais questoes em
consideracao para combinar advice tratadores semelhantes. Adicionalmente, algu-
mas vezes, os conjuntos de blocos catch associados a diferentes blocos try nao
puderam ser reusados em conjunto, mas blocos catch individuais puderam. Nessa
situacao, e necessario desagrupar os advice que possua varios 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 necessario ser explıcito a ordem dos novos advice advindos dos
catch desmembrados.
Apos o reuso de tratadores em cada aspecto, dentro de cada pacote, o proximo
passo foi semelhante ao reuso apresentado nas versoes refatoradas OO. Um aspecto
geral global foi criado contendo codigo de tratadores de excecoes similares, usados
em diferentes pacotes. Diferentemente das versoes refatoradas orientadas a
objetos (Ver. Ref. OO), as versoes refatoradas orientadas a aspectos (Ver.
Ref. AO) nao podem usar heranca para os aspectos de cada pacote herdarem os
27
tratadores semelhantes. Nao por limitacao da linguagem, mas pelo motivo de nem
todos os aspectos concretos que estendem os aspectos abstratos nao possuem a
necessidade de implementar os pointcut abstratos, pelo fato de nao terem necessidade
do tratamento mais generalizado existente no aspecto abstrato. Os aspectos gerais
das aplicacoes interferem em cada classe Java, vindas da versao original, diretamente,
quando necessario. Na Figura 3.8 e apresentado o diagrama de classes dessa solucao,
mostrando onde cada pacote, aspectos e classes ficaram.
Figura 3.8: Diagrama de Classes das versoes Ref. AO.
O trecho de codigo na Figura 3.9 mostra um metodo que e chamado por doze
diferentes blocos catch, em uma das aplicacoes. O trecho de codigo na Figura
3.10 apresenta o mesmo tratador de excecoes do trecho de codigo na Figura 3.9, na
linguagem AspectJ. O tratador neste caso nao e chamado por cada bloco catch. Ao
inves disso, o advice e associado a doze pontos de juncoes diferentes no sistema.
1 ...
2 // Called by some code location
3 public void rethrowCheckstylePluginException(Exception e)
4 throws CheckstylePluginException {
5 CheckstyleLog.log(e);
6 CheckstylePluginException.rethrow(e);
7 }...
Figura 3.9: Exemplo de Reuso de Tratadores de Excecao nas Ver. Ref. OO.
28
1 ...
2 Object around () throws CheckstylePluginException:
3 RetrowException_runHandle () ||
4 ProjectConfigurationFactory_internalLoadFromPersistenceHandler () ||
5 checkConfigurationMigrator_migrateHandler () ||
6 ProjectConfigurationEditor_internalEnsureFileExistsHandler () ||
7 ExternalFileConfiguration_internalEnsureFileExistsHandler () ||
8 checkConfigurationMigrator_ensureFileExistsHandler () ||
9 auditor_runAuditHandle () ||
10 PackageNamesLoader_getPackageNames () ||
11 CustomLibrariesClassLoader_get () ||
12 RetrowException_setModulesHandle () ||
13 RemoteConfigurationType_internalGetCheckstyleConfigurationHandler () {
14 Object result = null;
15 try {
16 result = proceed ();
17 } catch (IOException ioe) {
18 CheckstyleLog.log(ioe);
19 CheckstylePluginException.rethrow(ioe);
20 }
21 return result;
22 }
23 ...
Figura 3.10: Exemplo de Reuso de Tratadores de Excecao na Ver. Ref. AO.
3.4 Conjunto de Metricas
Para avaliar as refatoracoes, em cada um dos os tres sistemas e para cada versao
refatorada, foi utilizado um conjunto de metricas estaticas de codigo. Para coletar
essas metricas foi utilizada uma ferramenta, desenvolvida a partir da AopMetrics5,
a EH-Meter. Mais informacoes sobre a ferramenta sao apresentadas no Capıtulo 5.
Como o objetivo desse estudo e avaliar o reuso de codigo de tratadores de excecoes,
foi escolhido um conjunto de metricas capaz de medir os efeitos do reuso de tra-
tadores de excecoes. Uma premissa para a escolha desse conjunto de metricas e
que uma quantidade menor de codigo de tratamento de excecoes duplicado e um
indicador confiavel do reuso. Mais especificamente, foram selecionadas 11 metricas,
com 10 delas focadas em tratamento de excecoes. Para todas as metricas, a reducao
dos seus valores indicam que o codigo obteve uma melhora, relativa a definicao de
cada uma das metricas.
As metricas selecionadas sao divididas em dois grupos: metricas de tamanho e
metricas de interesse. A Tabela 3.1 descreve as metricas brevemente e as agrupa
pelo seus tipos. O primeiro grupo de metricas, metricas de tamanho, inclui as
metricas para atributos comuns dos sistemas (ex. Numero de Linhas de Codigo) e
quantidades relativas ao interesse tratamento de excecoes (ex. Numero de blocos
5http://aopmetrics.tigris.org/
29
try). As metricas de tamanho selecionadas sao: Numero de Linhas de Codigo (LOC
- Lines Of Code), Numero de blocos try (NOT - Number Of Try blocks), Numero
de blocos catch (NOC - Number Of Catch blocks), Numero de blocos finally
(NOF - Number Of Finally blocks), Numero de linhas de codigo que implementam o
tratamento de excecoes (LOCEH - Lines Of Code pertaining to Exception Handling)
e numero de blocos tratadores de excecoes (NEH - Number Exception Handlers).
Essa ultima conta o numero de blocos que implementam o interesse de tratamento de
excecoes e e utilizado para quantificar o reuso dos tratadores de excecoes nas versoes
refatoradas. Essa metrica nao conta a quantidade de blocos que capturam excecoes,
ou seja, para as versoes refatoradas OO, ele conta apenas os metodos tratadores e
nao os blocos catch.
Metricas de interesse indicam o quanto o codigo e direcionado a um interesse [40].
Foram utilizadas essas metricas para avaliar o quanto a modularizacao e o reuso de
tratadores de excecoes estao relacionados. Alem disso, algumas dessas metricas
contam simplesmente o numero de ocorrencias de um determinado tipo de elemento
pertencente a um interesse especıfico. Isso nao difere das metricas de tamanho, mo-
stradas acima. Nesse estudo foram considerados apenas dois interesses: tratamento
de excecoes e o comportamento normal do sistema. As primeiras tres metricas [37]
sao bastantes conhecidas na comunidade de Desenvolvimento de Software Orientado
a Aspectos: Difusao de Interesses sobre Componentes (CDC - Concern Diffusion
over Components), Difusao de Interesses sobre Operacoes (CDO - Concern Diffu-
sion over Operations) e Difusao de interesse sobre Linhas de Codigo (CDLOC -
Concern Diffusion over LOC ). A justificativa para o uso dessas metricas e verificar
a difusao do interesse tratamento de excecoes, analisando: (i) quantos componentes
(classes e aspectos) e (ii) operacoes (metodos e advice) implementam o interesse tra-
tamento de excecoes; e (iii) quantas transicoes existem entre os interesses tratamento
de excecoes e comportamento normal.
Adicionalmente, foram utilizadas mais duas metricas recentes, que foram pro-
postas a fim de contornar algumas das limitacoes das metricas de interesse citadas
anteriormente. A primeira e Perda de Foco (LOF - Lack Of Focus), que e uma
adaptacao da metrica Grau de Foco (DOF - Degree of Focus), proposta por Eaddy
et al. [18]. DOF mede ate que ponto as linhas de um componente de codigo (classe
e aspecto) sao dedicadas a implementacao de um interesse especıfico. Os valores
variam entre 0 (completamente nao focado) e 1 (completamente focado). O valor
de LOF para cada componente e igual a 1 - DOF. A ultima metrica de interesse,
Grau de Espalhamento (DOS - Degree of Scattering) [18] mede o quanto as linhas
de codigo de um determinado interesse estao espalhados pelos componentes do sis-
30
tema. Mais informacoes entre DOF e DOS estao 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 codigo
relativo ao tratamento de excecoes do que a abordagem tradicional, orientada a
objetos. O estudo tambem tenta, de certa forma, compreender a relacao entre o
reuso de codigo de tratadores de excecoes e a modularizacao desses. As metricas
empregadas tentam apoiar a avaliacao das mudancas aplicadas ao codigo, tentando
levantar as vantagens e tambem desvantagens decorrentes dessas alteracoes. No
trabalho, foram investigados os impactos da reutilizacao e separacao de interesses,
usando programacao orientada a aspectos para modularizar a captura e o tratamento
das excecoes. Alem disso, uma versao refatorada orientada a objetos, para cada
aplicativo, foi desenvolvida a fim de garantir a verificacao de um melhor reuso. Essa
versao refatorada OO (Ver. Ref. OO) foi utilizada para tentar fazer um comparativo
de codigo modularizado em POO e POA, pois as versoes originais dos sistemas nao
foram projetadas e desenvolvidas para modularizar e reusar o codigo relativo ao
tratamento de excecoes.
A Tabela 3.2 apresenta o resultado das metricas de tamanho para cada versao
de cada sistema utilizado no estudo. Na tabela, Ver. Original indica a versao
original de cada sistema, totalmente escrita na linguagem Java, orientada a objetos.
Ver. Ref. OO indica a versao que foi refatorada, com o tratamento de excecoes
modularizado utilizando classes Java. Por ultimo, Ver. Ref. AO indica a versao
refatorada, mas com o tratamento de excecoes dentro dos aspectos em AspectJ.
A coluna Valor mostra o valor obtido em cada metrica, para cada versao de cada
sistema, e (%Incr) e o incremento do valor da metrica, comparado com a Versao Ori-
ginal. Como mencionado na Secao 3.4, para todos os valores das metricas, menores
valores implicam melhores resultados em relacao ao codigo original.
Como mostrado na Tabela 3.2, o numero de blocos try (NOT), numero de blocos
catch (NOC) e numero de blocos finally (NOF) nao apresentaram variacoes entre
as versoes Original e Ref. OO. Entretanto, esses valores diminuıram sensivelmente,
em cada sistema utilizado, comparando as versoes 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 versao, assim como apresentado
no estudo anterior de Lippert e Loppes [30]. E importante ressaltar, porem, que em
nenhum caso, a quantidade de reuso chegou a um patamar proximo ao obtido desse
31
estudo anterior (em alguns casos, mais de 80%).
O numero de LOC cresceu em todas as versoes refatoradas das aplicacoes. Mesmo
que o aumento percentual parecendo pequeno (entre 0,51% e 3,38%), ele e consi-
deravel na pratica, ja que apenas trechos de codigo relativos a tratamento de excecoes
foram criados ou modificados. Na mesma linha de LOC, a metrica LOCEH aumen-
tou tambem para todas as versoes refatoradas. Esse incremento, em LOC e LOCEH,
ocorreu porque: (a) as versoes Ver. Ref. OO tem mais codigo fonte para chamar os
novos metodos, as novas classes, novas declaracoes de metodos; (b) nas versoes Ver.
Ref. AO foi necessario criar novos aspectos, advice e pointcuts, alem de ter sido
necessario usar a diretiva declare soft para suprimir as checagens de tipo reali-
zadas pelo compilador de Java, para tratamento de excecoes. Esse resultado leva a
conclusao de que, diferentemente do que foi suposto por estudos anteriores [30][6],
reducao na quantidade de linhas de codigo nao tem correlacao com aumento no
reuso de tratadores de excecoes.
A metrica do numero de tratadores de excecoes (NEH) diminuiu em ambas
versoes refatoradas. O motivo para o decremento nos valores dessa metrica e que
existe a separacao entre a captura e o tratamento da excecao. Como os tratadores
na Ver. Ref. OO sao metodos cujos parametros sao excecoes para serem trata-
das, em muitos casos esses metodos podem ter como argumentos excecoes de tipos
mais genericos do que os tipos de excecoes levantados e tratados, criando assim
bastante oportunidade de reuso. Isso e possıvel porque as excecoes sao capturadas
pelos blocos catch ainda em termos de tipos especıficos, evitando a subsuncao das
excecoes [34]. Na Ver. Ref. AO, tanto a captura quanto o tratamento da excecao sao
implementados dentro dos advice. Em geral, os advice capturam excecoes usando
tipos especıficos, assim como na implementacao Java Original, a fim de nao cap-
turar involuntariamente excecoes nao desejadas. Se, na Ver. Ref. AO, os blocos
try-catch dentro dos advice tratadores fossem responsaveis exclusivamente pela
captura das excecoes e novos metodos, dentro dos aspectos, tivessem a responsabi-
lidade de trata-las, seria possıvel conseguir um reuso ainda maior, como os valores
proximos ou superiores aos obtidos para as Versoes Ref. OO. Mas essa abordagem
nao foi levada em consideracao no trabalho realizado. A Tabela 3.3 mostra os resul-
tados relativos as metricas de interesse. As metricas CDC, CDO e CDLOC indicam
como o interesse tratamento de excecoes esta espalhado e misturado atraves das
aplicacoes. As Versoes Ref. AO obtiveram os melhores resultados. Esses resultados
reforcam os estudos anteriores e exaltam a capacidade da POA de promover a se-
paracao textual de interesses transversais, como tratamento de excecoes. Os valores
de CDLOC para as versoes Ref. AO dos sistemas utilizados caıram em mais de 50%.
32
Os valores de CDO indicam que menos operacoes no sistema implementam o inter-
esse tratamento de excecoes (menos espalhado). Os valores obtidos para CDLOC
indicam o quanto o codigo de tratamento de excecoes esta entrelacado com codigo
relativo ao comportamento normal do sistema. Na Versao Ref. OO nao houve mu-
danca. Como os comandos try-catch-finally permanecem do mesmo jeito, as
transicoes entre os interesses nao sao modificadas. Diferentemente, na Versao AO,
onde houve a remocao desses comandos, transicoes entre codigo relativo ao inter-
esse tratamento de excecoes e codigo relativo ao comportamento normal do sistema
deixaram de existir. Entao, a consequencia das refatoracoes 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 modularizacao em menos componentes
fez diminuırem drasticamente as transicoes e o numero de componentes afetados por
esse interesse.
A metrica LOF (falta de foco) e normalizada e na Tabela 3.3 apresentada em dois
modos diferentes. O primeiro modo apresenta uma media da metrica LOF para todos
os componentes de cada sistema utilizado. A Tabela 3.3 tambem indica o numero de
componentes que possuem o valor de LOF igual a 0 (LOF=0). Essa metrica indica
o numero de componentes totalmente focados em somente um interesse, tratamento
de excecoes ou comportamento normal do programa. Como numero de elementos
que tem LOF=0 e muito grande, nao seria representativo usar a mediana, pois todos
os casos teriam o mesmo valor, oq eu nao diferenciaria as versoes analisadas. Ao
comparar o LOF=0, para cada versao de cada sistema utilizado, torna-se possıvel
analisar se o resultado de LOF e uma tendencia no sistema inteiro ou decorre apenas
de casos isolados. A metrica LOF=0 e a unica para a qual um valor maior implica
em um resultado melhor.
Nas versoes Ref. AO, tanto a media de LOF quanto o numero de componentes
com LOF igual a 0 foram os melhores entre todas as versoes. Isso significa que as
versoes Ref. AO apresentam componentes mais focados no tratamento de excecoes
ou no comportamento normal do programa. Ja para as versoes Ref. OO, os valores
foram ligeiramente melhores que para as versoes originais dos aplicativos. Esses
resultados devem ser analisados com cuidado. Como CDLOC nao se alterou nas
versoes Ref. OO, e possıvel deduzir que os componentes do sistema que estao pre-
sentes tanto nas versoes Original quanto Ref. OO nao tornaram-se substancialmente
mais focados, ja que ainda incluem comandos try-catch-finally, embora estes
ocupem menos linhas. Entretanto, as versoes Ref. OO incluem classes que sao to-
talmente focadas e dedicadas exclusivamente ao tratamento de excecoes. E possıvel
dizer que esse resultado e uma consequencia da modularizacao e reuso dos tratadores
33
de excecoes.
A ultima metrica coletada e apresentada na Tabela 3.3 e a DOS (grau de espal-
hamento). Similarmente a LOF (e DOF), o valor dessa metrica e normalizado entre
0 e 1. O valor 0 para essa metrica significa que o interesse e inteiramente contido
em uma unidade do programa. O valor 1 significa que a implementacao do interesse
esta espalhado por todos os componentes do sistema. Os resultados obtidos nessa
metrica indicam que a Ver. Ref. AO apresentou os melhores resultados, embora com
uma diferenca pequena, com relacao as outras versoes. Isso porque o tratamento de
excecoes ainda permanecem espalhados por alguns locais no codigo, mesmo tendo
diminuido os locais de existencia do codigo. Isso e compreensıvel, pois as versoes Ver.
Ref. AO concentram a maioria do codigo relativo ao tratamento de excecoes dentro
dos aspectos, assim reduzindo o numero de unidades do programa responsaveis pela
implementacao de alguma parte de codigo desse interesse. Mas o tratamento de
excecoes ainda existe em varios aspectos do sistema, o que embora tenha diminuıdo
o numero de componentes contendo o codigo desse interesse, ainda esta espalhado.
A Ver. Ref. OO teve resultados pouco piores do que a versao Original, pois parte
do tratamento de erros, a captura, ainda continua espalhada um por grande numero
de componentes. Finalizando, para todas as versoes de todos os sistemas utilizados,
os valores de DOS foram muitos elevados para o interesse tratametno de excecoes,
mostrando que mesmo diminuindo em relacao a versao original, o codigo relativo ao
tratamento de excecoes continua espalhado por varios locais do sistema.
O percentual de incremento para cada metrica e apresentado nas Figuras 3.11
e 3.12. As metricas de tamanho sao retratadas na Figura 3.11 enquanto os incre-
mentos relativos as metricas de interesse sao apresentadas na Figura 3.12. Olhando
para esses valores, pode-se observar que ouve consistencia da abordagem de modu-
larizacao de tratamento de excecoes, para cada aplicacao, em uma mesma metrica
considerada. Por exemplo, todas as versoes Ref. AO exibiram um numero menor
de blocos try e uma maior quantidade de linhas de codigo relativo ao tratamento
de excecoes. Isso sugere que os resultados obtidos possam ser aplicados a outras
aplicacoes com caracterısticas similares.
Uma analise cuidadosa dos dados pode revelar alguns pontos interessantes. O
primeiro ponto e a existencia de uma relacao 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 excecao de fato influenciam o numero final de LOC. No entanto, o overhead da
utilizacao de POA, em termos de LOC, e consideravel. Para todos os sistemas, LO-
CEH cresceu pelo menos 25%. Mais importante ainda, esse overhead e, para todas
34
Figura 3.11: Incrementos nas Metricas de Tamanho.
Figura 3.12: Incrementos nas Metricas de Interesses.
as situacoes que foram analisadas ate agora, muito maior do que a economia em LOC
proporcionada por POA. Essas observacoes levantaram outro ponto importante.
Esse estudo evidenciou que, quando aplicada a modularizacao do interesse tra-
tamento de excecoes, POA promove o reuso. No entanto, nao esta claro se isso
resulta em codigo mais facil de manter e mais compreensıvel. Indiscutivelmente, os
desenvolvedores ao tentar compreender um sistema onde o tratamento de excecoes e
modularizado com aspectos, precisam compreender um maior numero de metodos,
maior numero de componentes e um maior numero de LOC. Alem disso, a utilizacao
de aspecto de tratadores de excecoes influencia o fluxo de controle dos programas
de maneira sutis que nao sao evidenciadas no codigo [3, 11].
35
3.6 Conclusoes sobre Reuso Intra-Aplicacao
Este capıtulo apresentou um estudo com o objetivo de verificar o potencial de abor-
dagens de modularizacao para promover o reuso intra-aplicacao para o codigo re-
lativo ao tratamento de excecoes. Mais especificamente, foram comparadas duas
implementacoes, uma orientada a aspectos e outra orientada a objetos para tres
aplicacoes diferentes e empregado um conjunto de metricas especıficas para o in-
teresse de tratamento de excecoes. Os resultados do estudo mostraram que POA
promove reuso de codigo relativo ao tratamento de excecoes e tambem melhora a
estrutura do codigo. Apesar de certa quantidade de modularizacao e reuso poderem
ser obtidos atraves do emprego de POO puramente, o estudo evidencia que o uso
de POA permite uma maior reuso e modularizacao: melhor separacao textual dos
interesses, menos dispersao desses interesses e uma menor quantidade de blocos de
codigo relativo ao tratamento de excecoes. Ao mesmo tempo, para os tres sistemas,
houve aumento no numero de linhas de codigo relacionado ao interesse tratamento
de excecoes nas versoes orientadas a aspectos do que nas versoes orientadas a ob-
jetos. Esses resultados contradizem dois estudos anteriores [6] [30] que avaliam a
adequacao do uso de POA para modularizar o tratamento de excecoes.
E importante deixar claro que o reuso de tratadores de excecoes, abordado nesse
capıtulo foi exclusivamente no interior de cada uma das aplicacoes. No Capıtulo 4
e abordado o reuso entre aplicacoes diferentes, inter-aplicacoes.
36
Grupo Metrica Descricao
LOC Lines of Common Code: Linhas de codigo do sistema,
excluindo-se comentarios e linhas em branco.
NOT Number of Try blocks: Numero de blocos try.
Metricas NOC Number of Catch blocks: Numero de blocos catch.
de NOF Number of Finally blocks: Numero de blocos finally.
Tamanho LOCEH Lines of Exception Handling Code: Linhas de codigo
relativo ao tratamento de excecoes.
NEH Number of Exception Handlers: Numero de blocos de codigo
relativos ao tratamento de excecoes.
CDC Concern Diffusion over Component [37]: Conta o numero de
componentes(classes, aspectos, interfaces) que incluem codigo
de tratamento de excecoes.
CDO Concern Diffusion over Operation [37]: Conta o numero de
operacoes(metodos e advice) que incluem codigo de
tratamento de excecoes.
CDLOC Concern Diffusion over Lines of Code [37]: Conta o numero de
Metricas pontos de transicao para cada interesse atraves das linhas
de de codigo. O uso dessa metrica exige um processo
Interesse de sombreamento dentro do codigo, com areas sombreadas
e areas nao-sombreadas.
LOF Lack of Focus: Essa e uma medida da ausencia 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 metrica e obtido
a partir do valor da metrica DOF (Degree of Focus) [18].
LOF = 1 - DOF.
DOS Degree of scattering [18]: Essa metrica mede a variacao de
concentracao 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 Metricas utilizadas
37
Sistema Metrica 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 Metricas de Tamanho
38
Sistema Metrica 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%)
Media 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%)
Media 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%)
Media 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 Metricas de Interesse
39
Capıtulo 4
Reuso Inter-Applicacao
Apos a verificacao do reuso de codigo tratadores de excecoes para uma mesma
aplicacao no Capıtulo 3 (reuso Intra-Aplicacao), neste capıtulo um outro estudo
foca na verificacao de reuso de codigo entre aplicacoes diferentes, o reuso Inter-
Aplicacao. Para essa avaliacao foram utilizados sete sistemas bastante difundidos
na comunidade, com tamanho medio, alguns com funcionalidades semelhantes e
plataforma semelhantes.
Nas proximas secoes sera descrito como foi feito esse estudo. A seguir e apre-
sentado a metodologia do estudo (Secao 4.1) e os Sistemas Utilizados (Secao 4.2), a
Extracao e Reuso dos Tratadores de Excecoes (Secao 4.3), a Metodologia de Busca
Aplicada (Secao 4.4) no reuso, os Resultados (Secao 4.5) do estudo, os Problemas
Relacionados (Secao 4.6) e as Conclusoes (Secao 4.7).
4.1 Metodologia
Esse trabalho e uma extensao do trabalho apresentado no capıtulo 3, agora focando
no reuso Inter-aplicacao. A abordagem adotada nesse estudo e utilizacao de aspectos
com implementacao de codigo relativo ao tratamento de excecoes a fim de avaliar
se esse codigo pode ser reusado em aplicacoes diferentes. Diferentemente do estudo
de reuso intra-aplicacao, esse estudo utilizou somente duas alternativas de modula-
rizacao: i) uma abordagem ’regular’, com o codigo original de cada aplicacao, tendo
o codigo relativo ao tratamento de excecoes junto com o codigo de comportamento
normal do sistema; e ii) uma segunda abordagem com os tratadores de excecoes
dentro de aspectos, na linguagem AspectJ.
Tres dos sete sistemas foram reutilizados do estudo de reuso intra-aplicacao, utili-
zando as extracoes de tratadores e verificacao 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 revisoes das extracoes e reuso encontrado. Apos todas as aplicacoes terem os
tratadores de excecoes dentro de aspectos e tendo o aplicado o reuso internamente
em cada uma, foi verificado o reuso entre todas aplicacoes, utilizando metodologias
de busca a serem explicadas na Secao 4.4.
A principal diferenca entre os dois estudos e o foco onde o reuso e aplicado.
Embora esse novo estudo utilize todas as aplicacoes com os tratadores de excecoes
reusados internamente, o objetivo e analisar o reuso entre todas elas. Outra dife-
renca e que apenas vamos utilizar aspectos para verificar a reusabilidade, diferente-
mente do estudo anterior que tambem utilizou uma com os tratadores de excecoes
dentro de classes Java. As aplicacoes que foram utilizadas possuem possuem dis-
tintos atributos relativos a plataformas de desenvolvimento, finalidade e tamanho.
Algumas possuem atributos semelhantes e outras nao. A partir desse estudo pode-
mos verificar se e possıvel reusar ou nao codigo relativo ao tratamento de excecoes
em aplicacoes diferentes, quando esse codigo estiver dentro de aspectos e para os
sistemas escolhidos para esse estudo.
4.2 Sistemas Utilizados
Para este estudo foram utilizadas sete aplicacoes escritas em Java. Essas aplicacoes
sao representativas por serem aplicacao reais, de tamanho medio na industria 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 codigo referente ao tratamento de excecoes e no mınimo 80 componentes
(classes e interfaces). Esses valores variam bastante de uma aplicacao para outra,
com algumas dessas aplicacoes possuindo valores bem maiores, como mais de 23K
LOC ou aproximadamente 10% do codigo dedicado ao tratamento de excecoes. A se-
gunda caracterıstica e referente a heterogeneidade das aplicacoes:as sete aplicacoes
analisadas vem de seis domınios diferentes, baseiam-se em diferentes plataformas
de desenvolvimento e foram desenvolvidas por diferentes organizacoes. Ao mesmo
tempo, uma premissa deste trabalho e que e mais provavel que seja possıvel reutili-
zar tratadores de excecoes se os sistemas estudados tiverem algumas caracterısticas
em comum. Tendo isso em vista, quatro dos sistemas alvo deste estudo sao plugins
para o Eclipse1 e dois sao aplicacoes Java para desktops, baseadas na plataforma
Java Standard Edition (Java SE). Alem disso, dois dos sistemas alvo podem ser en-
quadrados em um mesmo domınio: o das ferramentas de coleta de metricas estaticas
1http://www.eclipse.org/
41
de codigo. As aplicacoes selecionadas para este estudo sao as seguintes:
• Checkstyle2. Ferramenta para checagem de estilo de programacao para pro-
gramas escritos na linguagem Java.
• TeXlipse3. Editor de LaTex para Eclipse.
• EIMP4. Ferramenta de mensagens instantaneas para GTalk, MSN e outros
protocolos de comunicacao.
• JHotDraw5. Framework de GUI de Java, para desenhos tecnicos e estrutu-
rados.
• Java Pet Store6. Demo da plataforma Java Enterprise Edition para a
construcao de aplicacoes corporativas.
• AOPMetrics7. Ferramenta de coleta de metricas estaticas de codigo Java e
AspectJ.
• Metrics8. Ferramenta de coleta de metricas estaticas de codigo Java.
A Tabela 4.1 apresenta todas as sete aplicacoes, os tamanhos de cada em termos
de LOC total, LOC referentes ao tratamento de excecoes, numero de componentes
(classes e interfaces), a plataforma de desenvolvimento e uma breve descricao das
funcionalidades. Esses valores foram obtidos para as versoes originais, totalmente
implementadas em Java. Para cada uma dessas aplicacoes, uma nova versao foi
desenvolvida, com o tratamento de excecoes extraıdo para aspectos implementados
em AspectJ.
4.3 Extracao e Reuso dos Tratadores de Excecoes
Para chegar nas versoes com todo o tratamento de excecoes dentro dos aspectos, foi
necessario fazer refatoracoes para que todos os sistemas utilizados no estudo tenham
os tratadores de excecoes dentro de aspectos e nao mais em classes Java. Como no
estudo descrito no capıtulo 3, para obter a versao refatorada a partir da original,
2http://eclipse-cs.sourceforge.net/3http://texlipse.sourceforge.net4http://eimp.sourceforge.net5http://www.jhotdraw.org/6http://java.sun.com/developer/releases/petstore/7http://aopmetrics.tigris.org/8http://metrics.sourceforge.net/
42
Aplicacoes 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: Aplicacoes Usadas para reuso Inter-Aplicacoes.
foi levado em consideracao somente o conteudo dos blocos catch e finally. Parte
das refatoracoes foi feita em pares. Os resultados dessa atividade foram revisados
por outros pares, sistematicamente. Para alguns dos sistemas alvo do estudo, a
refatoracao do tratamento de excecoes para aspectos foi realizada por apenas um
componente da equipe, com experiencia na extracao de tratadores de excecoes 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 codigo relativo ao tratamento de excecoes apenas
entre aplicacoes distintas. A linguagem AspectJ foi usada como uma ferramenta
para atingir este fim. Outra opcao seria mover os tratadores para metodos escritos
em Java mas, como descrito no capıtulo anterior, essa solucao e inferior ao uso de
POA. A extracao dos tratadores de excecao, como tambem o reuso interno a cada
aplicacao foi realizado da mesma forma do estudo anterior (Capıtulo 3) e e descrito
na secao 3.3.
Apos a avaliar se o reuso e possıvel dentro de cada aplicacao alvo do estudo, foi
feita a verificacao da possibilidade de reusar os tratadores entre diferentes aplicacoes.
O primeiro passo, para reuso inter-aplicacoes foi a generalizacao dos aspectos de tra-
tamento de excecoes pre-existentes para que possam ser usados em varias aplicacoes
ao mesmo tempo. Essa generalizacao foi necessaria para que o codigo a ser reusado
nao tivesse nenhum conhecimento de cada aplicacao, atraves de aspectos abstratos
e interface. Mais informacoes sobre a generalizacao e apresentada na Secao 4.5.
Usando uma metodologia de busca, descrita na Secao 4.4, foi realizada uma busca
por tratadores de excecoes reusaveis nas diferentes aplicacoes. Quando descoberta
a possibilidade de reuso, foi criado no codigo que sera reusado, um aspecto abstrato
com um pointcut abstrato e o codigo tratador da excecoes concreto (e reutilizado)
dentro do advice. O proximo passo foi, para cada aplicacao onde existe tratador
de excecao que possa ser reusado entre aplicacoes, a criacao de um novo aspecto,
estendendo o aspecto abstrato e implementando somente o pointcut que definira a
43
1 public privileged aspect FiguresExceptionHandler {
2 ...
3 declare soft: CloneNotSupportedException: FigureAttributes_cloneHandler ();
4 pointcut FigureAttributes_cloneHandler () :
5 execution(Object FigureAttributes.clone (..));
67 Object around () throws InternalError : FigureAttributes_cloneHandler () {
8 try {
9 return proceed ();
10 }
11 catch (CloneNotSupportedException e) {
12 throw new InternalError ();
13 }
14 }
15 ...
16 }
Figura 4.1: Codigo Original do Reuso Inter-Aplicacao.
quais pontos de juncao os tratadores serao associados.
Os trechos de codigo apresentados nas figuras 4.1, 4.2 e 4.3 apresentam um
exemplo de codigo reusado. O trecho de codigo da Figura 4.1 apresenta um caso
inicial onde um aspecto e responsavel por implementar o tratamento da excecao
CloneNotSupportedException para somente uma aplicacao. Se esse tratamento
estiver duplicado em varias aplicacoes, esse aspecto precisara ser generalizado para
tornar possıvel o reuso. Ja o trecho de codigo da Figura 4.2 apresenta o aspecto
reusavel para o tratamento da excecao CloneNotSupportedException. Esse as-
pecto define o pointcut abstrato cloneNonSuportedGeneral(), usado por aspectos
concretos em diferentes aplicacoes para indicar pontos onde o tratador sera reusado.
E por fim, no trecho de codigo 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 excecao podem ser reusados sem qualquer modificacao.
4.4 Metodologia de Busca Utilizada
Esta secao descreve a metodologia utilizada para procurar por oportunidades de
reuso de codigo tratador de excecoes, para cada aplicacao. Inicialmente, uma
44
1 public abstract aspect CloneErrorAbstractExceptionHandling {
2 declare soft: CloneNotSupportedException: cloneNonSuportedGeneral ();
3 // Assinatura de pointcuts abstratos
4 abstract pointcut cloneNonSuportedGeneral ();
5 // Implementando codigo do Advice
6 Object around () throws InternalError : cloneNonSuportedGeneral () {
7 try {
8 return proceed ();
9 }
10 catch (CloneNotSupportedException e) {
11 throw new InternalError ();
12 }
13 }
14 }
Figura 4.2: Aspecto Abstrato no codigo reusavel
1 public privileged aspect CloneErrorImplementationExceptionHandling extends
2 CloneErrorAbstractExceptionHandling {
3 pointcut cloneNonSuportedGeneral ():
4 execution(Object FigureAttributes.clone (..));
5 }
Figura 4.3: Aspecto Concreto que estande do Aspecto Abstrato
aplicacao de deteccao de clones de codigo, o CCFinder9, ia ser utilizada para fa-
cilitar essa busca. O principal entrave foi da ferramenta nao dar suporte a codigo
AspectJ, somente Java, onde foi realizada uma verificacao e o resultado na adicionou
nada relevante ao estudo. A limitacao de nao 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-aplicacao fosse levado em consideracao na busca.
4.4.1 Procurando Oportunidades de Reuso
A busca por oportunidades de reuso foi realizada manualmente, atraves de inspecao
manual do codigo das aplicacoes. Para essa busca foram utilizadas dois metodos: a)
verificacao direta se existiam casos de tipos de excecoes e tratadores semelhantes e
b) verificacao agrupando por casos classificados no trabalho de Cabral e Marques [2].
A busca por reuso comecou com o cruzamento dos casos existentes nos aspectos
gerais da aplicacao, que estao contidos GeneralExceptionHandler, aspecto descrito
na Secao 3.3. Assim, a busca por tratadores reutilizaveis foi iniciada justamente nos
elementos mais reusados em cada sistema. O proximo passo foi procurar por outros
tratadores que seriam possıveis reusar, em cada pacote dos sistemas. Esse tipo de
busca e complicado, pois e necessario ter conhecimento de todos os tipos de excecoes
9http://www.ccfinder.net/
45
1 Object around () : FileMatchPattern_cloneHandler () ||
2 FileMatchPattern_cloneFileSetHandler () ||
3 FileMatchPattern_cloneProjectHandler () ||
4 FileMatchPattern_cloneWorkingCopyHandler () ||
5 AbstractFilter_cloneHandler () ||
6 cloneHandle (){
7 try {
8 return proceed ();
9 } catch (CloneNotSupportedException e) {
10 throw new InternalError ();
11 }
12 }
Figura 4.4: Exemplo da estrategia Lancamento.
levantadas e todos os tratadores existentes nas aplicacoes, alem das implementacoes
destes ultimos. Alem disso, a complexidade dessa tarefa cresce de forma exponencial
com o numero de aplicacoes avaliadas, o que a torna nao-escalavel e imprecisa.
A procura por tratadores de excecoes candidatos ao reuso utilizando a classi-
ficacao de Cabral e Marques [2] torna-se mais facil, pois diminui a necessidade de
conhecer todos os tratadores e de comparar todos eles entre si. Com esta abordagem,
so e necessario comparar tratadores cujas estrategias de tratamento de excecao se-
jam similares. O trabalho de Cabral e Marques define categorias de tratadores
de excecoes com base em suas estrategias de tratamento. Nem todos as catego-
rias de excecoes existentes podem ser implementadas em AspectJ, o que diminui
o numero de categorias de estrategias de tratamento de excecoes e, consequente-
mente, o numero de candidatos ao reuso. As categorias levadas em conta neste
estudo sao apresentadas na Tabela 4.2. Das categorias descritas no trabalho de
Cabral e Marques [2] a categoria Delegates so pode ser implementada em .NET10
e no estudo nao foram encontrados casos das categorias Assert e Rollback, que sao
descritas no trabalho de Cabral e Marques [2].
Uma estrategia bastante utilizada e a estrategia de lancar outra excecao. No
trecho de codigo mostrado na Figura 4.4 mostra um exemplo dessa estrategia. A
Tabela 4.3 apresenta um mapeamento das excecoes capturadas e excecoes que sao
novamente levantadas das aplicacoes listadas na Tabela 4.1. E possıvel notar na
Tabela 4.3 que em poucos casos existe um correspondencia entre excecao capturada
e excecao levantada novamente para aplicacoes distintas, o que minimiza os casos
possıveis de reuso. Os casos onde essa correspondencia existe estao marcados na
tabela com “*”.
10http://www.microsoft.com/NET/
46
Categoria Descricao
Vazio O codigo do tratamento e vazio e nem faz nada alem
de limpar a pilha.
Log Algum registro de erro ou notificacao ao usuario de situacao
inesperada.
Alternativo/ No caso de algum erro na execucao de um bloco finally
Configuracao ou algum outro tipo de configuracao (alternativa) de estado
estatica de um objeto.
Lancamento Um novo objeto de excecao e criado e lancado ou a
excecao original e re-lancada.
Retorno O tratador da excecao forca o metodo da execucao a retornar
ou a aplicacao finalizar. Se o tratador estiver dentro de
um laco e a acao de execucao do laco e interrompida atraves
de um comando break, tratador tambem e incluso nesta categoria.
Fechar O codigo garante que uma conexao aberta ou um fluxo (stream)
de dados e fechado. Uma outra acao que se enquadra nessa categoria
e a liberacao do bloqueio de algum recurso.
Outros Outros tipos de acoes de tratamento de excecoes que nao se
enquadram nos descritos acima.
Tabela 4.2: As estrategias de tratamento de excecoes propostas por Cabral e
Marques.
47
Aplicacao Excecao Capturada Excecao 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 excecao.
48
4.4.2 Empacotamento e Ambiente de Compilacao
Empacotamento e termo adotado neste trabalho para designar a atividade de tornar
um conjunto de tratadores de excecoes passıvel de ser associado a varias aplicacoes
distintas de forma simples. Para empacotar um grupo de tratadores reusaveis, basta
colocar esses tratadores em um aspecto separado do restante do codigo da aplicacao,
adotando a abordagem descrita na secao anterior. No momento da compilacao
do codigo de cada aplicacao, e colocado tambem o caminho contendo o codigo a
ser reusado como entrada nos parametros de compilacao do projeto. O proprio
compilador, no momento da compilacao, alem de compilar todos os arquivos fonte
passados como parametro de entrada tambem adiciona o codigo compilado referente
ao reuso inter-aplicacao para dentro da pasta de saıda dos arquivos .class, podendo
tambem adicionar ao novo arquivo .jar criado, caso seja opcao desejada.
Uma outra solucao possıvel para o empacotamento e fazer a compilacao do codigo
de cada aplicacao e do codigo a ser reusado separadamente. A primeira tarefa
desse modo de empacotamento e compilar o codigo a ser reusado separadamente,
sem ainda compilar o codigo das aplicacoes. Como os aspectos e os pointcuts sao
abstratos, em alguns casos, eles nao necessitam de informacoes do projeto para a
compilacao, sendo as vezes necessario apenas definir bibliotecas a serem utiliza-
das. Depois de compilado o codigo reusado, e necessario em cada projeto inserir
os arquivos .class compilados anteriormente, para poder compilar as aplicacoes que
utilizarao desse codigo reusavel.
Uma parte importante do reuso inter-aplicacoes e o ambiente de compilacao
das aplicacoes. Em alguns casos, pode ser estrategia do reuso utilizar codigo ja
compilado anteriormente. Para isso precisam ser observadas as versoes dos com-
piladores empregados para nao utilizar codigo reusavel compilado com uma versao
superior a do compilador empregado para compilar o restante da aplicacao. Alem
disso, existem dois compiladores maduros para AspectJ: ajc11 e abc12. O primeiro
compilador, ajc, e o mais comum. Ele e baseado no compilador Java com suporte
para compilacao de AspectJ usando o padrao da linguagem, enquanto o segundo e
mais focado para pesquisas. E importante verificar a compatibilidade entre esses
compiladores e suas limitacoes. O abc e um compilador extensıvel para novas fun-
cionalidades, mas tem limitacao na evolucao da linguagem e diferencas no uso. Alem
disso, possui funcionalidades adicionais, que nao estao disponıveis no ajc.
11http://www.eclipse.org/aspectj/doc/next/devguide/ajc-ref.html12http://abc.comlab.ox.ac.uk/
49
4.5 Resultados
Para os sete sistemas utilizados neste estudo (Secao 4.2), em apenas tres situacoes
foi possıvel reutilizar tratadores de excecoes. O primeiro e o caso mais simples,
uso de tratadores de excecoes em branco, onde a unica acao realizada, implicita-
mente, e a limpeza da pilha. Foi possıvel juntar todos os tratadores de excecoes em
branco no codigo reusado. O segundo caso foi para duas aplicacoes que capturam
a excecao do tipo CloneNotSupportedException e relancam uma nova excecao do
tipo InternalError. Para essas duas aplicacoes, em alguns casos, quando um pro-
grama tenta clonar um objeto e falha, ele trata a excecao lancada no momento da
clonagem levantando uma nova excecao (que sinaliza que a execucao do programa
deve ser interrompida, por ser um Error). Esse exemplo foi apresentado na secao
anterior, na Tabela 4.3.
O terceiro caso, e o mais significativo, foi a possibilidade de reusar o codigo que
trata excecoes usando a estrategia Log (Secao 4.2) para tres aplicacoes. A estrategia
de Log, definida por Cabral e Marques [2], pode guardar informacoes de erro, mensa-
gem, advertencia em arquivos onde o administrador do sistema pode verificar depois,
ou ate mesmo retornar ao usuario algum alerta. Cada aplicacao pode ter uma acao
ou finalidade para o Log a sua escolha. Para isso, se fez necessaria uma pequena
modificacao na estrutura inicial das classes Java desses sistemas. Inicialmente, cada
aplicacao possui uma classe que disponibiliza um metodo responsavel por fazer o
logging. Cada uma dessas classes deve implementar uma interface, ILogObject,
que pertence ao codigo reusavel de tratamento de excecao. Essa interface define
a assinatura para um metodo log(), que e o que o advice que implementa o trata-
mento de excecao no codigo reusavel deve conhecer. Tambem no codigo reusavel,
existe o aspecto abstrato LogAbstractHandler. Esse aspecto contem o tratamento
de excecoes que sera reutilizado. No trecho de codigo da Figura 4.5 e apresentado
esse aspecto. Assim, o metodo log() deve chamar o metodo que a interface imple-
menta, fazendo o codigo reusavel somente chamar os metodos dessa interface sem
necessidade de conhecer o codigo.
No aspecto apresentado no trecho de codigo da Figura 4.5, existem dois point-
cuts abstratos, como tambem dois metodos abstratos. Esses pointcuts e metodos
devem ser implementados nos aspectos concretos. Os dois pointcut lidam com duas
situacoes distintas que podem mais bem entendidas mediante o estudo dos advice
aos quais estao associados (explicados abaixo). Os metodos 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
metodo 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 diferenca quanto a captura da
excecao. O primeiro trata qualquer excecao, pois captura Exception. Assim, qual-
quer ponto de juncao selecionado por esse pointcuts implementa codigo para tratar
qualquer tipo de excecao, pois Exception e a super classe para todas as excecoes
em Java, ficando abaixo apenas de Throwable que tambem engloba os erros, que
idealmente nao devem ser capturados. A segunda so captura todas as excecoes
checadas, as excecoes que herdam de Exception, mas relanca as excecoes que her-
dam de RuntimeException. Vale lembrar que cada aplicacao deve especificar os
pontos de juncao para esse tratamento. A diferenca dos dois casos e que o pri-
meiro tambem tratam de excecoes que herdam de RuntimeException enquanto o
segundo nao. Uma atributo importante para essa solucao e saber qual o pointcut
associado ao ponto de juncao que interceptou o fluxo de execucao. A necessidade de
saber do pointcut e para saber qual a mensagem que devera ser enviada ao metodo
logGeneral(logText, e), nas linhas 14 e 26. Um numero identificando o pointcut
e obtido pelo metodo thisEnclosingJoinPointStaticPart.getId().
Do lado do codigo de cada sistema que vai utilizar o codigo reusavel, o primeiro
passo, conforme descrito antes, e fazer a classe que precisa registrar informacoes im-
plementar a interface ILogObject, que e definida dentro do codigo reusavel. Dessa
forma, o codigo reusavel so precisa conhecer o objeto que fara o logging , atraves da
interface, sem necessidade de saber de particularidades da aplicacao. As outras mo-
dificacoes sao no aspecto concreto, que estende LogAbstractHandler. Esse aspecto
deve implementar os pointcuts e metodos supracitados. No segundo caso, deve
especificar qual mensagem devera ser registrada para cada ID de pointcuts e qual e
o objeto que possui o metodo de Log. Assim, foi possıvel reusar esse mesmo tratador
21 vezes na aplicacao Checkstyle Plugin, 42 vezes no TeXlipse e 25 na Metrics.
4.5.1 Estrategias de Cada Aplicacao
No estudo tambem foi levantada a quantidade de tratadores que adotam cada es-
trategia apresentada no trabalho de Cabral e Marques [2]. A Tabela 4.4 apresenta
esses valores levantados. Com esses valores pode-se observar que ha uma grande
variedade de tratadores de excecoes nas aplicacoes alvo do estudo.
51
1 public abstract privileged aspect LogAbstractHandler {
2 // Assinatura de pointcuts abstratos
3 public abstract pointcut checkedExceptionLog ();
4 public abstract pointcut exceptionLog ();
5 // Implementando Advice 1
6 Object around (): checkedExceptionLog () {
7 Object result = null;
8 try { result = proceed ();
9 } catch (RuntimeException re){
10 throw re;
11 } catch (Exception e) {
12 String logText = getMessageText(
13 thisEnclosingJoinPointStaticPart.getId());
14 getLogObject ().logGeneral(logText , e);
15 }
16 return result;
17 }
18 // Implementando Advice 2
19 Object around (): exceptionLog () {
20 Object result = null;
21 try {
22 result = proceed ();
23 } catch (Exception e) {
24 String logText = getMessageText(
25 thisEnclosingJoinPointStaticPart.getId());
26 getLogObject ().logGeneral(logText , e);
27 }
28 return result;
29 }
30 // Assinatura de metodos abstratos
31 public abstract String getMessageText(int pointcutId);
32 public abstract ILogObject getLogObject ();
33 }
Figura 4.5: Exemplo da estrategia throws.
Aplicacao Estrategia
Vazio Log A./C.E. Lancamento 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 estrategia.
52
Foi realizado tambem um comparativo dos tipos de excecoes que cada aplicacao
levanta, com o tratamento adotado, para se ter uma ideia sobre como cada tipo
da excecao e tratado. Em cada aplicacao, os tipos de excecoes foram divididos em
tres grupos: i) excecao da propria aplicacao; ii) excecao encontrada em bibliotecas
utilizadas pelo projeto; iii) excecao existente em Java e AspectJ. Assim, foi feito
o mapeamento de cada tipo de excecao, de acordo com os grupos aqui definidos.
A Tabela 4.5 apresenta, para duas aplicacoes pertencentes ao mesmo domınio, Me-
trics e AOPMetrics, os tipos de excecoes pelos grupos. Ha apenas quatro casos
de excecoes em comum entre as duas aplicacoes e as aplicacoes adotam estrategias
de tratamento bem distintas para elas. Isso fornece evidencia de que um mesmo
domınio (funcionalidade) nao e um fator relevante na analise da similaridade dos
tratadores de excecoes de aplicacoes distintas. Evidencia essa encontrada pelos dois
sistemas de coleta de metricas utilizados no estudo.
53
Aplicacao
Grupo Tipo da Excecao
AOPMetrics
Definida na org.tigris.aopmetrics.ajdt.AjdtBuilderException
Aplicacao 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
Aplicacao 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 excecao com seu respectivo grupo.
54
4.6 Problemas Relacionados
Alem dos fatores encontrados em trabalhos anteriores, que mostram algumas di-
ficuldades da tarefa de reusar tratadores intra-aplicacoes [6][30][42], o reuso inter-
aplicacoes possui um conjunto de problemas especıficos. Vale destacar que esses
problemas encontrados sao referentes a refatoracoes de sistemas de software reais,
utilizados na pratica e com tamanho medio. Alguns desses problemas provavelmente
podem tambem 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-
trategias de tratamento em programas que necessitam ler algum tipo de informacao
contida em um arquivo (input/output) sao diferentes das de programas que fazem
transacoes em banco de dados e transacoes que recebem entrada pela interface grafica
com o usuario (GUI). Isso e relacionado com o domınio especıfico da aplicacao, pois
cada domınio necessita de bibliotecas diferentes.
Alem do domınio especıfico, tambem e levado em consideracao a plataforma de
desenvolvimento para cada aplicacao. Aplicacoes com o mesmo domınio podem
ter bibliotecas diferentes, a depender de cada plataforma. Uma aplicacao desen-
volvida para ambiente movel necessita de bibliotecas especıficas, diferentemente de
um mesmo tipo de aplicacao 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 sao as bibliotecas de parsing para
arquivos XML, a DOM e a SAX. Cada uma utiliza estrategias diferentes para rea-
lizar a leitura dos arquivos XML, a depender da necessidade e escolha no momento
de desenvolvimento.
Caso nao existam problemas relativos ao domınio, plataforma e utilizacao de
bibliotecas, existe um outro fator. A estrategia de tratamento da mesma excecao,
para cada aplicacao. Isso esta relacionado a fatores diversos como a equipe de desen-
volvimento, a cultura da empresa onde o sistema foi desenvolvido, os requisitos do
sistema ate a cada pessoa que participou do desenvolvimento. Tratadores para uma
mesma excecao podem ter estrategias diferentes em um mesmo sistema, devido aos
membros da equipe que o implementou e ate mesmo ao momento da implementacao,
como proximidade ou nao de uma entrega, por exemplo. Esse problema pode ser
ainda mais discrepante em aplicacoes distintas, com equipes distintas e ambientes
de desenvolvimento completamente diferentes.
Alguns problemas nao sao inerentes ao ambiente mas sim a construcoes da lingua-
gem. Como este estudo teve como objetivo reusar codigo de tratadores de excecoes
55
com AspectJ, entao alguns problemas sao relacionados as linguagens Java e As-
pectJ. Um problema bem simples, facil de ser contornado, mas que necessita de
modificacoes no codigo original, e o uso de palavras reservadas em cada linguagem,
podendo variar ate em uma mesma linguagem. AspectJ possui algumas palavras
reservadas diferentes das de Java e pode haver a adicao de novas palavras reservadas
de uma versao da linguagem para a outra. Em uma aplicacao utilizada no estudo,
o programa Java original utilizava uma variavel com o nome before. Em Java isso
e valido, mas before e, em AspectJ, uma palavra reservada, o que significa que
compiladores para AspectJ consideram tal programa invalido. Uma das solucoes
para esse problema e o uso do pre-processamento.
4.7 Conclusoes do Reuso Inter-Aplicacao
Nesse capıtulo, foi apresentado um estudo focando no ganho potencial que a mo-
dularizacao do codigo relativo ao tratamento de excecoes pode proporcionar, em
diferentes aplicacoes. Para isso, o codigo de tratamento de excecoes de sete sistema
foi extraıdo para aspectos, reusado internamente a cada aplicacao e, em seguida,
foi analisada a possibilidade de reusar tais aspectos entre as sete aplicacoes. Os
resultados do estudo mostraram que e possıvel reusar aspectos de tratamento de
excecoes apenas em poucos casos, e esses casos foram muito simples. Neste estudo,
em nenhuma situacao foi possıvel reutilizar tratadores com mais que uma linha de
codigo entre diferentes aplicacoes. Em poucos casos foi possıvel reusar e, nesses ca-
sos, foi necessario levar em consideracao sete aplicacoes diferentes, com finalidades
e plataformas diferentes, desenvolvidas independente por organizacoes 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 excecoes analisa-
dos nao foram projetados para ser reusados, o que pode tambem ter interferido nos
resultados. Esses tratadores foram reutilizados a partir de sistemas ja existentes.
56
Capıtulo 5
EH-Meter
Metricas estaticas de codigo sao amplamente utilizadas para avaliar atributos de
qualidade de sistemas de software [39]. Metricas de codigo podem fornecer desde
informacoes basicas, como numero de linhas de codigo e de modulos no sistema, ate
informacoes mais refinadas como as dependencias entre os elementos do sistema e
o quao focados esses elementos sao [9]. Idealmente, metricas de codigo devem ser
coletadas de maneira automatica, a fim de acelerar o processo de medicao, evitar os
erros inerentes a coleta manual e garantir a uniformidade dos resultados, tornando
possıvel a realizacao de comparacoes.
Existem diversas ferramentas capazes de coletar metricas estaticas de codigo a
partir de programas escritos em diferentes linguagens de programacao. Por exem-
plo, Metrics1 e FindBugs2 coletam diversas metricas a partir de programas escritos
em Java. Tambem existem Resource Standard Metrics3, que possuem como alvo
sistemas escritos em C, C++, C# e Java.
Apesar da crescente popularidade da Programacao Orientada a Aspectos (POA)
[27], ha poucas ferramentas de coleta de metricas capazes de medir programas escri-
tos em linguagens de POA de forma automatica. Um exemplo de tais ferramentas
e o AOPMetrics, que coleta metricas de programas em AspectJ [29], uma extensao
orientada a aspectos da linguagem Java. Para que POA possa se consolidar como
o proximo passo na evolucao das linguagens de programacao, essa tecnica precisa
ser avaliada exaustivamente, tanto qualitativa quanto quantitativamente e melhor
ainda de forma automatizada.
Ate onde foi possıvel averiguar, todas as ferramentas de coleta de metricas exis-
tentes trabalham com metricas gerais, aplicaveis a todos os interesses de um sistema.
Consequentemente, nao e possıvel avaliar alguns atributos de qualidade no contexto
1http://metrics.sourceforge.net/2http://findbugs.sourceforge.net/3http://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, metricas focadas em interesses especıficos sao
mais eficazes do que as independentes de interesse. Utilizar apenas metricas que se
aplicam ao sistema como um todo, sem levar em conta os interesses que o compoem,
pode fazer com que a avaliacao de tais abordagens nao reflita adequadamente seus
benefıcios e limitacoes.
Nao e uma tarefa simples fazer a adaptacao de uma ferramenta que coleta
metricas genericas para tambem coletar metricas de interesse especıfico. Atual-
mente, existe uma ferramenta disponıvel que conta codigo relativo a um interesse
(concern) especificamente: ConcernTagger4, um plugin para o Eclipse. Apesar de
suas muitas vantagens, ConcernTagger exige que os usuarios tenham que selecio-
nar manualmente quais partes (metodos ou classe) do codigo referem-se ao interesse
que se deseja computar. Ela tambem impoe algumas limitacoes sobre as linhas de
codigo, deixando seus usuarios sem poder selecionar linhas dentro de um metodo.
Isso impede a coleta de algumas metricas de granularidade mais fina, como CD-
LOC [37]. Outra limitacao do ConcernTagger e que ele so pode fazer a medicao de
programas Java. Outra ferramenta similar ao ConcernTagger e a AJATO5, onde o
usuario precisa selecionar manualmente quais partes do codigo fonte do programa
sao relativas ao interesse especıfico.
Para melhor convencer a academia e industria de software sobre os benefıcios da
POA, avaliacoes exaustivas e profundas, tanto qualitativas como quantitativas, sao
necessarias. Argumentamos que um interesse especıfico, a abordagem de medicao
automatizada deve ser empregada para obter resultados melhores e mais precisos,
em estudos empıricos. Este capıtulo apresenta uma ferramenta de coleta de metricas
que visa preencher parcialmente essa lacuna. A ferramenta proposta, chamada de
EH-Meter (Exception Handler Meter), e capaz de coletar 11 metricas descritas em
diferentes trabalhos na literatura [18, 37] a partir de programas escritos em Java
ou AspectJ. Dez dessas metricas lidam com um interesse especıfico ( tratamento
de excecoes. Uma facilidade de tratar com esse interesse (tratamento de excecoes),
alem de ser o foco desse trabalho de mestrado, e o dato de que e um interesse
demarcado sintaticamente no codigo do programa, o que evita dificuldades ligadas
a mineracao de interesses [34] e permite que o foco se mantenha na atividade de
medicao. Essa ferramenta foi usada nos estudos apresentados nos Capıtulos 3 e 4
para realizar diversas medicoes de forma automatica.
4http://www1.cs.columbia.edu/ eaddy/concerntagger/5http://www.teccomm.les.inf.puc-rio.br/emagno/ajato/
58
Esse trabalho gerou um artigo que foi aceito, publicado e apresentado no 3o
ACoM [43] (3rd Workshop on Assessment of Contemporary Modularization Tech-
niques - ACoM.09), em OOPSLA.
Nas proximas secoes sao apresentadas as metricas coletadas pelo EH-Meter
(Secao 5.1), sua estruturacao interna (Secao 5.2), como ela pode ser usada para
medir programas em Java e AspectJ (Secao 5.3), uma avaliacao preliminar (Secao
5.4) e as conclusoes (Secao 5.5) do capıtulo.
5.1 Metricas Implementadas
O EH-Meter e capaz de colher diversas metricas relativas ao interesse de tratamento
de excecoes. As metricas escolhidas sao divididas em dois grupos: metricas de
tamanho e metricas de interesses. O primeiro grupo engloba diversas metricas que
visam determinar a quantidade de codigo em um sistema relativa ao interesse de
tratamento de excecoes. Para tanto, ha desde metricas tradicionais, como numero
de linhas de codigo (tanto total quanto especıficas de tratamento de excecoes) e
outras menos comuns, como numeros de blocos catch e finally. Essas metricas
sao listadas na Tabela 5.1. e foram apresentadas e descritasno Capıtulo 3. Para as
metricas NOT, NOC e NOF, caso o bloco try (-catch, -finally) apareca dentro
de outro bloco catch ou finally (mas nao try), ele nao e levado em conta. A
justificativa para isso e que, para fins de separacao de interesses, tal bloco nao
precisaria ser separado pois nao esta misturado a outros interesses. Essa decisao
esta em conformidade com o que foi seguido nos estudos descritos nos capıtulos
anteriores.
59
Grupo Metrica Descricao
LOC Lines of Common Code: Linhas de codigo do sistema,
excluindo-se comentarios e linhas em branco.
NOT Number of Try blocks: Numero de blocos try.
Metricas NOC Number of Catch blocks: Numero de blocos catch.
de NOF Number of Finally blocks: Numero de blocos finally.
Tamanho LOCEH Lines of Exception Handling Code: Linhas de codigo
relativo ao tratamento de excecoes.
NEH Number of Exception Handlers: Numero de blocos de codigo
relativos ao tratamento de excecoes.
CDC Concern Diffusion over Component [37]: Conta o numero de
componentes(classes, aspectos, interfaces) que incluem codigo
de tratamento de excecoes.
CDO Concern Diffusion over Operation [37]: Conta o numero de
operacoes(metodos e advice) que incluem codigo de
tratamento de excecoes.
CDLOC Concern Diffusion over Lines of Code [37]: Conta o numero de
Metricas pontos de transicao para cada interesse atraves das linhas
de de codigo. O uso dessa metrica exige um processo
Interesse de sombreamento dentro do codigo, com areas sombreadas
e areas nao-sombreadas.
LOF Lack of Focus: Essa e uma medida da ausencia 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 metrica e obtido
a partir do valor da metrica DOF (Degree of Focus) [18].
LOF = 1 - DOF.
DOS Degree of scattering [18]: Essa metrica mede a variacao de
concentracao 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 Metricas implementadas no EH-Meter
60
O outro grupo de metricas, relativas a separacao de interesses e tambem apre-
sentadas na Secao 3.4, tem o intuito de medir o quanto o codigo esta direcionado
aos interesses analisados, que no caso desse trabalho e o tratamento de excecoes,
e separado do codigo relativo aos outros interesses do sistema. As tres primeiras
delas mostram valores absolutos. As duas ultimas metricas relativas a interesses
contabilizam de forma normalizada os valores apresentados. Para todas as metricas,
um valor menor implica em um resultado melhor.
5.2 Implementacao
O EH-Meter e uma extensao da ferramenta AopMetrics6. Para facilitar a imple-
mentacao do EH-Meter, recursos como os parsers para Java e AspectJ e o engenho de
coleta de metricas do AopMetrics foram utilizados. Para a maior parte das metricas,
foi necessario apenas implementar as classes responsaveis pelas novas metricas. Al-
gumas delas, porem, exigem que a medicao seja feita de um modo diferente do que
acontece no AopMetrics, levando em conta o sistema como um todo e nao apenas os
valores individuais da metrica para cada componente analisado. Para estes casos,
foi necessario modificar o engenho de medicao do AopMetrics.
5.2.1 Arquitetura e Modificacoes no Codigo Original
A arquitetura da ferramenta e simples, dividida em modulos (pacotes) com propositos
bem definidos. No pacote principal se encontram o codigo responsavel por receber
entradas do usuario para execucao da ferramenta e outros recursos comuns a toda
a ferramenta, como o engine de coleta de metricas. Em outros pacotes, source e
ajdt, sao encontrados elementos que fazem referencia a um projeto Java e AspectJ
e transformacoes necessarias, respectivamente. O pacote metrics contem as classes
que implementam as metricas a serem coletadas. A maior parte das alteracoes apli-
cadas ao AopMetrics resultaram em novas classes sendo incluıdas neste pacote. Os
ultimos pacotes, export e results, contem o codigo responsavel por exportar os
resultados da medicao para planilhas em formato XLS e como sao as saıdas das
metricas, quando executadas. A Figura 5.1 mostra as dependencias entre os pacotes
do sistema.
A primeira modificacao para dar suporte aos novos tipos de metricas diz respeito
a como e calculado o valor para cada uma. Normalmente, as medicoes sao execu-
tadas individualmente para cada componente (classe, interface e aspecto). Assim,
6http://aopmetrics.tigris.org/
61
Figura 5.1: Hierarquia de Pacotes do EH-Meter.
cada metrica e coletada uma vez para cada componente sem o valor de um compo-
nente interferir no valor de outro. O resultado total da medicao e o somatorio dos
valores da metrica para cada componente. A metrica DOS, porem, e calculada para
todos os componentes do sistema. Logo, foi necessario levar em conta os valores
relativos a cada componente do sistema para poder fazer o calculo da metrica. Esse
comportamento precisou ser incorporado ao engenho de coleta do AopMetrics, ja
que este e construıdo partindo da suposicao de que todas as metricas podem ser
coletadas de forma independente, para cada componente.
A segunda modificacao diz respeito a listagem de todas as metricas. A classe
Metrics contem um ındice de todas as metricas que devem ser coletadas. Para
o EH-Meter, foram adicionadas as novas metricas implementadas e suas respecti-
vas Strings de identificacao. Ponto comum entre todas as metricas e a interface
MetricsCalculator. Entretanto, essa interface e aplicavel apenas para metricas
que nao precisam ser coletadas globalmente, sendo apenas para calculo em cada
componente. Logo, a ultima modificacao consistiu na criacao de uma interface para
abranger as metricas que sao calculadas utilizando dados de todo o sistema. Essa
interface foi denominada de MetricsCalculatorGeneral e pode ser usada na im-
plementacao de novas metricas com essa caracterıstica. No Trecho de Codigo 5.2 e
apresentada a classe Metrics.java, que contem a lista das metricas que serao exe-
cutadas. Em resumo, o EH-Meter e capaz de medir dois tipos de metricas: metricas
por unidade de compilacao (compilation unit - um arquivo fonte) e metricas gerais.
Uma metrica que medir apenas uma unidade de compilacao, deve implementar a in-
terface MetricsCalculator e para implementar metricas gerais, deve implementar
a interface MetricsCalculatorGeneral.
62
1 package br.upe.dsc.ehmeter.metrics;
23 public class Metrics {
4 // ... mode code
5 public static final MetricsCalculator [] typeMetricsCalculators = {
6 new LinesOfClassCode (),
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 static final MetricsCalculatorGeneral [] typeMetricsGeneral = {
19 new DOS()
20 };
21 // ...
22 }
Figura 5.2: Codigo da Classe Metrics.java
5.2.2 Novas Metricas
Para as novas metricas implementadas, na maioria dos casos foi estendida a classe
ASTVisitor para detectar ocorrencias de trechos de codigo relativos ao tratamento
de excecoes. Esses trechos de codigo na maioria dos casos foram ocorrencias de
blocos try (catch, finally), declaracoes de metodos e blocos de codigo. Para as
metricas de tamanho, os resultados foram obtidos apenas atraves da contagem das
ocorrencias do pedaco de codigo desejado. Para metricas de interesses, interfaces
nao foram consideradas por nao incluırem comportamento, sendo apenas analisadas
classes e aspectos. CDC e CDO foram bem simples, bastando apenas marcar para
cada componente e operacao, respectivamente, a existencia de codigo tratador de
excecoes. Para LOF (medida utilizando DOF) e DOS, apenas foi necessario utilizar
informacoes de outras metricas, como linhas de codigo, linhas de codigo relativas ao
tratamento de excecoes e numero de componentes de cada interesse.
A Metrica CDLOC e a que apresenta a implementacao mais complexa. Essa com-
plexidade decorre da dificuldade de lidar com todos os casos possıveis de transicoes
entre interesses no codigo de um sistema. Em todos os trabalhos anteriores sobre
metricas de separacao de interesses [6, 7, 24, 37], essa metrica foi coletada manual-
mente. Alem disso, nenhuma ferramenta de coleta de metricas estudadas (Metrics,
AOPMetrics e Resource Standard Metrics), mesmo as que realizam medicao de
forma semi-automatica (nas quais o usuario precisa indicar o codigo relativo a cada
63
interesse), como ConcernTagger e AJATO, e capaz de coletar essa metrica. A Fi-
gura 5.3 mostra um exemplo de como sao diferenciadas as areas de transicao entre o
tratamento de excecoes (fundo cinza) e o comportamento normal do sistema (fundo
branco). Na implementacao, foi necessario detectar e marcar essas areas, a fim de
calcular as transicoes. Para essa metrica, tem que ser levados em conta diversos
casos de transicao entre o codigo referente ao tratamento de excecoes e o codigo
relativo ao comportamento normal do sistema. Fatores complicadores incluem a
existencia de diversos blocos de tratamento de excecoes, potencialmente aninhados,
blocos de lacos (while, for), blocos condicionais (if, switch) e situacoes bem
particulares.
Figura 5.3: Transicoes entre os interesses.
5.3 Execucao e Resultados da Ferramenta
Do mesmo modo que a ferramenta AopMetrics, a ferramenta EH-Meter funciona
atraves de tasks do Apache Ant7. Atraves de um arquivo de configuracao XML e
especificado quais serao os programas Java e AspectJ que a ferramenta vai analisar,
7http://ant.apache.org/
64
1 <?xml version="1.0" encoding="UTF -8"?>
2 <project name="run -eh-meter" default="run">
3 <!-- Definic~ao de Propriedades -->
4 <property name="dir.build" value="../ ehmeter" />
5 <property name="dir.work" value="${dir.build}/work" />
6 <property name="dir.librariesEHMeter" value="${dir.build }/libs" />
7 <property name="dir.lib" value="../lib" />
8 <property name="dir.src" value="../src" />
9 <property name="dir.src2" value="../nls" />
10 <!-- Listando bibliotecas para ser usadas -->
11 <path id="classpath.common">
12 <fileset dir="${dir.lib}"> <include name="*.jar" /> </fileset >
13 <fileset dir="${dir.librariesEHMeter}">
14 <include name="*.jar" />
15 </fileset >
16 <fileset dir="../../../ plugins">
17 <include name="*.jar" />
18 </fileset >
19 </path>
20 <!-- Execuc~ao do EH -Meter -->
21 <target name="run" description="Computes metrics on the project.">
22 <taskdef name="ehmeter" classname="br.upe.dsc.ehmeter.EHMeterTask"
23 classpath="${dir.librariesEHMeter }/ehmeter -0.4.1. jar"/>
2425 <ehmeter workdir="${dir.work}" sourcelevel="1.5" export="xls"
26 resultsfile="${dir.work}/metrics -results.xls">
27 <fileset dir="${dir.src}" includes="**/*. java"/>
28 <fileset dir="${dir.src}" includes="**/*.aj"/>
29 <fileset dir="${dir.src2}" includes="**/*. java"/>
30 <fileset dir="${dir.src2}" includes="**/*. aj"/>
31 <classpath refid="classpath.common"/>
32 </ehmeter >
33 </target >
34 </project >
Figura 5.4: Exemplo de um arquivo de configuracao para executar o EH-Meter.
quais as bibliotecas que devem ser utilizadas como referencia, versao da linguagem e
o nome do arquivo de saıda. Um exemplo do arquivo XML que pode ser empregado
e apresentado no Trecho de Codigo da Figura 5.4. Esse trecho de codigo mostra
a definicao da task a ser executada e os parametros necessarios para a execucao e
coleta de metricas.
Arquivo de saıda produzido pela ferramenta e uma planilha eletronica no padrao
do Microsoft Excel (XLS), embora tambem possa ser produzido um arquivo no
padrao XML. Essa planilha contem, para cada componente do sistema, o valor de
cada uma das metricas, descritas na Secao 5.1, assim como os valores para o sistema
inteiro. Como dito anteriormente, a excecao e a metrica DOS, que depende do
65
sistema completo e, por isso, nao 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 metricas apresentam um valor para cada componente,
enquanto DOS so apresenta um valor geral, para todo o sistema.
Figura 5.5: Resultado das Metricas Coletadas.
5.4 Avaliacao
Existem algumas ferramentas para coletar metricas e avaliar atributos de quali-
dade do software. As metricas expressam uma avaliacao quantitativa para ajudar
a tomada de decisoes estrategicas sobre como atividades serao realizadas, o mo-
nitoramento do progresso durante o desenvolvimento do software e o controle de
qualidade do produto. Nesse contexto, a automatizacao e muito importante para
acelerar o processo de medicao e prover resultados consistentes e uniformes. Entre-
tanto, e difıcil coletar metricas para interesses de forma automatizada. Por isso, as
ferramentas existentes capazes de medir programas orientados a aspectos de forma
automatica coletam apenas metricas gerais. EH-Meter sacrifica a generalidade, a
fim de automatizar a medicao de um interesse especıfico: tratamento de excecoes.
Nessa secao e descrita uma avaliacao do EH-Meter. Ele foi comparado com ou-
tras ferramentas de coleta de metricas usando como principal criterio a economia
de tempo para coletar metricas de tratamento de excecoes. Como dito anterior-
mente, EH-Meter tambem foi utilizada para apoiar os estudos empıricos descritos
nos Capıtulos 3, e 4,.
5.4.1 Comparando Abordagens de Medicoes
Foram feitos testes comparativos para avaliar os benefıcios obtidos a partir de uma
abordagem de medicao baseada no EH-Meter. Inicialmente, foram verificados os
tempos gastos para coletar metricas especificamente para o tratamento de excecoes,
66
utilizando tres abordagens diferentes. A primeira consiste na coleta manual das
metricas. A segunda e a terceiras foram parcialmente e completamente automa-
tizadas, utilizando o ConcernTagger e o EH-Meter, respectivamente. Tres versoes
de um sistema usado no estudo de caso foram escolhidas para comparar as coletas
de metricas. A utilizada foi o JHotDraw, apresentado na Secao 3.2 do Capıtulo 3.
A comparacao envolveu apenas as metricas de interesses, mais especificamente em
CDC, CDO e CDLOC, ja que algumas ferramentas existentes apoiam a coleta delas.
A Tabela 5.2 apresenta os resultados obtidos. As colunas apresentam a aborda-
gem de coleta de metricas adotada e as linhas apresentam as versoes dos sistemas. Os
numeros na tabela indicam os tempo (em minutos) necessarios para fazer a medicao
usando cada abordagem. N/A indica que nao foi possıvel colher a metrica para
essa versao, com a referida abordagem.
Manual ConcernTagger EH-Meter
Codigo Original 10 15 1
Versao Ref. OO 10 15 1
Versao Ref. AO 10 N/A 1
Tabela 5.2: Comparativo de coleta de metricas. Os numeros representam o tempo,
em minutos.
Os resultados mostram que EH-Meter foi mais eficiente do que os outros meios
de coletas de metricas abordados. A Coleta manual obteve melhores resultados
do que a ferramenta ConcernTagger, mas a coleta manual e bem mais sucetıvel a
erros. Outra questao importante e que ConcernTagger nao pode coletar a metrica
CDLOC, pois e necessario analisar o programa linha a linha e o ConcernTagger nao
implementa essa funcionalidade. Adicionalmente, o ConcernTagger nao consegue
fazer a medicao de programas em AspectJ, somente classes Java.
Uma questao que tem que ser deixada clara e que essa comparacao foi realizada
apenas uma vez. Em caso de necessidade de re-coletar as metricas, devido a alguma
modificacao, a coleta manual pode ser mais onerosa do que o ConcernTagger. O
processo de medicao usando esta ultima envolve a marcacao manual dos trechos de
codigo relativos a cada interesse, mas essa marcacao so precisa ser realizada uma
vez. Ja na medicao manual, e necessario identificar as transicoes entre interesses toda
vez que for necessario medir CDLOC. Alem disso, e importante enfatizar que o EH-
Meter nao e capaz de coletar metricas para qualquer interesse alem de tratamento
de excecoes, o que limita o seu escopo de aplicacao.
67
5.5 Conclusao
Neste capıtulo foi apresentada a ferramenta EH-Meter, que implementa metricas
especıficas de tratamento de excecoes. Foram descritas as metricas 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 metricas tanto a
partir de programas escritos em Java quanto de programas em AspectJ. Ate onde
se pode averiguar, o EH-Meter e a primeira ferramenta capaz de coletar metricas
para um interesse especıfico de forma completamente automatica.
Uma possıvel extensao da ferramenta EH-Meter e a possibilidade de sugerir opor-
tunidades de reuso, procurando inicialmente por codigo duplicado. Assim, alem de
fazer a coleta de metricas, poderia tambem sugerir melhorias de codigo a fim de
melhorar os valores das mesmas com o codigo mais reusavel. A ferramenta EH-
Meter esta disponıvel no endereco http://www.cin.ufpe.br/∼fjclf/eh-meter.
No mesmo endereco tambem esta disponıvel o codigo fonte e tambem outras in-
formacoes. A licenca do EH-Meter e a GPL.
68
Capıtulo 6
Conclusoes e Trabalhos Futuros
Neste trabalho foi abordado o reuso de codigo referente ao tratamento de excecoes,
quando esse codigo e modularizado atraves de aspectos. Foram analisadas duas
situacoes, atraves de dois estudos diferentes: reuso intra-aplicacao e reuso inter-
aplicacao.
O primeiro estudo abordou reuso intra-aplicacao (Capıtulo 3), ou seja, aborda o
reuso de codigo de tratadores de excecoes dentro de uma mesma aplicacao. Foram
utilizados tres sistemas relevantes na industria, com tamanho e atributos inter-
nos que proporcionaram um resultado significativo. Foram utilizadas onze metricas
de software para avaliar como o emprego de diferentes abordagens para a imple-
mentacao de tratadores afetou o reuso. O principal resultado foi a confirmacao de
que o uso de Programacao Orientada a Aspectos (POA) promove o reuso, dentro de
uma mesma aplicacao. Esses resultados complementaram os resultados de Lippert
e Lopes [30] e contradisseram em parte o resultado de Castor et al. [6], em relacao
a possibilidade de reuso de codigo de tratamento de excecoes. Tal estudo tambem
confirmou estudos anteriores que afirmam que POA promove uma boa separacao
textual de codigo relativo ao interesse tratamento de excecoes.
O segundo estudo abordou o reuso inter-aplicacao (Capıtulo 4), ou seja, o reuso
de tratadores de excecoes entre aplicacoes diferentes. Para esse outro estudo foram
utilizados sete sistemas, com tamanhos em LOC, numero de tratadores e outras
caracterısticas que tambem foram levadas em consideracao em relacao 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 codigo de tratamento de excecoes, ou seja, quando aplicacoes diferentes
estao envolvidas, poucas situacoes de reuso foram encontradas. A situacao onde a
maior quantidade de reuso foi obtida aplicou-se apenas a tratadores triviais, com
69
nao mais que uma linha de codigo, alem de exigir modificacoes ao codigo original,
com implementacoes 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 metricas especıficas para o inter-
esse tratamento de excecoes. Embora esse interesse seja facil de ser identificado
no codigo, a medicao de diversos sistemas nao-triviais e uma tarefa demorada e
trabalhosa e, consequentemente, passıvel de erro. A ferramenta automatiza esse
processo, facilitando o processo de medicao e evitando distorcoes devido a diferentes
abordagens de medicao.
6.1 Publicacoes Resultantes
Foram publicados tres trabalhos com resultado do esforco desta pesquisa. A primeira
publicacao foi referente ao estudo apresentado no Capıtulo 3, onde foi avaliado o
reuso de codigo de tratamento de excecoes intra-aplicacao. O mesmo foi publicado
no XXIII Simposio 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 programacao orientada a aspectos (POA) para modularizar codigo de
tratamento de excecoes. O artigo descreve um novo estudo cujo objetivo e respon-
der se aspectos realmente promovem a implementacao de tratamento de excecoes
reusavel. 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 codigo de tratamento de excecoes e extraıdo para aspectos.
A segunda publicacao foi referente a ferramenta desenvolvida durante o trabalho
de avaliacao de reuso. O artigo aborda nao apenas a ferramenta EH-Meter, como
tambem a ideia de desenvolver ferramenta para coleta de metricas especıficas para
um determinado interesse. Esse trabalho foi apresentado no Capıtulo 5. O mesmo
foi publicado no 3o 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 publicacao se refere ao estudo de reuso inter-aplicacao, apresentado
no Capıtulo 4. Esse artigo apresenta como foi aplicado o reuso entre sete aplicacoes
diferentes. E uma continuacao do estudo referente ao reuso intra-aplicacao, porem
abordando apenas versoes com os tratadores de excecoes 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 Conferencia de
70
Aspect-Oriented Software Development, e esta aguardando resultado da avaliacao
pelo comite de programa.
6.2 Trabalhos Futuros
Os resultados e limitacoes deste trabalho apontam para outros trabalhos a serem
desenvolvidos no futuro.
O primeiro diz respeito a reusar codigo de versoes diferentes de um mesmo sis-
tema. Neste caso, a ideia e avaliar se tratadores de excecoes modularizados atraves
de aspectos podem ser reusados entre versoes diferentes de um mesmo sistema e ate
que ponto. O segundo diz respeito a modularizacao do tratamento de excecoes de
aplicacoes desde o inıcio do seu desenvolvimento. Seria interessante ver os resulta-
dos de uma aplicacao cujo codigo de tratamento de excecoes e projetado para ser
reusado.
Tambem seria interessante a criacao de um catalogo de cenarios de reuso. As-
sim, com estudos ja realizados, junto com outros que ainda serao realizados, esse
catalogo poderia ser um resumo de todo o conhecimento obtido ao longo dessa serie
de estudos. Com esse catalogo ficaria mais facil fazer uma ferramenta de sugestoes
de reuso e ate mesmo uma capaz de refatorar tratadores de forma automatica, de
modo a maximizar o reuso.
Um outro trabalho e avaliar ate que ponto os mecanismos providos por dife-
rentes linguagens orientadas a aspectos auxiliariam ou nao o reuso de tratadores de
excecoes. Uma abordagem interessante seria um comparativo de linguagens como
CesarJ1, EJFlow [4] e alguma outra linguagem com suporte a Pontos de Juncao
Explıcitos [25] para avaliar a influencia dos mecanismo no reuso de tratadores de
excecoes.
1scriptsizehttp://www.caesarj.org/
71
Referencias
[1] Carlos Andrade, Andre Santos, and Paulo Borba. Aspecth: Uma extensao
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] Nelio 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] Nelio 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] Nelio Cacho, Claudio 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, Uira 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, Nelio Ca-
cho, Uira 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] Cesar Francisco de Moura Couto, Jaqueline Faria, and Marco Tulio Valente.
Estimativa de metricas de separacao de interesses em processos de refatoracao
para extracao de aspectos. In VI Workshop de Manutencao 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, Nelio Cacho, Claudio Sant’Anna, M. Monteiro, Uira Ku-
lesza, Alessandro Garcia, Sergio 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] Claudio 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 Programacao, 5a ed. Bookman,
Sao Paulo, Brasil, 2003.
[39] Yan Sommerville. Engenharia de Software, 8a edicao. Pearson Adson Wesley,
Sao 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] Julio Cesar Taveira, Hitalo Oliveira, Fernando Castor, and Sergio Soares. On
inter-application reuse of exception handling aspects. In Submited to Empirical
Evaluation of Software Composition Techniques (ESCOT 2010), 2010.
[42] Julio Cesar Taveira, Cristiane Queiroz, Romulo Lima, Juliana Saraiva, Fer-
nando Castor, Sergio Soares, Hıtalo Oliveira, Nathalia Temudo, Emanuel Bar-
reiros, Amanda Araujo, and Jefferson Amorim. Assessing intra-application
75
exception handling reuse with aspects. In XXIII Simposio Brasileiro de Engen-
haria de Software - SBES’2009, October 2009.
[43] Julio Cesar Taveira, Juliana Saraiva, Fernando Castor, and Sergio 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çãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo