Research > Internet & Technology, programação orientada à aspectos e reengenharia de software">
Phoenix: Uma Abordagem para Reengenharia de Software Orientada A Aspectos
Phoenix: Uma Abordagem para Reengenharia de Software Orientada A Aspectos
Phoenix: Uma Abordagem para Reengenharia de Software Orientada A Aspectos
São Carlos
Março de 2005
Universidade Federal de São Carlos
Centro de Ciências Exatas e de Tecnologia
Programa de Pós Graduação em Ciência da Computação
São Carlos
Março de 2005
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
"#$%&!$&'&()*+,-#$&!.(&/)+&0&!1.()!2.34!0&!
5#/(#)'.$&!6)789#',+#&!0&!:";6&+!
!
! !
! "'()*'+!,*-.)*/0!1'(23034!
"#$%&'! !!!!!56789:;<!/='!'>3(2'?@=!&'('!(@@-?@-A'(*'!2@!
03BCD'(@!3(*@-C'2'!'!'0&@)C30!E!,*-.)*/0!1'(2303!"'()*'4!FF!
GH3!1'(I30!<!JKG1'(+!#LLM4!
!!!!!$$N!&4!
!
!
!!!!!O*00@(C'PH3!QR@0C('23S!!FF!J-*T@(0*2'2@!K@2@('I!2@!GH3!
1'(I30+!#LLM4!!
!!
!!!!!$4!8-?@-A'(*'!2@!03BCD'(@4!#4!U@@-?@-A'(*'!3(*@-C'2'!'!
3>V@C34!W4!G*0C@='0!2@!C('-0B3(='PH3!2@!03BCD'(@4!:4!X.C/I34!
!
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1OO<!LLM4$!Q#L'S!
!
! !
!
Dedico esta dissertação a DEUS e Nossa Senhora,
a meus pais e minha irmã, cujo exemplo de honestidade e
trabalho tem sido um norteador para a minha vida,
que sempre me deram apoio nos momentos mais difíceis,
vocês me ensinaram a simplicidade de ter esperança.
Agradecimentos
Ao longo destes anos muitos foram os que contribuíram para a realização deste projeto. Gos-
taria de destacar aqui alguns, não necessariamente os mais importantes, mas os essenciais para a
consolidação desta conquista. Inicialmente quero agradecer a Deus e a Nossa Senhora pela opor-
tunidade e capacidade de aprender e onde eu sempre busquei forças e coragem para enfrentar os
desafios e buscar meus sonhos, nunca deixando que eu me abatesse pelas quedas e tristezas durante
a caminhada.
Ao professor Dr. Antonio Francisco do Prado, pela orientação e incentivo, pelos ensinamentos,
amizade e principalmente pela confiança depositada em mim durante este longo período desde o
projeto RHAE/CNPq até o ingresso no mestrado e pelas inúmeras discussões, nem sempre sobre
os mesmos pontos de vista, mas que contribuíram significativamente para a minha formação como
pesquisador e como pessoa, o meu muitíssimo obrigado.
Ao professor Dr. Roberto Bigonha e à professora Dra. Rosana Braga pelos comentários e
sugestões durante a defesa da dissertação.
Ao amigo Daniel Lucrédio por estar sempre disposto a ajudar e discutir novas idéias e pro-
jetos, pelo companheirismo e pelos inúmeros momentos de descontração; à amiga Val Fontanette
pelas inúmeras traduções e auxílio no inglês, discussões sobre reengenharia, pelo acolhimento,
hospitalidade e grande ajuda durante minha chegada em São Carlos; e a João “Pelão” por partilhar
diversas opiniões e ajuda em diversos momentos.
A Eduardo Kessler Piveta pelas inúmeras discussões, idéias e pela parceria em diversos traba-
lhos e publicações. I shall not forget to thank Jim Coplien. He did an outstanding work, guiding
me and making me understand what patterns are really about.
Aos amigos do mestrado, em especial Dinho, Érico, Escovar, Evandro, Fabiana, Bocudo,
Genta, Jessica, Jukinha, Mairum, Raquel, Taciana e outros, pelos excelentes momentos nos chur-
rascos, festas de boas vindas e de despedidas, nas inúmeras “baladas”, pelo tereré na hora do
almoço e por tudo mais. Agradeço também ter participado do glorioso SSS - Saravá Saci Soccer,
o melhor time de futsal do PPG-CC de todos os tempos, campeão do InterAnos da Computação.
Aos companheiros de todas as horas e para todas as viagens (Ouro Preto, Ibitinga, Ribeirão,
Araraquara...) e por todas as outras ainda por viajar, Renato Claudino, Ricardo Argenton Ramos
(RAR) e Wesley “Bel” Thereza.
Às amizades feitas em São Carlos, em especial André Rocha, Aninha e família Maricondi,
Bira, Bruno (Negão), Cecília, Dani, Érika, Kamei, Roberta, Tais Calliero, Vê e Wanessa.
Aos meus amigos-irmãos, que conviveram comigo todo este período de lutas e vitórias, sempre
presentes mesmo estando a milhares de quilômetros de distância, em especial Déa, Bruninha,
Duda, Fefeu, Gilberto, Luciano “Bizonho”, Luciano “Padang”, Mara, Márcio “Chêpa”, Marcus
“Manga”, Paulo Marcelo, Rogério, Tiago “Xuba” e toda galera da APEBA; e à eterna galera do
Villa (Fenícia e Etruska). A vocês eu tenho o seguinte a dizer: “Às vezes a gente corre tanto pela
vida e deixa passar tantas coisas bonitas... A gente corre tanto que não percebe as coisas, as flores
na beirada do caminho. Às vezes a gente quer que o fruto amadureça antes do tempo. A gente tem
muita pressa, mas somente o tempo sabe dar as coisas para a gente na hora certa. O tempo sabe
o momento exato de dar o presente que a gente merece.”
Ao grande amigo Eduardo Almeida, companheiro desde a graduação, por participar de mais
uma vitória, pelas noites em claro viajando pelo país, nos aeroportos, nas viagens sempre corridas
e cheias de entraves na hora de voltar para casa, pelas discussões sobre projetos, perspectivas e
caminhos a seguir. O seu apoio foi fundamental por todo o período da graduação, mestrado e num
futuro próximo, o doutorado.
A Danielle Irina Shiratori, minha namorada, pela paciência em ouvir minhas queixas e desa-
bafos, por participar de “diálogos” sobre técnicas de reengenharia, refactoring, aspect mining e
aspectos, por estar sempre presente quando eu precisei e por entender a loucura que é a vida de um
estudante de mestrado, sem a sua compreensão, incentivo, carinho e apoio, a conclusão e o sucesso
deste trabalho não seria possível.
Aos meus pais, a minha irmã e minha família que não pouparam esforços para me incentivar,
pelo amor, carinho, e cujo suporte foi essencial para o desenvolvimento deste. É por vocês que
eu procuro sempre mais. Com certeza este trabalho deve-se muito a todo esse amor. Amo todos
vocês.
The continuous technological evolution makes many systems become obsolete due to chan-
ges in hardware and software platforms, although the fact that they attend their requirements and
that they are stable. Software reengineering, integrated with modern techniques of reverse and
forward engineering, can be the solution to reconstruct these systems reusing the knowledge em-
bedded in the code and the available documentation. Even when current reengineering techniques
are used, some problems regarding the legibility of the code are found in the reconstructed sys-
tems. Recently developed systems making use of modern techniques for object oriented analysis,
design and implementation using software patterns also have these problems. Thus, motivated
by the ideas of a better solution to improve systems codes legibility that have already been built,
we intend to investigate an approach to rebuild such systems, obtaining their project and code
restructured in a more readable and organized way. The approach combines reverse engineering
techniques, component-based modeling, software transformation, and Aspect-Oriented Program-
ming to reconstruct software systems from legacy code and available documentation. The code
and the documentation of the reconstructed system are structured according to Aspect-Orientation,
which facilitates its maintenance and continuous evolution and complies with new hardware and
software technologies. The main mechanisms for the execution of the approach are a Transforma-
tional System and a CASE tool, which automates most of the software engineer tasks.
Lista de Figuras
41 ClockAspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
42 Transformação AspectJ2XMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1 Designadores primitivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3 Operadores lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1 Introdução 15
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Reengenharia de Software 19
2.1.1 A terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 XSimulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Referências 107
Apêndice A 117
Prêmio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Publicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
15
1 Introdução
1.1 Contextualização
Atualmente, existe um grande número de empresas que continuam trabalhando com sistemas
implementados em linguagens de programação antigas, cuja manutenção é árdua e onerosa.
A dificuldade em atualizar esses sistemas para a utilização de novas tecnologias, como distri-
buição e componentização, tem motivado os pesquisadores a investigar soluções que diminuam os
custos de desenvolvimento, prolonguem o tempo de vida útil do sistema, e facilitem a sua evolução
e manutenção (BAXTER; PIDGEON, 1997; GAMMA et al., 1995; NEIGHBORS, 1983).
Além dessas técnicas, vem ganhando destaque o uso de ferramentas CASE (Computer-Aided
Software Engineering) no projeto ou reprojeto de sistemas a serem reconstruídos. Uma ferramenta
CASE que possui características importantes para este projeto de pesquisa é a MVCASE. A MV-
CASE, objeto de outro projeto de pesquisa (ALMEIDA et al., 2002a; LUCRÉDIO, 2005), além de
apoiar a especificação do sistema em linguagens de modelagem orientadas a objetos, gera código
automaticamente em uma linguagem de programação orientada a objetos, a partir das especifica-
ções em alto nível, usando componentes distribuídos.
(HARRISON; OSSHER, 1993), (KICZALES et al., 1997), (TARR et al., 1999). As limitações associadas
à Orientação a Objetos, como, por exemplo, o entrelaçamento e o espalhamento de código com
diferentes interesses, são apontadas atualmente como o principal problema da manutenção dos sis-
temas (OSSHER; TARR, 1999). Algumas dessas limitações podem ser atenuadas com a utilização
dos padrões de software propostos por Gamma (1995). Entretanto, algumas extensões do para-
digma orientado a objetos são propostas para solucionar estas limitações, como, por exemplo, Pro-
gramação Adaptativa (LIEBERHERR; SILVA-LEPE; XAIO, 1994), Programação Orientada a Assunto
(OSSHER; TARR, 1999) e Programação Orientada a Aspectos (ELRAD; FILMAN; BADER, 2001b). Es-
sas técnicas de programação visam aumentar a modularidade, onde a Orientação a Objetos e os
padrões de software não oferecem o suporte adequado.
Dessa forma, mesmo tendo-se recuperado o projeto do sistema legado em um alto nível de
abstração, permitindo ao Engenheiro de Software ter uma visão legível da funcionalidade do sis-
tema, a sua manutenção muitas vezes, ainda é uma tarefa árdua e difícil, podendo comprometer
sua evolução para acompanhar as novas tecnologias de hardware e software.
Motivado por estas idéias, esta dissertação tem por objetivo pesquisar uma abordagem que
ofereça recursos para contornar essas limitações, encontradas no código do sistema reimplemen-
tado de acordo com o paradigma orientado a objetos, e não contempladas atualmente nas técnicas
de reengenharia de software e encontradas nos sistemas mais recentes.
A dissertação está organizada em seis capítulos, além da seção referente às referências biblio-
gráficas. O primeiro capítulo contém esta introdução.
18
No Capítulo 3 é apresentada uma visão geral do paradigma orientado a aspectos, bem como
são descritas as características fundamentais da linguagem AspectJ e das suas construções. São
apresentadas também as direções na pesquisa de projetos de software orientados a aspectos.
2 Reengenharia de Software
Para resolver este problema, Visaggio (2001) apresenta algumas evidências experimentais de
que o processo de Reengenharia pode diminuir alguns sintomas do envelhecimento. Entretanto,
mesmo reconstruindo o sistema legado, não há nenhuma garantia que o novo sistema terá uma
maior/melhor manutenibilidade do que antes. Por exemplo, a Orientação a Objetos, muitas vezes
considerada a “solução para a manutenção” (BENNETT; RAJLICH, 2000), criou novos problemas
para a mesma (OSSHER; TARR, 1999) e deve ser usada com muito cuidado para assegurar que a
manutenção não será mais problemática do que nos sistemas legados tradicionais.
Neste contexto, este capítulo é dedicado à Reengenharia de Software, um dos tópicos essen-
ciais para a realização da abordagem apresentada nesta dissertação. Assim, ele está organizado
como se segue: a Seção 2.1 apresenta uma visão geral dos conceitos de Reengenharia de Software
e engenharia reversa. Em seguida, a Seção 2.2 apresenta uma análise sobre os principais trabalhos
em Reengenharia e Engenharia Reversa, tentando estabelecer um relacionamento entre elas e as
novas linhas de pesquisa e, finalmente, a Seção 2.3 apresenta as considerações finais.
20
De acordo com a literatura (BENNETT; RAJLICH, 2000; BIANCHI et al., 2003; OLSEM, 1998;
SNEED, 1995), a Reengenharia possui quatro objetivos, a saber:
ii. Migração: a Reengenharia pode ser usada para migrar o software para um ambiente ope-
racional melhor ou menos custoso. Também pode converter sistemas implementados em antigas
linguagens de programação em sistemas implementados em modernas linguagens que oferecem
mais recursos ou uma melhor flexibilidade;
iii. Obter maior confiabilidade: são necessários extensivos testes para demonstrar uma equi-
valência funcional que irá identificar antigos erros que tem afetado o software. A reestruturação
revela potenciais defeitos. Esse objetivo pode ser medido prontamente pela análise de erros;
iv. Preparação para melhorias funcionais: decompor o sistema em módulos menores, aper-
feiçoando a sua estrutura e isolando um módulo dos outros, tornando mais fácil realizar modifica-
ções ou adicionar novas funcionalidades sem afetar outros módulos.
2.1.1 A terminologia
A partir dos relacionamentos da Figura 1 pode-se notar que a direção seguida pela Engenharia
Avante (Forward Engineering), vai do nível de abstração mais alto para o mais baixo. Nota-se
também que a Engenharia Reversa (Reverse Engineering) percorre o caminho inverso, podendo
utilizar-se da Redocumentação (Redocumentation) para melhorar o nível de abstração. A Reenge-
nharia (Reengineering) geralmente inclui uma Engenharia Reversa, seguida de alguma forma de
Engenharia Avante ou Reestruturação (Restructuring).
22
A Engenharia Reversa deve produzir, de forma mais automática possível, uma documentação
que possibilite ao Engenheiro de Software um maior entendimento sobre o sistema, auxiliando
assim na sua manutenção, reutilização, teste e controle de qualidade. Nos últimos dez anos, as
pesquisas em Engenharia Reversa produziram um número de estudos para análise de código, in-
cluindo a decomposição em subsistemas (UMAR, 1997), sintetização de conceitos (BIGGERSTAFF;
MITBANDER; WEBSTER, 1994), projeto, programação e utilização de padrões (GAMMA et al., 1995;
STEVENS; POOLEY, 1998), análise de dependências estáticas e dinâmicas (SYSTA, 1999), métri-
cas orientadas a objetos (CHIDAMBER; KEMERER, 1994), componentização (ALVARO et al., 2003)
entre outros. No geral, estas análises foram bem sucedidas ao tratar o software no nível sintá-
tico, dirigindo-se à necessidade de informações específicas e para transpor pequenas diferenças de
informação.
O processo começa com uma fase de análise. Durante esta fase, o sistema legado pode ser
analisado por meio de ferramentas para obter as informações do sistema (projeto, especificações
ou diagramas arquiteturais). Os Engenheiros trabalham em nível de código para, a partir de então,
recuperar o projeto do sistema. Toda informação obtida deve ser armazenada preferencialmente
em diagramas que estejam em um alto nível de abstração.
A palavra-chave do final dos anos 80 e início dos anos 90 era a Orientação a Objetos. O
paradigma orientado a objetos oferece algumas características desejáveis, que ajudam significa-
tivamente na melhoria do reuso de software. Esta foi a tendência predominante do software dos
anos 90. De acordo com a literatura, a Orientação a Objetos deveria aumentar a manutenibilidade,
reduzir a taxa de erros, aumentar a produtividade e tornar “o mundo do processamento de dados
um lugar melhor para se viver” (MEYER, 1997).
A idéia de aplicar Engenharia Reversa orientada a objetos é que o Engenheiro de Software pode
obter o projeto de um sistema existente de uma forma simplificada e com esforços limitados. Com
o projeto, o Engenheiro de Software pode analisar sobre onde a modificação deve ser realizada,
sua extensão, e como será mapeada no sistema existente. Além disso, o novo projeto orientado a
25
objetos pode servir como base para um projeto futuro de desenvolvimento. As extensões podem
ser projetadas como adições fora dos sistemas existentes.
O primeiro trabalho relevante envolvendo a tecnologia orientada a objetos foi desenvolvido por
Jacobson e Lindstron (JACOBSON; LINDSTROM, 1991), que apresentam uma técnica para efetuar a
Reengenharia de sistemas legados, implementados em uma linguagem procedimental como C ou
Cobol, obtendo sistemas orientados a objetos. Os autores mostram como realizar a Reengenharia
de forma gradual, pois consideram impraticável substituir um sistema antigo por um completa-
mente novo (o que exigiria muitos recursos). Consideram três cenários diferentes: no primeiro se
faz mudança de implementação sem mudança de funcionalidade; no segundo se faz a mudança
parcial da implementação sem mudança de funcionalidade; e no terceiro se faz alguma mudança
na funcionalidade. A Orientação a Objetos foi usada para garantir a modularidade. Os autores uti-
lizaram uma ferramenta CASE específica e defendem a idéia de que os processos de Reengenharia
devem focar o uso de ferramentas para auxiliar o Engenheiro de Software. Eles também afirmam
que a Reengenharia deve ser incorporada como parte do processo de desenvolvimento de software,
ao invés de ser um substituto para ele.
Gall e Klösh (GALL; KLÖSCH, 1994) afirmam que a transformação de programas procedimen-
tais em programas orientados a objetos é um processo importante para aumentar o potencial de
reuso dos programas procedimentais, mas que existem problemas difíceis de se resolver no pa-
radigma procedural, como é o caso da interconexão de módulos. Relatam que o reuso está assu-
mindo papel relevante na produção industrial de software, pois reduz os custos de desenvolvimento
de software e melhora a qualidade do produto final. Os autores propõem um processo de trans-
formação, denominado método COREM (Capsule Oriented Reverse Engineering Method) (GALL;
KLÖSCH, 1993), que usa o conhecimento do domínio da aplicação. Esse método consiste em qua-
tro passos principais: recuperação do projeto, modelagem da aplicação, mapeamento dos objetos
e transformação do sistema. Embora a aplicação de ferramentas seja útil e necessária durante o
processo de transformação COREM, é imprescindível a aquisição de conhecimento adicional pelo
Engenheiro de Software. Portanto, a automação completa desse processo de transformação não é
possível, mas muitos passos do processo podem ser auxiliados por ferramentas.
Yeh, Harris e Reubenstein (YEH; HARRIS; REUBENSTEIN, 1995) propõem uma abordagem mais
conservadora baseada não apenas na busca dos objetos, mas dirigida para encontrar tipos de dados
abstratos (ADTs: abstract data types). A abordagem, chamada OBAD, é encapsulada por uma
ferramenta, que usa um grafo de dependência de dados entre procedimentos e os tipos de estrutura
como um ponto de início para a seleção de candidatos a ADTs. Os procedimentos e os tipos de
estrutura são os nós do grafo, e as referências entre os procedimentos e os campos internos são as
bordas. O conjunto de componentes conectados neste grafo formam o conjunto de candidatos a
26
ADTs.
Em 1995, Wilkening e outros (WILKENING et al., 1995) apresentaram um processo para efe-
tuar a Reengenharia de sistemas legados, utilizando partes de sua implementação e projeto. Esse
processo inicia-se com a reestruturação preliminar do código fonte, para introduzir algumas me-
lhorias, como remoção de construções não-estruturadas, código “morto” e tipos implícitos. A
finalidade dessa reestruturação preliminar é produzir um programa fonte mais fácil de analisar,
entender e reestruturar. Em seguida, o código fonte produzido é analisado e são construídas suas
representações em alto nível de abstração. Com base nessas representações, pode-se prosseguir
com os passos de reestruturação, reprojeto e redocumentação, que são repetidos quantas vezes fo-
rem necessárias para se obter o sistema totalmente reestruturado. Pode-se, então, implementar o
programa na linguagem destino e dar seqüência aos testes que verificarão se a funcionalidade não
foi afetada.
Para transformar programas de uma estrutura procedural para orientada a objetos, pressupõem-
se que os programas são estruturados e modulares, caso contrário, não podem ser transformados.
Entende-se por programas estruturados, programas que não possuem nenhum “GOTO” como ra-
mificações de um segmento de código a outro, por exemplo. Modulares significa que os programas
estão encapsulados em uma hierarquia de segmentos de código, cada um com uma única entrada e
uma única saída. Os segmentos ou procedimentos devem corresponder às operações elementares
do programa. Cada operação deve ser acessível pela invocação de uma rotina de um nível mais
elevado (SNEED, 1995). O outro pré-requisito é estabelecer uma árvore de chamadas de procedi-
mentos para a hierarquia de sub-rotinas, de modo que todas as sub-rotinas sejam incluídas como
parte do procedimento, com suas respectivas chamadas ou execuções.
Assim como Wilkening e outros, Sneed assume como pré-requisitos para a Reengenharia ori-
entada a objetos a estruturação e modularização dos programas. Entretanto, Sneed defende a
existência de uma árvore de chamadas do sistema, para identificar as chamadas a procedimentos
27
Para solucionar este problema, diversos autores sugerem encapsular (wrapping) o sistema le-
gado, e considerá-lo como um componente caixa-preta a ser submetido à Reengenharia. Devido à
natureza iterativa deste processo de Reengenharia, durante sua execução o sistema incluirá tanto os
componentes da Reengenharia como os componentes legados, coexistindo e cooperando a fim de
assegurar a continuidade do sistema. Finalmente, todas as atividades da manutenção, se requeridas,
têm que ser realizadas tanto nos componentes da Reengenharia quanto nos legados.
O primeiro trabalho sobre processos iterativos foi proposto por Olsem (OLSEM, 1998). De
acordo com o autor, sistemas legados são formados por quatro classes de componentes (Softwa-
re/Aplicações, Arquivo de Dados, Plataformas e Interfaces), que não podem ser tratados da mesma
forma. A Reengenharia incremental proposta pelo autor efetua o processo em componentes sepa-
rados, utilizando estratégias diferentes para cada classe de componentes, diminuindo as probabili-
28
Em 2003, Bianchi e outros (BIANCHI et al., 2003) apresentaram um modelo iterativo para a
Reengenharia de sistemas legados. Como inovações do processo proposto pode-se citar: a Reen-
genharia é gradual, isto é, é executada iterativamente em componentes diferentes (dados e funções)
em fases diferentes; durante a execução do processo haverá coexistência entre os componentes le-
gados, componentes submetidos à Reengenharia, componentes que já passaram pela Reengenharia
e os novos componentes, adicionados ao sistema para satisfazer novos requisitos funcionais.
Existem diversos benefícios associados aos processos iterativos: usando técnicas de “divide et
impera” (“dividir para conquistar”), onde o problema é dividido em unidades menores, que são
mais fáceis de manipular, os resultados e o retorno do investimento são imediatos e concretos; os
riscos associados ao processo são reduzidos; os erros são mais fáceis de encontrar e corrigir, não
põe-se todo o sistema em risco; e garante-se que o sistema continuará a funcionar mesmo durante a
execução do processo, preservando a familiaridade dos mantenedores e dos usuários com o sistema
(BIANCHI; CAIVANO; VISAGGIO, 2000).
29
Hoje, no topo das técnicas orientadas a objetos, está sendo estabelecida uma camada adicional
no desenvolvimento de software, a baseada em componentes. Os objetivos do “componentware”
são muito similares àqueles da Orientação a Objetos: o reuso de software deve ser facilitado e
melhorado, para assim o software se tornar mais confiável e menos custoso (LEE et al., 2003).
Entre os primeiros trabalhos de pesquisa nesta direção, Caldiera e Basili (CALDIERA; BASILI,
1991) exploram a extração automatizada de componentes de software reutilizáveis de sistemas
existentes. Os autores propõem um processo que seja dividido em duas fases. Primeiramente,
são escolhidos, no sistema existente, alguns candidatos e empacotados para um possível uso inde-
pendente. Em seguida, um engenheiro com conhecimento do domínio da aplicação analisa cada
componente para determinar os serviços que eles podem oferecer. A abordagem é baseada em
modelos e em métricas de software.
Anos mais tarde, Neighbors (NEIGHBORS, 1996) apresentou uma pesquisa informal, realizada
em um período de 12 anos, de 1980 a 1992, com entrevistas e a análise de sistemas legados, em
uma tentativa de fornecer uma abordagem para a extração de componentes reutilizáveis. Embora
o artigo não apresente idéias conclusivas, dá diversos indícios importantes a respeito de gran-
des sistemas. Conseqüentemente, as tentativas de dividir um sistema de acordo com uma destas
abordagens não terão sucesso. A melhor divisão é a idéia dos subsistemas, que são encapsulados
convenientemente aos programadores, aos mantenedores e aos gerentes do sistema. A etapa se-
guinte é extraí-los na forma de componentes reutilizáveis, que podem ser executados manualmente
ou automaticamente.
Outro trabalho envolvendo componentes de software e Reengenharia pode ser visto em (AL-
VARO et al., 2003) no qual é apresentado um ambiente para a Reengenharia de Software Baseada
em Componentes chamado Orion-RE. O ambiente utiliza técnicas de Reengenharia de Software e
de Desenvolvimento Baseado em Componentes (DBC) para reconstruir sistemas legados, reutili-
zando a documentação disponível e o conhecimento embutido em seu código fonte. Um modelo de
processo de software guia a utilização do ambiente por meio de uma Engenharia Reversa para re-
30
cuperar o projeto do sistema legado, e de uma engenharia avante no qual o sistema é reconstruído
usando modernas técnicas de engenharia de software como, por exemplo, padrões, frameworks,
técnicas de DBC e middleware. Como pontos positivos foi observado que a Reengenharia por
meio do Orion-RE demanda menos tempo do que em um processo manual. Destaca-se também
a utilização de um repositório distribuído para armazenamento, busca e recuperação de artefatos
de software que facilita e estimula o reuso desses artefatos durante o processo, e pelo fato da
abordagem ser baseada em componentes, têm-se uma melhoria na manutenibilidade.
A outra abordagem semelhante é proposta em (LEE et al., 2003), onde os autores apresentam
um processo para a Reengenharia de um sistema legado orientado a objetos para um sistema ba-
seado em componentes. Os componentes são criados com base nos relacionamentos originais das
classes, que são determinados pela análise do código fonte do programa. O processo é composto
de duas fases: a primeira para criar componentes básicos com o relacionamentos de composição
e de herança entre as classes que constituem o sistema; e a segunda para refinar o sistema base-
ado em componentes intermediário usando as métricas propostas, que incluem a conectividade, a
coesão e a complexidade. Finalmente, a abordagem é baseada em um modelo formal do sistema,
reduzindo a possibilidade de falhas no entendimento do sistema e para permitir que operações
sejam executadas corretamente.
Estas quatro abordagens são exemplos da tendência atual nas pesquisas de Engenharia Re-
versa, como observado por Keller e outros (KELLER et al., 1999). As abordagens Baseadas em
Componentes estão sendo consideradas na Engenharia Reversa, principalmente por seus benefí-
cios no reuso e manutenibilidade. Entretanto, ainda nota-se a falta de uma metodologia completa
para a Reengenharia de sistemas legados para sistemas baseados em componentes. Mas esta falta
não é restringida somente à Engenharia Reversa. Como pode ser visto em (BASS et al., 2000), os
problemas encontrados quando considerando abordagens Baseadas em Componentes na Reenge-
nharia, são somente um pequeno conjunto dos problemas relacionados à Engenharia de Software
Baseada em Componentes. Enquanto esses problemas não forem solucionados, a Reengenharia
terá sérias dificuldades para alcançar os benefícios associados aos componentes de software.
A Figura 3 sumariza o estudo apresentado na seção 2.2. Analisando a linha do tempo, pode-se
observar que os primeiros trabalhos estavam concentrados na transformação (tradução) de código-
para-código, sem se preocupar com a legibilidade e a qualidade dos resultados. Mais tarde, com o
surgimento das tecnologias orientadas a objetos, pôde-se observar um aumento no interesse com
o código fonte e a qualidade da documentação, para facilitar as evoluções futuras dos sistemas.
31
Figura 3: Linha do tempo das pesquisas sobre Reengenharia de Software e Engenharia Reversa
Os atuais problemas levantados e não resolvidos incluem reduzir a dispersão das funcionalida-
des e aumentar a modularidade, o que facilitaria a manutenção e a evolução dos sistemas resultantes
da Reengenharia. Na Engenharia de Software, decompor um sistema em pequenas partes é uma
forma essencial de reduzir a complexidade e garantir a sua evolução. Esta decomposição resulta
na “separação de interesses” e facilita o trabalho paralelo, a especialização da equipe de desen-
volvimento, a localização de pontos que devem sofrer modificação e conseqüentemente auxilia na
32
O Desenvolvimento de Software Orientado a Aspectos (DSOA) surgiu nos anos noventa como
um paradigma direcionado a implementar interesses transversais (crosscutting concerns) ou mais
especificamente aspectos, por meio de técnicas de geração de código para combinar (weave) as-
pectos na lógica da aplicação (KICZALES et al., 1997). De acordo com os princípios da Orientação
a Aspectos, aspectos modificam componentes de software através de mecanismos estáticos e di-
nâmicos. Os mecanismos estáticos preocupam-se com a adição de estado e comportamento nas
classes, enquanto que os dinâmicos modificam a semântica dessas classes em tempo de execução.
Esses aspectos são implementados como módulos separados, de forma que fique transparente a
maneira como os aspectos agem sobre os componentes funcionais, e como estes o fazem (FILMAN;
FRIEDMAN, 2000).
As investigações sobre DSOA na literatura procuram determinar a extensão que pode ser usada
para melhorar o desenvolvimento e a manutenção do software, ao longo das linhas discutidas por
Bayer em (BAYER, 2000). O DSOA pode ser usado para reduzir a complexidade e o entrelaçamento
de código; aumenta também a modularidade e o reuso, que são os principais problemas enfrentados
atualmente pela Reengenharia de Software. Assim, alguns trabalhos que usam as idéias do DSOA
na Reengenharia podem ser encontrados na literatura recente.
No estudo de caso realizado por Kendall (KENDALL, 2000), projetos orientados a objetos exis-
tentes são usados como ponto de início para a Reengenharia com técnicas orientadas a aspecto.
Neste trabalho, o processo de Reengenharia, as técnicas, mecanismos e as etapas seguintes não são
descritas em detalhes. São informados apenas os resultados comparativos entre o código orientado
a objetos e o código orientado a aspectos, resultado da Reengenharia. O uso do DSOA neste estudo
de caso reduziu o módulo total do sistema (classes e métodos) e o número de linhas do código.
Houve uma redução de 30 métodos e 146 linhas do código no sistema orientado a aspectos 1 .
1 As regras de modelos discutidas em (KENDALL, 2000) envolvem cinco protocolos da FIPA (Foundation for In-
telligent Physical Agents) (DICKINSON, 1997). Nos protocolos, os agentes podem pedir e receber serviços de cinco
33
Sant’Anna e outros (SANT’ANNA et al., 2003) apresentam algumas métricas para comparações
entre os projetos e implementações orientadas a aspectos e orientadas a objetos, que podem servir
para avaliar o produto do processo de Reengenharia.
Lippert e Lopes (LIPPERT; LOPES, 2000) apresentam um estudo que relata a capacidade do
DSOA em facilitar a separação do código de manipulação e detecção de exceções. Como estudo
de caso foi examinado um framework, construído em Java, e a parcial Reengenharia para aspectos,
de parte do sistema que cuida da manipulação e detecção de exceções, usando AspectJ.
Atualmente como o DSOA está entrando em uma fase de inovações, novos desafios vão sur-
gindo enquanto a tecnologia vai sendo adotada e estendida. Linguagens para apoiar o DSOA,
como AspectJ e AspectS, as contribuições de diferentes grupos de pesquisa 2 e a recente integra-
ção com servidores de aplicação como JBOSS3 e BEA’s WebLogic4 demonstram o crescimento da
popularidade do DSOA.
Este capítulo apresentou um estudo que identificou quatro tendências da pesquisa (tradução
código-para-código, recuperação e especificação de objetos, abordagens incrementais e aborda-
gens baseadas em componentes) nas referências de Engenharia Reversa e Reengenharia, do final
dos anos 80 até hoje. Os pesquisadores irão continuar a desenvolver tecnologias e ferramentas
para as tarefas genéricas da Engenharia Reversa e Reengenharia, mas pesquisas futuras devem se
concentrar em formas de como fazer o processo da engenharia reversa ser passível de aplicação
em diversos casos, melhor definido, controlado, e otimizado (MÜLLER et al., 2000).
A tendência mais promissora nesta área são as abordagens para auxiliar na compreensão con-
tínua do programa. A premissa de que a Engenharia Reversa necessita ser aplicada continuamente
durante toda a vida do software e que é importante compreender e reconstruir o potencial do pro-
jeto e decisões arquiteturais tem maiores implicações. A integração e a adaptação da ferramenta
maneiras diferentes. Os primeiros dois protocolos envolvem pedir e receber i) serviços e ii) informações. Nos ou-
tros três protocolos, um agente negocia para serviços com os múltiplos potenciais fornecedores via iii) uma rede do
contratos, iv) uma rede iterada do contrato, ou v) um leilão.
2 http://aosd.net
3 http://www.jboss.org
4 http://www.bea.org
34
devem ser as preocupações centrais. As organizações devem compreender esta premissa e obter o
completo suporte administrativo a fim realizar estes objetivos.
Para o futuro, segundo (MÜLLER et al., 2000), é crítico que os Engenheiros de Software respon-
dam eficazmente a perguntas, tais como o “Quanto de conhecimento, e em que nível de abstração,
é necessário extrair de um determinado sistema, para obter as informações sobre como realizar
a sua Reengenharia?”. Assim, será necessário combinar e adaptar as tarefas de compreensão do
programa aos objetivos específicos da Reengenharia.
A Programação Orientada a Aspectos (POA) procura solucionar alguns problemas não aten-
didos pela Orientação a Objetos, como, por exemplo, entrelaçamento e espalhamento de código
com diferentes funções. Este entrelaçamento e espalhamento tornam o desenvolvimento e a manu-
tenção desses sistemas atividades difíceis para o Engenheiro de Software. A POA visa aumentar
a modularidade, separando o código que implementa funcionalidades específicas, afetando dife-
rentes partes do sistema, chamadas de interesses transversais (crosscutting concerns). Dentre as
diferentes linguagens orientadas a aspectos destaca-se a linguagem AspectJ, que é uma extensão
orientada a aspectos da linguagem Java. AspectJ possui construções específicas para representar
os principais conceitos da POA, como aspectos, pontos de junção, conjunto de pontos de junção,
adendos e declarações intertipos1 .
Neste contexto, este capítulo é dedicado à Programação Orientada a Aspectos, contribuindo as-
sim para o embasamento teórico da abordagem apresentada nesta dissertação. Ele está organizado
como se segue: na seção 3.1 são apresentados os conceitos básicos que abrangem a Programação
Orientada a Aspectos. Na seção 3.2 é apresentada a especificação de uma linguagem de apoio
à POA, descrevendo mais detalhadamente a linguagem AspectJ, alvo deste projeto de pesquisa.
Na seção 3.3 são feitas considerações a respeito do projeto de software orientado a aspectos e,
finalmente, na seção 3.4 têm-se as considerações finais.
O software desenvolvido usando a Programação Orientada a Objetos (POO) é mais fácil de man-
ter porque oferece mecanismos para reduzir o acoplamento e aumentar a coesão dos módulos,
melhorando a manutenibilidade (PRESSMAN, 2001).
A POA baseia-se no princípio de que sistemas computacionais podem ser mais bem desenvol-
vidos pela separação de funções específicas, afetando diferentes partes do sistema, denominadas
interesses transversais (crosscuting concerns) (ELRAD; FILMAN; BADER, 2001b) e (KICZALES et al.,
1997).
Gregor Kiczales e outros (1997) foi quem primeiramente classificou esses interesses trans-
versais como “aspectos”, e, conseqüentemente, quem criou a POA. Estes interesses podem ser
tanto funcionais, relacionados a regras de negócios, quanto não-funcionais, como gerenciamento
de transação, distribuição e persistência em banco de dados. Com essa separação e o aumento da
modularidade proposta pela POA, o sistema implementado fica mais legível, o que contribui para
o seu projeto e a sua manutenção.
Elrad, Filman e Bader (2001b) ilustram, por meio do diagrama de classes apresentado na
Figura 4, como um determinado interesse não-funcional pode se apresentar entrelaçado entre as
classes de um sistema, sendo assim um interesse transversal às demais funcionalidades da classe.
Esse diagrama de classes, usando a notação UML (Unified Modeling Language) (RUMBAUGH;
JACOBSON; BOOCH, 1999), mostra o projeto de um editor de figuras que possui duas classes con-
cretas: “Point” e “Line”, que estão com suas funcionalidades bem encapsuladas, segundo os
princípios da POO. Porém, existe a necessidade de se adicionar uma nova funcionalidade que irá
atualizar o display toda vez que um dos elementos do tipo “Figure” for movido, ou seja, sempre
que os valores da posição do elemento em um plano cartesiano (eixos X e Y) forem alterados.
Uma solução seria criar um método “displayUpdating()” responsável pela atualização do dis-
play, e fazer a sua invocação após o código dos métodos referentes à manipulação da posição do
elemento. A implementação do mecanismo de atualização afeta métodos de diferentes classes. Em
destaque, pela linha tracejada, estão os métodos que serão afetados por essa modificação, tornando
o código funcional da classe entrelaçado com o código desse novo interesse recém adicionado e,
este, por sua vez, espalhado por alguns métodos funcionais das classes (os métodos “setX(int)”,
“setY(int)”, “setP1(Point)” e “setP2(Point)”).
Por meio do uso da POA pode-se encapsular esse novo interesse em uma unidade modular
denominada aspecto, de forma que o código que implementará essa atualização do display não
afetará o código que trata da movimentação dos elementos.
A separação dos diferentes interesses que estão espalhados pelo sistema, nas suas unidades
modulares, facilita a manutenibilidade garantindo também a evolução, compreensão e o reuso de
artefatos do sistema (ELRAD; FILMAN; BADER, 2001b).
38
Embora possa parecer que a POA é uma evolução da POO, na verdade, ela é um paradigma
para ser utilizado em conjunto com a POO, assim como também pode ser utilizado em conjunto
com o paradigma procedural, já que a programação procedural também pode apresentar interesses
transversais (HIGHLEY; LACK; MYERS, 1999). Além disso, a POA, atuando em conjunto com a
POO, aumenta o grau de reuso das classes à medida que busca solucionar o problema dos interesses
transversais.
• pontos de junção (join points): Um ponto de junção é um local bem definido no código
no qual um interesse vai interceptar o fluxo de execução do sistema. Um ponto de junção
pode ser definido por uma invocação de métodos, invocação de construtores, execução de
manipuladores de exceção ou outros pontos na execução do sistema;
• uma dada linguagem para identificar os pontos de junção: Visto que um ponto de junção
é um local bem definido no código do sistema, é necessário ter um construtor na linguagem
orientada a aspectos que possa identificar esse ponto de junção. Esta construção é denomi-
nada conjunto de pontos de junção (pointcut);
3.2.1 AspectJ
AspectJ (KICZALES et al., 2001a) é uma extensão orientada a aspectos da linguagem Java, de
propósito geral, desenvolvida pela equipe de pesquisadores do laboratório Palo Alto Research Cen-
ter (PARC), da Xerox. Por se tratar de uma extensão da linguagem Java, todo programa em
AspectJ, ao ser compilado, é passível de execução em qualquer máquina virtual Java. Para im-
plementar os conceitos da POA, AspectJ apresenta novas construções básicas, como: aspectos
(aspects), pontos de junção (join points) e conjunto de pontos de junção (pointcuts); e construções
específicas, como: declarações intertipos (inter-type declarations) e adendos (advices).
http://www.oopsla.org
41
(GRADECKI; LESIECKI, 2003). A Figura 7 apresenta o diagrama de classes UML deste sistema.
Os pontos de junção (join points) em AspectJ são pontos bem definidos na execução de uma
aplicação. A Figura 8, retirada de (HILSDALE; KICZALES, 2001), mostra um exemplo de fluxo de
execução entre dois objetos.
Os pontos de junção são utilizados nas definições dos conjuntos de pontos de junção. Um con-
junto de pontos de junção (pointcut) é uma construção na linguagem AspectJ, que visa identificar
pontos de junção e obter o contexto da execução desse pontos de junção por meio de critérios bem
definidos. Esses critérios podem variar de nomes de funções específicas, ou generalizadas pelo
sinal de asterisco (*). Além disso, um conjunto de pontos de junção pode conter operadores lógi-
cos (“&&”,“||” e “!”) e pode ter um nome atribuído para possibilitar a identificação de pontos de
junção de diferentes classes.
Um conjunto de pontos de junção é mais do que uma expressão contendo informações sobre
os pontos de junção, ele mostra diretamente como um interesse intercepta o fluxo de execução do
sistema.
A estrutura de um conjunto de pontos de junção pode ser representada da mesma forma que
a assinatura de um método na linguagem Java. A Figura 9 apresenta o trecho da gramática8 da
linguagem AspectJ que especifica um conjunto de pontos de junção.
O modificador de um conjunto de pontos de junção (1) tanto pode ser “public” ou “private”,
dependendo das considerações no projeto, e indica o escopo do conjunto de pontos de junção
no aspecto. Após a definição do tipo do modificador, procede-se a definição do identificador do
conjunto de pontos de junção (2). O identificador nada mais é do que um nome, definido por uma
seqüência de caracteres e números (3) que irá identificar o conjunto de pontos de junção no aspecto,
e é análogo ao nome de um método usado tradicionalmente nas classes em Java. Os parâmetros
(4) são usados para transferir o contexto obtido de um ponto de junção e possuem um tipo Java
válido (5). Um parâmetro do conjunto de pontos de junção é seguido de um ou mais designadores
8 Foi especificada uma gramática da linguagem AspectJ, utilizada na abordagem apresentada nesta dissertação,
definida com base na literatura (ASPECTJ, 2004; GRADECKI; LESIECKI, 2003; HILSDALE; KICZALES, 2001; KICZALES et
al., 2001b)
43
de conjuntos de pontos de junção (6). Estes designadores provêm a definição de como o ponto de
junção é utilizado no conjunto de pontos de junção. Existem diversos designadores pré-definidos
na linguagem AspectJ, denominados designadores primitivos, mas o Engenheiro de Software pode
elaborar novos conjuntos de pontos de junção (nomeados ou não) a partir dos já existentes.
Designador Descrição
call(<assinatura de método>) Quando o método é chamado
execution(<assinatura de método>) Quando o método é executado
get(<assinatura de atributo>) Quando o atributo é acessado
set(<assinatura de atributo>) Quando o atributo é alterado
handler(<tipo de exceção>) Quando a exceção é tratada
initialization(<assinatura de construtor>) Quando o construtor é executado
staticinitialization(<tipo>) Quando a inicialização de classe é executada
Tabela 1: Designadores primitivos
e aqueles que selecionam pontos de junção que satisfazem uma determinada propriedade (por
exemplo, em função da classe do objeto no qual o ponto de junção ocorre), conforme a Tabela 2.
Para se utilizar uma combinação dos designadores listados, basta utilizar os operadores lógicos
“&&”,“||” e “!” para combiná-los, formando as seguintes construções, conforme a Tabela 3.
Designador Descrição
within(<tipo>) Qualquer ponto de junção que ocorra na
classe
withincode(<método>) Qualquer ponto de junção que ocorra no
método/construtor
cflow(<conjunto de pontos de junção>) Qualquer ponto de junção que ocorra no
contexto de um ponto de junção selecio-
nado pelo designador
cflowbelow(<conjunto de pontos de junção>) Idem ao anterior, excluindo os pontos de
junção selecionados pelo próprio designa-
dor
this(<tipo>) Qualquer ponto de junção que ocorra em
um objeto da classe
target(<tipo>) Quando o objeto alvo do call/get/set é da
classe
args(<tipo, ...>) Quando os argumentos são do tipo espe-
cificado
if(<expressão lógica>) Quando a expressão é verdadeira
Tabela 2: Designadores que selecionam pontos de junção que satisfazem uma determinada propri-
edade
Operador Descrição
!<conjunto de pontos de junção> Qualquer ponto de junção não selecio-
nado pelo designador
<conjunto de pontos de junção> && <con- Qualquer ponto de junção selecionado
junto de pontos de junção> por ambos os designadores
<conjunto de pontos de junção> || <conjunto Qualquer ponto de junção selecionado
de pontos de junção> por ao menos um dos designadores
Tabela 3: Operadores lógicos
pointcut MudancaTitulo():
call(public void DVD.setTitulo(String));
pointcut MetodosSet():
call (public set*(..));
seleciona os pontos de junção nos quais quaisquer métodos públicos, que tenham o nome iniciados
por “set” concatenados com quaisquer outros caracteres e possuam qualquer número de parâme-
tros, sejam invocados, e
pointcut InvocacaoMetodosProduto():
45
set(* Produto+.*);
seleciona os pontos de junção no qual quaisquer atributos de objetos da classe “Produto” ou deri-
vadas sejam alterados.
O Engenheiro de Software pode também criar seus próprios conjuntos de pontos de junção,
bem como pode definir designadores de conjunto de pontos de junção, de forma a possibilitar seu
uso em mais de um local. A palavra-chave “pointcut” é usada para definir um designador de
conjunto de pontos de junção (GRADECKI; LESIECKI, 2003).
Um designador de conjunto de pontos de junção pode ainda ser abstrato, quando deve omitir
a sua definição. A existência de um designador de conjunto de pontos de junção abstrato obriga
o aspecto a ser abstrato. Deve haver então um sub-aspecto concreto que especialize o aspecto
abstrato e forneça uma definição para os designadores de conjunto de pontos de junção abstratos.
Tanto designadores de conjunto de pontos de junção primitivos como os de usuário podem ser
usados na definição dos conjuntos de pontos de junção do usuário.
A Figura 10 apresenta como os adendos são definidos, de acordo com a gramática da lingua-
gem AspectJ.
Os adendos podem ser de três tipos (1): “anterior” (“before”), que executa quando a compu-
tação alcança a invocação do método e antes de sua execução; “posterior” (“after”), que executa
após a execução do corpo do método e antes do controle retornar ao cliente; e “de contorno”
(“around”), que executa quando alcança o ponto de junção e possui controle explícito sobre a
execução (ou não) da computação originalmente associada ao ponto de junção.
46
Os adendos de contorno são os que têm uma maior influência sobre o código do sistema, já que
eles substituem o comportamento original do ponto de junção. Além disso, o adendo de contorno
é o único que possui um tipo de retorno (2).
Os adendos posteriores que possuem o qualificador “returning” (3), são executados somente
quando o ponto de junção retorna normalmente, sem erros, o controle ao aspecto. Já os que pos-
suem o qualificador “throwing” (3) são executados somente quando o ponto de junção é finalizado
lançando uma exceção.
Um adendo também pode declarar parâmetros (4), que devem ser correspondidos na declara-
ção dos conjuntos de pontos de junção. Esses parâmetros ficam disponíveis na execução do corpo
do adendo (5).
O atributo “thisJoinPoint” (1) é uma variável usada para acessar o contexto do ponto de jun-
ção. O método “toLongString()” (2) retorna uma “String” com uma representação por extenso
do ponto de junção. O resultado da execução do adendo anterior do conjunto de pontos de junção
“Todos(obj)”, usando o exemplo da classe “DVD” é:
O resultado mostra que o construtor da classe “DVD” foi executado. Quando a identificação
foi determinada, o código do adendo do conjunto de pontos de junção foi executado e exibiu a
47
Assim, nos pontos de junção comuns aos dois aspectos, os adendos do aspecto “AspectoExce-
cao” tem prioridade na execução em relação aos do aspecto “AspectoLog”.
Até o momento, todas as construções apresentadas são de caráter dinâmico, pois elas alteram a
estrutura do sistema por meio da interceptação de pontos bem definidos no fluxo de execução (pon-
tos de junção) e da adição de comportamento antes e/ou depois dos mesmos, ou ainda, obtendo o
controle total da execução. Porém, a linguagem AspectJ também possui construções, denomina-
das declarações intertipos, para alterar estaticamente a estrutura do sistema, adicionando membros
(atributos, métodos e construtores) a uma classe, alterando a hierarquia de herança das classes e
interfaces do sistema (GRADECKI; LESIECKI, 2003).
Em (1) um atributo do tipo “String” denominado “Ano” está sendo introduzido na classe
“Produto”. Já em (2) é declarada uma interface denominada “IProduto” que possui a assinatura
de dois métodos: “void setAno(String inAno);” e “String getAno();”. Em (3), é declarado que a
classe “Produto” implementará a interface “IProduto”. Finalmente, em (4), está a declaração da
implementação dos corpos dos métodos da interface “IProduto”.
A partir do exemplo da Figura 12, pode-se notar que atributos definidos como uma declaração
intertipos na classe, ficam disponíveis para uso pelos métodos também assim declarados. A inter-
face adicionada pode ser usada em designadores de conjuntos de pontos de junção para selecionar
48
A principal construção em AspectJ é o aspecto (aspect). Cada aspecto define uma funciona-
lidade específica que pode afetar várias partes de um sistema, como, por exemplo, tratamento de
exceções. Um aspecto é uma construção que encapsula pontos de junção, conjuntos de pontos de
junção, declarações intertipos e código de adendos. Um aspecto, assim como uma classe Java,
pode definir membros (atributos e métodos) e uma hierarquia de aspectos, por meio da definição
de aspectos especializados. O formato de um aspecto é apresentado na Figura 13.
O modificador (1) mais comumente utilizado nos aspectos é o “public”, porém, algumas vezes,
um aspecto pode ser declarado como “abstract”, que pode ser utilizado para implementar o reuso
de aspectos (PIVETA; ZANCANELLA, 2003). O modificador “private” é o menos utilizado. Os
modificadores especificados para os aspectos seguem as mesmas regras para as classes Java. O
modificador “privileged” permite que o aspecto tenha acesso interno aos atributos privados da
classe.
Um aspecto, assim como uma classe Java, possui um nome identificador (2). Ele pode ainda
implementar uma hierarquia de herança, por meio da palavra-chave “extends” (3), sendo que
o aspecto pode derivar de outro aspecto ou de uma classe. Apenas os aspectos abstratos (com
49
Por padrão, existe apenas uma instância para cada aspecto, já que a declaração de construtores
públicos não é disponível. Porém, é possível definir uma associação por instância de objeto ou por
ponto de junção selecionados por um designador, usando os modificadores de instanciação (4):
“issingleton”, “perthis”, “pertarget”, “percflow” e “percflowbelow”.
O “issingleton” é o tipo padrão atribuído para todos os aspectos que não possuem aspectos
pais ou uma declaração específica de um tipo de instanciação. Ele pode ser atribuído a um aspecto
para assegurar que somente um objeto do tipo aspecto foi criado no sistema. A estrutura sintática
é como se segue:
Já o “perthis” e o “pertarget” criam uma instância do aspecto para o objeto que for o corrente
no momento de execução de um ponto de junção previamente especificado.
Neste conjunto de pontos de junção e no código do adendo, toda exceção lançada pela classe
será capturada pelo aspecto “AspectoExcecaoDVD”, por causa do tipo da classe “Exception+”
usada no designador “handler” (1). Quando uma exceção de um objeto é passada para o código
do adendo, a palavra-chave “instanceof” (2) determina se a classe do ponto de junção é ou não a
“DVDException”. Se a classe for a “DVDException”, o nome atribuído ao objeto é exibido (3).
50
Os pesquisadores dessa área buscam, entre outras coisas, definir uma linguagem de modelagem
na qual um modelo mais completo para DSOA irá se basear. Segundo Clarke e Walker (2002) uma
linguagem de modelagem que apóie o projeto de software orientado a aspectos deve atender a
alguns objetivos principais, a saber:
tada a aspectos não pode estar baseada em uma linguagem de programação orientada a as-
pectos específica, deve ser genérica;
Neste contexto, Chavez e Lucena (CHAVEZ; LUCENA, 2001; CHAVEZ, 2004) propõem um mo-
delo de projeto para o DSOA que incorpora as principais características da POA, e é independente
de linguagem e de processo. Por meio do modelo de projeto proposto, que é uma extensão do
modelo orientado a objetos, os autores pretendem reduzir o tempo gasto no DSOA e a distância
existente entre o projeto e a implementação no qual linguagens orientadas a aspectos são utilizadas.
O modelo proposto compreende de três facetas: uma faceta estrutural, que objetiva a mode-
lagem da estrutura dos aspectos e dos componentes e de como eles estão relacionados em relação
à interceptação do fluxo de execução do sistema e nos mecanismos de composição; uma faceta
dinâmica, que objetiva modelar as interações entre as instâncias dos aspectos e as instâncias dos
componentes que eles interceptam, por meio da perspectiva do aspecto; e por fim uma faceta
composicional, que objetiva modelar o processo de composição (weaving) para facilitar o enten-
dimento dos efeitos causados pela combinação entre aspectos e componentes em um alto nível de
abstração.
A necessidade de uma notação satisfatória para o projeto de software orientado a aspectos foi
reconhecida anos após o paradigma ter sido criado. Dentre as diferentes propostas para estender a
UML, destaca-se a proposta de Suzuki e Yammamoto (SUZUKI; YAMAMOTO, 1999) e a de Pawlak
e outros (PAWLAK et al., 2002).
A primeira proposta de extensão da UML com conceitos para o projeto de software orien-
tado a aspectos foi apresentada por Suzuki e Yammamoto (SUZUKI; YAMAMOTO, 1999). Nesta
52
abordagem, uma nova meta-classe UML chamada “aspect” é introduzida. Esta meta-classe está
relacionada à classe base por meio de um relacionamento de realização. Esta proposta tem dois
problemas.
Primeiro, os autores apresentam somente uma notação que pode ser usada para representar o
conceito de declarações intertipos. Não está claro como os conjuntos de pontos de junção e os
adendos podem ser especificados na UML e como será representada a forma que os relacionamen-
tos de entrecorte (crosscutts) afetam o comportamento das classes.
A proposta de Pawlak e outros (PAWLAK et al., 2002) para o Projeto de Software Orientado a
Aspectos, por meio da extensão da UML, é a que se apresenta mais interessante. São definidos três
53
novos conceitos na UML: (1) grupos (groups), que provêm meios de classificação para entidades
distribuídas e heterogêneas, (2) relações de conjunto de pontos de junção (pointcut relations), que
permitem ao Engenheiro de Software definir entrecortes (crosscutts) dentro do programa funcional,
e (3) a meta-classe aspecto (aspect-classes), que implementa a extensão do programa nos pontos
de entrecorte (crosscutting points) especificados pelas relações de conjuntos de pontos de junção.
Porém, alguns pontos sobre o trabalho de Pawlak e outros apresentam problemas: a utilização
do papel de um relacionamento para representar os pontos de junção acaba poluindo visualmente
o modelo, visto que a definição de pontos de junção normalmente envolve um grande número de
caracteres. Outro ponto é a utilização de caracteres especiais como sinal de exclamação (“!”) que
pode possuir outro significado em um linguagens de programação, resultando em confusão.
Stein e outros também propuseram uma extensão da UML para a modelagem de programas
orientados a aspectos implementados em AspectJ (STEIN; HANENBERG; UNLAND, 2002). A exten-
são proposta é um modelo de projeto e denomina-se AODM (Aspect Oriented Design Model). Este
modelo foi proposto a partir da linguagem de modelagem UML, adicionando os conceitos clássicos
da programação orientada a aspectos. Além disso, também reproduz o mecanismo de composição
(weaving). Os aspectos são representados como classes UML com estereótipo <<aspect>> e
podem participar em relacionamentos de associação, generalização e dependência. Eles contém
elementos de entrecorte (crosscutts) que podem alterar a estrutura e o comportamento de um mo-
delo. A estrutura é alterada por meio de templates de colaboração (collaboration templates9 ), que
possuem o estereótipo <<introduction>> e o comportamento por meio de operações com este-
reótipo <<advice>>. Os aspectos também possuem etiquetas valoradas que especificam como
será a sua instanciação.
Embora essa notação seja bastante completa, ela não influenciou a notação proposta por este
documento devido à dificuldade de leitura que ela apresenta e também à falta de apoio automati-
zado.
Este capítulo apresentou uma visão geral da programação orientada a aspectos, discutindo de
forma detalhada os seus objetivos e conceitos, bem como a aplicação destes no DSOA. Também
9 Um template é um elemento de modelo parametrizado utilizado para gerar outros elementos do modelo através
de passagem de parâmetro.
10 Correspondem aos pontos de junção em AspectJ.
55
Nos capítulos anteriores foram apresentados os principais conceitos envolvidos nesta pesquisa,
que forneceram o embasamento teórico para o desenvolvimento de uma abordagem com o objetivo
de auxiliar a migração de sistemas orientados a objetos para aspectos, por meio da Reengenharia
de Software. Neste contexto, neste capítulo apresenta-se em detalhes a abordagem Phoenix para
a Reengenharia de Software Orientada a Aspectos. A abordagem baseia-se em técnicas de Enge-
nharia Reversa e Reengenharia de Software e é apoiada por diversos mecanismos que auxiliam o
Engenheiro de Software no processo, automatizando grande parte das atividades da Reengenharia.
Como visto no Capítulo 3, muitas funções existentes nos sistemas de software são inerente-
mente difíceis de decompor e isolar, reduzindo a legibilidade e a manutenibilidade desses sistemas.
Na literatura pode-se encontrar diversas propostas (DEURSEN; MARIN; MOONEN, 2003; JAN-
ZEN; De Volder, 2003; IWAMOTO; ZHAO, 2003) para dar suporte à identificação de aspectos em
estágios iniciais do processo de desenvolvimento de software. O principal objetivo de migrar sis-
temas orientados a objetos para aspectos é melhorar o entendimento do sistema, aumentando assim
a manutenibilidade e dando uma maior garantia para a sua evolução.
Várias preocupações relativas ao uso do DSOA são levantadas como, por exemplo, o risco
de obter um código mais entrelaçado, conhecido como “código espaguete”, pela não utilização
correta dos conceitos da Orientação a Aspectos e o uso indiscriminado de abordagens ad-hoc para
o projeto de sistemas, pelo fato de não haver um padrão definido para expressar a modelagem de
sistemas orientados a aspectos. Essas preocupações levantam a seguinte questão: Quando o DSOA
é necessário e quando somente a Programação Orientada a Objetos resolve o problema ?
Neste contexto, a mineração de aspectos pode ajudar a resolver esta questão. Técnicas de
mineração de software ajudam a encontrar informações valiosas no código de um sistema, tor-
nando estas informações disponíveis aos Engenheiros de Software envolvidos na evolução daquele
sistema. Um bom exemplo de mineração de software é a extração de regras de negócio.
A identificação dos candidatos a aspectos requer primeiramente uma clara idéia de quais as-
pectos se pretende encontrar. Assim, um estudo sobre os aspectos genéricos ou específicos de
um domínio é um pré-requisito para a mineração de aspectos. Por exemplo, antes de minerar o
interesse de persistência em banco de dados, é necessário entender como este interesse é tratado,
e como ele é tratado particularmente no sistema em questão. Esse estudo pode envolver a análise
da documentação disponível e a busca pela chamada de métodos específicos, chamadas a constru-
58
tores, acesso a atributos e outros pontos de execução bem definidos, visando descobrir possíveis
pontos de junção envolvendo o interesse a ser minerado.
Para realizar a mineração de aspectos existe a necessidade de se fazer a análise (parsing) dos
programas orientados a objetos e verificar os locais nos quais existem códigos duplicados, difusos
ou referentes a diversos interesses de projeto.
• Mineração baseada em texto: A mineração de dados baseada em texto procura por padrões
no código fonte, utilizando como base os nomes de classes, métodos e atributos. Ela é
interessante caso sejam utilizadas convenções de nomeação para os elementos do sistema. A
não utilização de um padrão para tal pode dificultar no processo de identificação de interesses
transversais.
• Mineração baseada em tipos: A mineração por meio de tipos procura pela ocorrência dos
diversos tipos (i.e. classes) definidos no aplicativo a ser analisado. Ela permite encontrar
pontos em um sistema nos quais o acoplamento e a coesão possam deixar a desejar. Um
único módulo que utiliza alguns poucos tipos é candidato a possuir uma coesão alta e baixo
acoplamento, por exemplo. A mineração baseada em tipos funciona melhor do que a mi-
neração baseada em texto quando não existem convenções de nomeação. Ela não é muito
interessante quando instâncias de um mesmo tipo são utilizadas para diferentes propósitos.
O ideal é que essas duas abordagens sejam utilizadas em conjunto, já que uma complementa a
outra.
Após a extração dos interesses transversais, a extração deve ser planejada por meio de técnicas
bem definidas. O problema é como extrair os interesses que estão entrelaçados dentro do código da
aplicação e espalhados por diversas classes. Nesta pesquisa utilizou-se para isso a POA (KICZALES
et al., 1997), que auxilia na separação desses diferentes interesses em unidades separadas. Para ex-
trair estes interesses dos sistemas orientados a objetos em aspectos, é possível utilizar refatorações
59
Refatoração é uma técnica utilizada para reestruturar código orientado a objetos de uma forma
disciplinada. A intenção dela é aprimorar a legibilidade e a compreensão do código orientado a
objetos. A maioria das técnicas de refatoração se propõe a aumentar a modularidade e eliminar a
redundância do código. Considerando que as mesmas vantagens são obtidas por meio do DSOA,
parece ser natural aplicá-los no mesmo processo de desenvolvimento (DEURSEN; MARIN; MOONEN,
2003). O benefício de se utilizar ambas as abordagens é considerável. Refatoração pode ajudar
a reestruturar o código orientado a objetos segundo o paradigma orientado a aspectos, tornando
viável a migração de sistemas orientados a objetos para orientados a aspectos.
A partir da pesquisa de catálogos de refatorações existentes como, por exemplo (FOWLER et al.,
1999), foram identificadas diversas similaridades entre refatorações para melhoria de código e a
extração de aspectos. Assim, foi definido um catálogo1 de refatorações (GARCIA et al., 2004), com
base em refatorações existentes (FOWLER et al., 1999; HANENBERG; OBERSCHULTE; UNLAND, 2003;
IWAMOTO; ZHAO, 2003), que são utilizadas para extrair os aspectos do código fonte orientado a ob-
jetos. A Figura 18 mostra a interação entre essas refatorações orientadas a aspectos especificadas,
onde as refatorações sombreadas (em cinza) não são especificadas nesta dissertação.
O catálogo definido contém refatorações para extrair os interesses de acordo com os princi-
pais conceitos do DSOA, como, por exemplo, a extração de métodos e atributos de classes para
aspectos, definição de conjuntos de pontos de junção, construção de adendos, entre outros.
As refatorações apresentadas aqui são propostas a partir da experiência do aluno e seu orien-
1 Refatorações são sistematicamente organizadas em catálogos, de um modo análogo aos padrões de projeto
(GAMMA et al., 1995).
60
tador em DSOA e na realização de estudos de caso. É importante ressaltar que essas refatorações
não abrangem todos os problemas e nem pretendem ser a solução completa para a extração de inte-
resses transversais do código orientado a objetos, mas representam o primeiro passo para a criação
de um catálogo com este objetivo.
Após a extração dos aspectos, obter uma representação em alto nível de abstração facilitaria
o entendimento do sistema para futuras atividades de manutenção, a evolução do software, bem
como estimularia o reuso. A abordagem Phoenix utiliza transformações de software para auxiliar
na obtenção dessa representação.
O Draco-PUC é uma ferramenta baseada nas idéias do paradigma Draco (NEIGHBORS, 1983),
implementando a grande maioria das características importantes em um sistema transformacional
de software. Dentre essas características, destaca-se um sistema de parser de grande expressi-
vidade, baseado no Bison (DONNELLY; STALLMAN, 2004), aliado a outros recursos, como, por
exemplo, o backtracking (FREITAS; LEITE; SANT’ANNA, 1996). As transformações no Draco-PUC
são escritas com base na sintaxe das linguagens dos domínios cujos programas se deseja transfor-
mar e na sintaxe da linguagem do sistema de transformação denominado TFMGEN (PRADO, 1992)
do próprio Draco-PUC.
Além disso, o Draco-PUC possui um código portátil e que pode operar em diferentes versões
de sistemas operacionais, como Unix, Windows 9x, NT, 2000 e XP.
MORAES, 2004; NOGUEIRA, 2002; NOVAIS, 2002). Estas pesquisas também serviram para testar o
Draco-PUC e identificar as dificuldades na construção dos domínios. Ao longo destas pesquisas,
grande parte das dificuldades foram superadas e os erros encontrados foram corrigidos, tornando
o Draco-PUC mais estável e confiável.
Dentre as diferentes ferramentas CASE (ARGOUML, 2003; TOGETHER, 2004; RATIONAL, 2004;
OMONDO, 2004) destaca-se a MVCASE2 (ALMEIDA et al., 2002a, 2002b). A MVCASE é uma ferra-
menta orientada a objetos que dá suporte à especificação textual e gráfica de requisitos do sistema,
em diferentes níveis de abstração, utilizando a notação UML (BOOCH; RUMBAUGH; JACOBSON,
1999).
A partir do estudo das diferentes propostas para a modelagem orientada a aspectos, alguns
pontos em comum foram identificados, indicando uma conformidade na representação de alguns
conceitos da POA. Assim, foi especificada uma notação chamada UAE (UML-based Aspect Engi-
neering) (GARCIA et al., 2004b) para a modelagem de sistemas orientados a aspectos, por meio da
extensão da UML.
Para dar suporte a esta notação, a ferramenta de modelagem MVCASE foi estendida para
apoiar o projeto orientado a aspectos por meio da notação UAE (GARCIA et al., 2004b).
2 Disponível para download em: http://mvcase.dev.java.net/
62
Figura 19: Phoenix: Uma Abordagem para Reengenharia de Software Orientada a Aspectos
No primeiro passo, parte-se do código fonte do sistema orientado a objetos para realizar a iden-
tificação dos interesses transversais. Uma vez identificados os interesses, eles podem ser extraídos,
para então serem encapsulados em aspectos, por meio da aplicação de refatorações especificadas
com este propósito. No passo seguinte, o Engenheiro de Software recupera o projeto do sistema
orientado a aspectos em alto nível de abstração, baseado na UML, e importa esse projeto na fer-
ramenta MVCASE. A partir de então, é possível trabalhar e realizar modificações no projeto do
sistema, em um alto nível de abstração, para depois gerar o código novamente em uma linguagem
orientada a aspectos. Conforme mostra a Figura 19, os principais mecanismos da abordagem são:
o sistema transformacional Draco-PUC, a ferramenta MVCASE e o Engenheiro de Software. A
abordagem é orientada por técnicas de Mineração de Aspectos, Refatorações, Transformação de
Software e DSOA.
Segue-se uma apresentação detalhada de cada passo da abordagem, além das técnicas e meca-
nismos utilizados. Para a definição da abordagem foram realizados diferentes estudos de caso, de
diferentes domínios (Sistema de Caixa de Banco, Sistema de Vendas pela Web e um sistema que
63
implementa o problema do Jantar dos Filósofos). Nas seções que se seguem, esses sistemas são
utilizados como exemplo, para facilitar o entendimento das entradas, saídas e controles de cada
passo. Os sistemas foram obtidos na Internet 3 e nenhuma documentação estava disponível além
de alguns comentários no código fonte.
O entendimento dos sistemas foi obtido por meio da sua execução, onde se pode observar as
suas funcionalidades. Após o entendimento, o código dos sistemas foi analisado a fim de identificar
os possíveis interesses transversais, entrelaçados e dispersos através das classes do sistema.
O interesse de tratamento de exceção (1) pode ser encontrado pela existência da expressão
“try-catch”, onde podem existir um ou mais “catch” para cada “try”. Além disso pode existir
uma expressão de “finally”. Já o interesse de persistência em banco de dados (2) pode ser
identificado pela utilização de determinadas classes da linguagem Java, relativas à conexão com
o banco como, por exemplo a classe “Connection”, e para a persistência como, por exemplo as
classes “PreparedStatement”, “Statement” e “ResultSet”.
O parser reconhece a estrutura sintática “try-catch” (1) no código Java (2) e a ocorrência de
3 http://www.portaljava.com.br
4 Embora o Draco-PUC seja principalmente um sistema transformacional, ele pode atuar perfeitamente como um
gerador de parser, conforme já ficou comprovado em trabalhos anteriores (ALVARO et al., 2003; JESUS; FUKUDA; PRADO,
1999; LEITE; SANT’ANNA; PRADO, 1996; PRADO et al., 2004).
64
uma exceção do tipo SQLException, que indica a presença do interesse de tratamento de exceção.
Esta informação é armazenada para ser consultada futuramente, a fim de ajudar o Engenheiro
de Software a extrair e encapsular os interesses transversais em aspectos. Vale ressaltar que a
existência da exceção do tipo SQLException indica também a presença do interesse transversal
de persistência em banco de dados. Neste caso, cabe ao Engenheiro de Software separar o código
desses dois interesses no momento em que for encapsulá-los em aspectos.
exceção, também podem ser pesquisados outros interesses, por meio de transformações de soft-
ware, como, por exemplo, os interesses de rastreamento e programação paralela. Os interesses
de persistência em memória e/ou em arquivo não foram explorados na Abordagem. Na Phoenix,
a identificação de trechos de códigos relativos ao rastreamento é realizada utilizando o seguinte
conjunto de padrões de reconhecimento, conforme mostra a Figura 24.
66
O interesse transversal de programação paralela não depende de contexto para ser identificado,
ele depende da classe Thread e da interface Runnable, presentes na biblioteca da linguagem Java.
Não existindo nem a classe nem a interface, os padrões de reconhecimento para a identificação
deste interesse não serão válidas. A Figura 26 mostra os padrões de reconhecimento para a identi-
ficação do interesse transversal de programação paralela.
As informações obtidas sobre os interesses transversais identificados, bem como sua loca-
lização no código, são armazenadas para consulta na base de conhecimento, a fim de ajudar o
Engenheiro de Software a extrair e encapsular os interesses em aspectos. Os fatos armazenados na
67
i. Package(<nome do pacote>);
Entretanto deve-se reforçar que a mineração baseada em parser, assim como em seqüências
de caracteres e na análise de padrões de reconhecimento, é uma forma de auxiliar a identificação
dos interesses, que não impede que os interesses também sejam identificados manualmente, por
inspeção do código.
Figura 29: Identificando interesses no código: Atualização da tela com as informações do Cliente
representa.
No segundo passo da abordagem Phoenix, o código fonte é organizado de acordo com os prin-
cípios da POA, separando os interesses transversais (requisitos funcionais e/ou não-funcionais) em
aspectos, e as regras de negócio (requisitos funcionais) em classes com seus respectivos métodos e
atributos. Essa separação é auxiliada pelo catálogo de refatorações orientadas a aspectos (GARCIA
et al., 2004).
import java.lang.reflect.*;
public class ShoppingCart {
private List items = new Vector();
71
Este código mistura a lógica do negócio com o requisito de logging. O código de logging
(sombreado) deve ser extraído para um aspecto. Para fazer isto, as refatorações podem ser utili-
zadas, auxiliando a mover atributos, partes de código e métodos inteiros que são relacionados ao
logging no novo aspecto.
Para facilitar a compreensão na especificação das refatorações foi escolhido um formato se-
melhante ao utilizado por Fowler em (FOWLER et al., 1999). Será utilizado também, assim como
Fowler, um único código no exemplo de aplicação das refatorações. A especificação compreende
os seguintes elementos: o nome da refatoração; uma descrição da situação na qual ela é necessária
e o que ela propõe; uma descrição da ação recomendada; pré-condições para sua aplicação, quando
existir; o mecanismo de aplicação da refatoração e um código de exemplo.
A primeira refatoração aplicada é a EXTRACT FIELD TO ASPECT. Ela deve ser aplicada
quando uma classe tem um atributo relacionado a um interesse transversal que está implemen-
tado ou está sendo extraído para um aspecto. O código a seguir mostra o atributo relacionado ao
interesse de logging em sombreado.
import java.lang.reflect.*;
public class ShoppingCart {
private List items = new Vector();
private java.io.PrintWriter logWriter = System.err;
public void addItem(Item item) {
logWriter.println("Log:"+this.getClass().getName());
items.add(item);
}
public void removeItem(Item item) {
logWriter.println("Log:"+this.getClass().getName());
items.remove(item);
}
public void empty() {
logWriter.println("Log:"+this.getClass().getName());
72
items.clear();
}
}
A solução é mover o atributo como uma declaração intertipo para o aspecto que implementa
o interesse.
Mecanismo.
• Se o atributo for definido como público, considere o uso do Encapsulate Field ((FOWLER et
al., 1999), p.206) antes que esta refatoração seja aplicada.
• Mova a declaração do atributo para o aspecto, incluindo a declaração de valor inicial, se hou-
ver uma. Isto deve ser feito de acordo com a sintaxe da declaração intertipos da linguagem
orientada a aspectos utilizada.
• Modifique a visibilidade do atributo para public. A visibilidade pode ser modificada depois
que a refatoração for aplicada. Se ainda houver a necessidade de manter o código relacionado
ao atributo na classe, considere usar o Self Encapsulate Field ((FOWLER et al., 1999), p.146).
• Verifique todos os conjuntos de pontos de junção que contém declarações “within()”, pois
devem ser atualizadas após a aplicação desta refatoração.
• Compile e teste.
A EXTRACT FIELD TO ASPECT pode ser utilizada para extrair atributos relacionados ao
interesse de logging para o aspecto. Após a refatoração ser aplicada, tem-se:
. . . após a EXTRACT FIELD TO ASPECT ser aplicada, alguns métodos que se relacionam
àqueles atributos também devem ser movidos para o aspecto, desde que provavelmente relacionem-
se ao mesmo interesse que está sendo extraído. Para extrair estes métodos, assim como outros mé-
todos que relacionam-se a este interesse, pode-se utilizar EXTRACT METHOD TO ASPECT.
import java.lang.reflect.*;
public class ShoppingCart {
private List items = new Vector();
private void addLogMessage(String message) {
System.out.println("Log "+(logNumber++)+":"+message);
}
public void addItem(Item item) {
addLogMessage(this.getClass().getName());
items.add(item);
}
public void removeItem(Item item) {
addLogMessage(this.getClass().getName());
items.remove(item);
}
public void empty() {
addLogMessage(this.getClass().getName());
items.clear();
}
}
A solução seria mover o método para o aspecto que implementa o interesse transversal, como
uma declaração intertipos.
Motivação: Um método que relaciona-se com um interesse particular deve estar situado den-
tro do aspecto que implementa este interesse, para reduzir o entrelaçamento e espalhamento de
código.
Mecanismo.
• Mover a declaração do método que está na classe para o aspecto. Isto deve ser feito de
acordo com a sintaxe da declaração intertipos da linguagem orientada a aspectos utilizada.
• Verificar todos os conjuntos de pontos de junção com a declaração “within()”, que devem
ser atualizados após a aplicação desta refatoração.
74
• Compilar e testar.
A EXTRACT METHOD TO ASPECT pode ser utilizada para extrair o método relacionado
ao interesse de logging para o aspecto. Após a sua aplicação tem-se:
. . . após a EXTRACT METHOD TO ASPECT ser aplicada, não existe mais nenhum método
que esteja relacionado ao interesse que está sendo extraído. Entretanto, as chamadas a esses mé-
todos permanecem localizadas em outros métodos que não foram extraídos para o aspecto. Pode
também existir trechos de código que estão relacionados a esse interesse, mas não estão agrupados
como métodos. Para extrair essas chamadas de método e outros trechos de código, utiliza-se a
EXTRACT CODE TO ADVICE.
A EXTRACT CODE TO ADVICE é aplicada quando algum trecho de código está relacio-
nado a um interesse que pode ser implementado como um aspecto. Esse código não está separado
em um único método, mas sim misturado com outros códigos relacionados a outros interesses.
Motivação: As chamadas ao método que ocorrem em diversas classes são geralmente sujeitas
a esta refatoração. A separação correta dos interesses pode melhorar a manutenibilidade e o reuso
do software.
Mecanismo.
• Mover o trecho de código que está sendo extraído para o corpo do adendo.
• Analisar o trecho de código extraído, procurando por referências a variáveis locais no escopo
do método, incluindo parâmetros e atributos locais. Quaisquer declarações de variáveis tem-
porárias, utilizadas somente no trecho de código extraído, podem ser substituídas no corpo
do adendo.
Exemplo.
Esta refatoração pode ser utilizada para extrair o trecho de código relacionado à execução do
addItem para o aspecto. Após a aplicação da refatoração tem-se:
import java.lang.reflect.*;
public class ShoppingCart {
private List items = new Vector();
public void addItem(Item item) {
items.add(item);
}
public void removeItem(Item item) {
System.out.println("Log:"+this.getClass().getName());
items.remove(item);
}
public void empty() {
System.out.println("Log:"+this.getClass().getName());
items.clear();
}
}
Nota-se que o contexto referente à variável “this” também foi movido para o aspecto.
76
. . . após essa refatoração ter sido aplicada, ainda existem chamadas aos métodos que
relacionam-se ao interesse de logging. Assim, aplica-se a EXTRACT CODE TO ADVICE nos
outros métodos afetados na classe. Então, a classe fica desta forma:
import java.lang.reflect.*;
public class ShoppingCart {
private List items = new Vector();
public void addItem(Item item) {
items.add(item);
}
public void removeItem(Item item) {
items.remove(item);
}
public void empty() {
items.clear();
}
}
E o aspecto:
A EXTRACT POINTCUT DEFINITION deve ser aplicada quando a definição dos pontos
de junção estão altamente acopladas ao código do adendo.
Motivação: Pode ser definido um conjunto de pontos de junção separado, definindo os pontos
de junção e o contexto correto. A separação entre as definições do conjunto de pontos de junção
e os adendos torna o código mais legível e flexível, já que as modificações podem ser executadas
em um único lugar. Além disso, melhora-se reuso do código, visto que uma única definição do
conjunto de pontos de junção pode ser utilizada por diversos adendos.
Mecanismo.
77
• Assegure-se de que o conjunto de pontos de junção capture todo o contexto requerido pelo
trecho de código. Verifique se o código extraído se refere a declarações “this” ou “super”.
Os tipos de predicados mais utilizados definidos nos conjuntos de pontos de junção usam
referências ao objeto que recebe uma mensagem e chamadas a um método específico, ou uma
referência ao objeto atual combinado com a execução do método, atributo lido e operações
de escrita, entre outros.
• Compile e teste.
Exemplo.
Mecanismo.
78
• Verificar quantos pontos de junção determináveis são afetados atualmente pelo conjunto de
pontos de junção.
• Converter a declaração do ponto de junção em uma expressão regular, pelo uso dos coringas
a atributos lógicos disponibilizados pela linguagem orientada a aspectos.
• Compilar e testar.
Exemplo.
Em seguida à aplicação da COLLAPSE POINTCUT DEFINITION:
. . . após formatar a definição, pode-se identificar que o nome do conjunto de pontos de junção
não ajuda a identificar qual a sua real função. Assim, para fornecer um nome significativo, pode-se
aplicar a RENAME POINTCUT.
A RENAME POINTCUT deve ser aplicada quando o nome do conjunto de pontos de junção
não revela o seu real objetivo.
Motivação: Os nomes são um dos melhores mecanismos para expressar o objetivo de uma
determinada funcionalidade. Se existirem nomes ímpares às classes, aos métodos e aos aspectos,
seu código torna-se mais difícil para compreender e manter. O ideal é fornecer nomes significativos
para melhorar a qualidade do código.
Mecanismo.
• Modifique o antigo conjunto de pontos de junção para apontar para o novo (se possuir poucas
referências, pode-se pular este passo)
79
• Compile e teste.
• Modifique as referências do antigo conjunto de pontos de junção nos adendos e outros con-
juntos de pontos de junção para o novo.
• Compile e teste.
Após ter extraído o interesse relacionado ao logging para o aspecto Foo, foi identificado que
esse aspecto deveria ser rebatizado com um nome mais significativo, por meio da RENAME AS-
PECT.
A RENAME ASPECT deve ser aplicada quando o nome do aspecto não revela sua real fun-
cionalidade.
Motivação: Uma boa prática é nomear classes, aspectos, métodos, etc, a fim de melhorar a
legibilidade do código. Se para descobrir a função de um método ou classe for necessário analisar
todo o código fonte, esta é uma situação onde tem-se um candidato a aplicação desta refatoração.
Mecanismo.
• Verificar se o nome do aspecto está sendo utilizado por um super-aspecto ou por um sub-
aspecto. Em caso positivo, renomear também as referências no sub e super-aspectos.
• Compilar e testar.
. . . após o aspecto ser extraído, com seus atributos, métodos e adendos, e propriamente bati-
zado, algumas características podem ser separadas, como, por exemplo, as definições dos conjun-
tos de pontos de junção da implementação, utilizando conjuntos de pontos de junção e aspectos
abstratos, para aumentar a reusabilidade, flexibilidade e legibilidade.
Para prover e estimular o reuso pode-se usar a PULL UP ADVICE/POINTCUT. Ela deve
ser aplicada quando um aspecto tem as funcionalidades que poderiam estar sendo utilizadas por
diversos aspectos relacionados.
Mecanismo.
• Criar um novo conjunto de pontos de junção abstrato no super-aspecto com a mesma assina-
tura que nos sub-aspectos.
• Criar um novo adendo no super-aspecto e copiar o corpo do antigo adendo para o definido
no super-aspecto.
• Compilar e testar.
Exemplo.
Após aplicar a PULL UP ADVICE/POINTCUT, tem-se:
}
}
. . . algumas vezes, separar funcionalidades por toda a hierarquia dos aspectos não é uma al-
ternativa eficiente. Neste caso, o processo exatamente oposto pode ser aplicado usando a COL-
LAPSE ASPECT HIERARCHY.
Mecanismo.
• Modificar as referências às classes que serão removidas para utilizar o aspecto combinado,
resultante da aplicação da refatoração.
• Compilar e testar.
. . . após desfazer a hierarquia dos aspectos, pode-se inferir que o adendo está tão legível quanto
o nome dos conjuntos de pontos de junção relacionados. Assim, para fornecer um nome significa-
tivo, pode-se aplicar a INLINE POINTCUT DEFINITION.
A INLINE POINTCUT DEFINITION deve ser aplicada quando tem-se uma situação em
que um conjunto de pontos de junção é utilizado com um adendo somente e sua funcionalidade é
completamente óbvia. Não há nenhuma razão separar a definição do conjunto de pontos de junção
do adendo.
A solução é mover o predicado que contém os pontos de junção afetados para a assinatura do
adendo.
Mecanismo.
• Compilar e testar.
• Compilar e testar.
Exemplo.
Após a aplicação da INLINE POINTCUT DEFINITION, tem-se:
83
As refatorações apresentadas são aplicadas manualmente, porém, sabe-se que existe uma
grande probabilidade de erros serem inseridos pelo Engenheiro de Software durante esta ativi-
dade. Para automatizar e assegurar a não inserção de erros durante a aplicação das refatorações,
podem ser implementadas transformações de software específicas para tal.
Nós acreditamos que assim como algumas refatorações orientadas a objetos propostas por
Fowler (1999) são passíveis de implementação (automatização), algumas refatorações orientadas
a aspectos também o são como, por exemplo, RENAME ASPECT, EXTRACT FIELD TO
ASPECT e EXTRACT METHOD TO ASPECT. A implementação para a extração dos trechos
de código relativos ao interesse de tratamento de exceção é o primeiro passo para alcançar esse
84
objetivo.
Após obter o código do sistema organizado segundo a Orientação a Aspectos, com os inte-
resses transversais encapsulados em aspectos, e a sua validação, parte-se para o último passo da
abordagem para recuperar o projeto orientado a aspectos do sistema.
Para importar o projeto recuperado em descrições XMI na MVCASE é necessário que o plug-
in AOSD esteja adicionado à ferramenta. Este plug-in, que foi construído neste trabalho para
85
incorporar à ferramenta as extensões da POA. Para criar um novo projeto orientado a aspectos, o
Engenheiro de Software deve, a partir do projeto já criado na MVCASE, inserir um novo diagrama
na visão lógica (Logical View), por meio da seqüência de ações: Botão direito do mouse -> AOSD
-> Create Aspect Diagram. A seguir, um novo diagrama é criado, permitindo ao Engenheiro de
Software utilizar os estereótipos implementados para representar as construções da POA, são eles:
<<aspect>>, <<crosscut>> e <<inter-type>>, conforme mostra a Figura 32.
Assim como uma classe, um aspecto também pode conter atributos (Attributes) e métodos
(Operations), e, além deles, um aspecto pode conter adendos (Advices) e conjuntos de pontos de
junção (Pointcuts).
Na Figura 34, os elementos relativos à POA estão sombreados. Em (1) tem-se o aspecto
que encapsula o interesse de conexão com o banco, que por opção foi encapsulado separado do
interesse de persistência, em (2). Em (3) tem-se a representação dos dois métodos, declarados
como intertipos, que serão adicionados à classe Bankbox no momento da combinação, o mesmo
acontecendo para os métodos representados em (4), que serão adicionados à classe Client. O
aspecto de persistência relativo às contas do cliente (5), separado desta forma por opção, também
possui declarações intertipos. Em (6) tem-se o método que será inserido na classe Account e em
(7) os que serão inseridos na classe Bankbox.
Figura 34: Projeto orientado a aspectos parcial do Sistema - Persistência e Conexão com banco
Em (1) tem-se a tela para especificação dos conjuntos de pontos de junção. Os pontos de junção
e os designadores são especificados como código dos conjuntos de pontos de junção (“pointcut
code - joinpoint specification”). O mesmo acontece para o código dos adendos (“advice code”)
88
em (2).
Uma vez que o projeto orientado a aspectos está finalizado, o Engenheiro de Software pode
implementá-lo utilizando uma linguagem orientada a aspectos. Essa tarefa pode ser realizada
parcialmente pela MVCASE, por meio de um plug-in desenvolvido para gerar o código em As-
pectJ, a partir das descrições em XMI. Na Figura 36 é apresentada a geração do código do aspecto
ExceptionHandlingAspect, na MVCASE.
ção do projeto orientado a aspectos pode ser auxiliada por transformações de software, semi-
automatizando o processo e diminuindo a probabilidade de inserção de erros pelo Engenheiro de
Software.
90
Neste capítulo é apresentada, na seção 5.1, a realização de um estudo de caso para ilustrar a
aplicação da abordagem Phoenix. Em seguida, na seção 5.2, é feita uma avaliação dos resultados,
com base nos dados colhidos na execução do estudo de caso. O sistema utilizado no estudo de
caso foi obtido pela Internet.
5.1 XSimulare
Após o entendimento, o código do sistema foi analisado a fim identificar os possíveis interesses
transversais, entrelaçados e dispersos através das classes do sistema. Neste estudo de caso foram
identificados quatro interesses transversais relacionados a: tratamento de exceção, rastreamento,
logging e atualização do relógio.
1 Disponível em: http://xsimulare.tigris.org/.
91
ii. Por inspeção do código, outros dois interesses foram identificados: logging e atualização
do relógio da simulação.
A Figura 39 mostra alguns fatos obtidos por meio das transformações que analisaram o código
do sistema e armazenaram-nos na base de conhecimento. Maiores informações sobre a especifica-
ção dos fatos podem ser encontradas no Capítulo 4.
Na Figura 39, em A têm-se os fatos relativos à classe Editor, que estende a JPanel e
implementa a ClockListener. Ela possui ainda o modificador public indicando que é pú-
blica. Em B têm-se os fatos relativos ao método jbInit, que é privado (modificador pri-
vate), void e lança uma exceção do tipo Exception por meio da expressão throws. O fato
ExceptionHandlingCCByThrow indica a presença do interesse transversal de tratamento de ex-
ceção pelo throws do método jbInit. Em C, têm-se os fatos relacionados ao método openFile,
92
que além de armazenar informações sobre características do método, também armazena informa-
ções sobre variáveis internas. Além disso, o fato ExceptionHandlingCCByTryCatch(Editor,
class, 9, openFile, Exception, ex) indica a existência do interesse de tratamento de exce-
ção pela presença da expressão “try-catch” no corpo do método, capturando uma exceção do tipo
Exception. E em D têm-se os fatos relativos ao método saveFile, armazenando também infor-
mações sobre as características do método, variáveis internas e indicando a presença do interesse
de tratamento de exceção pela existência de “try-catch”.
classe Clock. Além das informações sobre as características do método, também são arma-
zenadas na forma de fatos, informações sobre os parâmetros de entrada do método como,
por exemplo, o fato MethodParameter(Clock, 21, randomSelect, ClockEvent, e), que
informa a existência de um parâmetro de entrada e, do tipo ClockEvent. Já o fato
TraceCrosscuttingConcern(Clock, 21, randomSelect, out) indica a presença do inte-
resse de rastreamento no método randomSelect, pela expressão “System.out” (parâmetro out
no fato). Em F têm-se os fatos indicando a presença de tratamento de exceção, pelo lançamento de
exceção (método com throw), na classe ClockPanel, método jbInit. E, finalmente, em G, têm-se
os fatos relacionados ao interesse de rastreamento no método jButtonPlay_actionPerformed,
por meio da expressão “System.out”.
Após a identificação dos interesses por meio de transformação de software, partiu-se para a
identificação dos interesses por meio da inspeção do código. A Figura 40 mostra os trechos de
código relacionados ao interesse de atualização do relógio, identificados pela inspeção do código
e pela documentação do sistema.
O passo Identificação de Interesses Transversais deve ser realizado até que todos os interes-
ses sejam identificados pelo Engenheiro de Software, ou até que ele decida que já identificou os
94
Finalizada a identificação, partiu-se para a aplicação das refatorações, visando obter o sistema
reorganizado segundo os princípios da Orientação a Aspectos. As informações obtidas pelas trans-
formações de software, bem como as obtidas pela inspeção do código foram utilizadas no próximo
passo.
As refatorações apresentadas na Seção 4.2.2, Capítulo 4, foram utilizadas para extrair os inte-
resses e encapsulá-los em aspectos.
package org.simulare;
import java.util.*;
public class SimulationImpl implements Simulation {
// simulation controler
(1) private Clock clock;
...
(2) public Clock getClock() {
return clock;
}
(3) public void setClock(Clock clock) {
this.clock = clock;
}
private void remove(Task task, Item item) {
List list = new LinkedList();
Iterator iter = schedule.iterator();
while (iter.hasNext()) {
ClockedTask ct = (ClockedTask) iter.next();
if (task != null && ct.getTask().equals(task.getName())) {
list.add(ct);
}
if (item != null && ct.getItem().equals(item.getName())) {
list.add(ct);
}
}
iter = list.iterator();
while (iter.hasNext()) {
removeSchedule((Schedule) iter.next());
}
}
...
}
95
Por meio da aplicação das refatorações, o interesse de atualização do relógio da simulação foi
extraído e encapsulado em um aspecto. A primeira refatoração aplicada é a EXTRACT FIELD
TO ASPECT, para extrair o atributo clock do tipo Clock, sombreado em (1). Em seguida,
aplicou-se a EXTRACT METHOD TO ASPECT para extrair os métodos getClock (sombreado
em (2)) e setClock (sombreado em (3)) relacionados ao interesse de atualização do relógio da
simulação para o aspecto. Após as refatorações serem aplicadas, tem-se:
package org.simulare;
import java.util.*;
public aspect Foo {
//simulation controler
public org.simulare.Clock org.simulare.SimulationImpl.clock;
public org.simulare.Clock org.simulare.SimulationImpl.getClock(){
return clock;
}
public void org.simulare.SimulationImpl.setClock(org.simulare.Clock clock) {
this.clock = clock;
}
}
Em seguida, foi identificado que o código do corpo do método remove relacionava-se com
o interesse de atualização do relógio da simulação, que estava sendo extraído para um aspecto.
Porém, a assinatura do método não estava relacionada ao contexto do interesse. Aplicou-se então
a refatoração EXTRACT CODE TO ADVICE para mover o código do corpo do método para um
adendo, mantendo a assinatura do método na classe SimulationImpl, obtendo-se:
package org.simulare;
import java.util.*;
public class SimulationImpl implements Simulation {
...
private void remove(Task task, Item item) { }
...
}
E no aspecto, o adendo:
}
if (item != null && ct.getItem().equals(item.getName())) {
list.add(ct);
}
}
iter = list.iterator();
while (iter.hasNext()) {
si.removeSchedule((Schedule) iter.next());
}
}
Como todo o corpo do método foi movido para o adendo, este teve que ser um adendo de
contorno, que toma para si o controle da computação quando o método for executado (designa-
dor execution). Em um adendo de contorno, o comportamento especificado é executado EM
LUGAR do comportamento original do método afetado, que não é executado. Nota-se que as va-
riáveis passadas como parâmetro para o adendo tem a função de capturar o contexto da execução
do método.
Após a extração do corpo do método para um adendo no aspecto, observou-se que a assina-
tura do adendo tornou-se complexa. A fim de melhorar a legibilidade, aplicou-se a refatoração
EXTRACT POINTCUT DEFINITION. Em seguida, para fornecer um nome significativo ao
conjunto de pontos de junção, aplicou-se a RENAME POINTCUT. O seguinte conjunto de pon-
tos de junção foi criado, e uma chamada a ele foi inserida no adendo (em sombreado):
Na execução deste estudo de caso, foram encontrados trechos de código relacionados a inte-
resses transversais que deveriam ser encapsulados em aspectos como, por exemplo, quando uma
classe implementa uma interface ou estende uma outra classe. Um exemplo dito pode ser visto na
Figura 40, onde a classe Schedule estende a classe ClockedTask. Porém não haviam sido espe-
cificadas refatorações para esta situação em especial. Neste caso, a solução encontrada foi extrair
para o aspecto essa propriedade como uma declaração intertipos, conforme se segue:
Após todo o código estar orientado a aspectos, as transformações obtêm o projeto orientado
a aspectos do sistema, conforme pôde ser visto na Figura 31 (capítulo 4). Este último passo é
opcional, ficando a cargo do Engenheiro de Software decidir sobre a sua realização ou não. De
posse do projeto orientado a aspectos, futuramente, possíveis modificações poderão ser feitas no
próprio modelo, em um alto nível de abstração, e em seguida por meio da próprio ferramenta
MVCASE o código pode ser gerado novamente em AspectJ.
5.2 Discussão
Além do estudo de caso apresentado neste capítulo, para avaliação da abordagem, outros 3
estudos de caso, de diferentes domínios, foram realizados. Estes outros 3 estudos de caso foram
realizados com o objetivo de auxiliar na definição da abordagem, mais especificamente na especi-
ficação das expressões regulares, e posteriormente na implementação delas nas transformações de
software, para a identificação dos interesses transversais.
Após a realização dos estudos de caso, pôde-se comprovar uma redução no número de linhas
de código dos sistemas. Para o sistema de Caixa de Banco a redução foi de 168 linhas de có-
digo correspondendo a 6,74%. No Sistema de Vendas pela Web a redução foi de 112 linhas de
código, correspondendo a 5,63%. Já no sistema do Jantar dos Filósofos foi de 46 linhas de có-
digo, correspondendo a 10,82%. E por fim, no XSimulare a redução foi de 307 linhas de código,
correspondendo a 4,14%. A Tabela 4 mostra os resultados obtidos nos 4 estudos de caso.
indicam que os elementos (classes e aspectos) recuperados são menores e mais bem divididos, já
que cada aspecto agrupa um único interesse (menor entrelaçamento de código). Pode-se afirmar
que os módulos são também mais coesos, devido ao fato de que o espalhamento de código é
reduzido pela utilização do DSOA.
ii. Rastreamento de requisitos : Após a separação dos interesses, fica mais fácil rastrear cada
módulo a um requisito específico;
iv. Legibilidade: O novo código é mais claro e menos poluído, porque as operações com os
atributos e os métodos não são espalhadas e entrelaçadas através do sistema;
v. Reuso: Os aspectos identificados e extraídos podem ser implementados de tal maneira que
podem ser reutilizados futuramente. Isto pode dar origem, com a realização de diferentes estudos
de caso, a um framework de aspectos para domínios de interesses transversais específicos, como,
por exemplo, rastreamento, tratamento de exceção e persistência em banco de dados.
Construção dos Transformadores: Visto que a abordagem Phoenix usa um sistema trans-
formacional para auxiliar o Engenheiro de Software em algumas tarefas do processo, admite-se
101
que devem existir os transformadores para identificar os interesses transversais, para reorgani-
zar o código por meio da aplicação de algumas refatorações e para recuperar as informações de
projeto diretamente do código. Entretanto, estes transformadores devem primeiramente ser cons-
truídos, o que requer um esforço e um grande conhecimento sobre as linguagens envolvidas, visto
que além das linguagens do próprio sistema transformacional para especificar as gramáticas e os
transformadores, também é necessário ter um domínio sobre as linguagens de programação e de
modelagem (Java, AspectJ e XMI, por exemplo). O tempo gasto na construção dos transformado-
res também é um fator crítico. Porém, deve-se reforçar que este esforço é reutilizado futuramente
em todo sistema escrito na mesma linguagem, como por exemplo, os transformadores construídos
para identificação de interesses transversais em sistemas Java é genérico para todo sistema imple-
mentado em Java, por se basear na sua BNF. A redução do tempo obtida quando se utilizar estes
transformadores na recuperação do projeto, por exemplo, justifica este esforço inicial; e
Testes: Não existe na abordagem Phoenix uma metodologia bem definida de testes para o
sistema orientado a aspectos obtido. A verificação é feita de forma ad-hoc pelo Engenheiro de
Software. Porém, testes de regressão, por exemplo, poderiam ser aplicados para verificar se a
funcionalidade do sistema orientado a objetos foi preservada no sistema orientado a aspectos obtido
(RAMOS, 2004).
102
Como foi visto na Seção 2.2.4, do Capítulo 2, uma nova camada, baseada em componentes,
está sendo incorporada ao processo de desenvolvimento de software. Os objetivos desta camada
são similares aos da Orientação a Objetos, buscando um maior reuso para aumentar a confiabili-
dade, segurança e diminuir os custos do software (LEE et al., 2003).
Ainda na Seção 2.2.4 foi apresentada a pesquisa de Caldiera e Basili (CALDIERA; BASILI, 1991)
como sendo um dos primeiros trabalhos relevantes neste sentido. Os autores buscavam a extração
automatizada de componentes de software reutilizáveis de sistemas existentes. O processo pro-
posto é dividido em duas fases distintas onde, primeiramente, são escolhidos os candidatos a com-
ponentes e, em seguida, esses são empacotados de forma a possibilitar o seu uso independente. Na
segunda fase, um engenheiro com conhecimento do domínio da aplicação analisa esses candidatos
a componentes para poder determinar quais serviços cada um deles pode fornecer.
Os primeiros trabalhos nesta direção foram os realizados por Kendall (2000) e Lippert e Lo-
pes (2000), ambos já discutidos na seção 2.2.5. Porém, o primeiro processo de reengenharia de
software orientado a aspectos sistemático foi apresentado por Ramos (RAMOS, 2004).
Ramos propôs uma abordagem de reengenharia denominada Aspectig que busca a elicitação
de aspectos em sistemas orientados a objetos, com a sua posterior implementação de acordo com
o paradigma orientado a aspectos. A abordagem é realizada em três etapas distintas, que com-
preendem: Entender a Funcionalidade do Sistema, Tratar Interesses e Comparar o Sistema Ori-
entado a Aspectos com o Orientado a Objetos. Diretrizes auxiliam a modelagem dos interesses
identificados, utilizando diagrama de classes com a notação UML. Outras diretrizes auxiliam a
implementação desses interesses em aspectos, utilizando a linguagem AspectJ. A utilização de tes-
tes de regressão no sistema após a reorganização do código do sistema agora implementado com
aspectos, verificando que a funcionalidade original foi preservada, completa a abordagem.
A principal diferença existente entre a Phoenix e a Aspecting é que a primeira possui fer-
ramentas que automatizam as principais tarefas da Reengenharia, garantindo assim, uma maior
confiabilidade no resultado. Em compensação, a abordagem Aspecting possui uma etapa para ve-
rificação e validação do resultado baseada em testes de regressão, etapa esta que falta à abordagem
Phoenix e pode ser considerado como um dos seus pontos fracos.
6.2 Contribuições
Outra contribuição desta pesquisa vem da integração de diferentes técnicas e mecanismos para
apoiar a abordagem Phoenix, automatizando parte das tarefas do Engenheiro de Software.
Por fim também pode ser considerada como contribuição desta pesquisa o uso combinado de
uma ferramenta CASE com a ferramenta Draco-PUC, para apoiar a reengenharia em diferentes
níveis de abstração, que vão desde o código do sistema orientado a objetos, até o seu projeto
orientado a aspectos.
Ainda considerando a construção de uma ferramenta para mineração, uma visualização gráfica
dos possíveis interesses transversais do código pode ser desenvolvida. Dessa forma, a tarefa de
identificação dos diferentes interesses no sistema será facilitada.
A aplicação das refatorações é um ponto que também pode derivar outras pesquisas, principal-
mente no que diz respeito à automatizar ou semi-automatizar essa aplicação. Diversas pesquisas
avançam nesse sentido para as refatorações orientadas a objetos e tudo indica que possam tam-
bém ser direcionadas para as refatorações orientadas a aspectos, como, por exemplo, o trabalho de
Mendonça e outros (MENDONÇA et al., 2004).
A abordagem Phoenix carece de uma metodologia de testes para garantir que o resultado do
processo está de acordo com o esperado. Porém, como a tecnologia orientada a aspectos é muito
nova, ainda não existem métodos de teste bem definidos para os sistemas orientados a aspectos.
Trabalhos nesse sentido vêm sendo desenvolvidos (BRUEL et al., 2003; HUGHES; GREENWOOD,
2003; MONK; HALL, 2002).
Em relação à ferramenta MVCASE e a notação UAE, ambas devem ser utilizadas em dife-
rentes estudos de caso para validá-las e comprovar a sua eficácia. Novos diagramas podem ser
desenvolvidos para auxiliar na documentação e no DSOA como, por exemplo, um diagrama que
represente como serão os aspectos, classes, e seus relacionamentos após a combinação. Outro di-
agrama muito útil seria para representar o fluxo de execução do sistema orientado a aspectos (uma
extensão do Diagrama de Seqüência).
diretamente em um modelo visual e usar a sincronização ativa para manter o modelo e o código
atualizados durante mudanças rápidas na aplicação.
107
Referências
ABRAHÃO, S.; PRADO, A. Web-enabling legacy systems through software transformations. In:
Proceedings of IEEE International Workshop on Advanced Issues of E-Commerce and Web-based
Information Systems. [S.l.: s.n.], 1999. p. 149–152.
ASPECTJ. AspectJ project in Eclipse Projects homepage. maio 2004. Disponível em:
<http://eclipse.org/aspectj/>.
BANIASSAD, E.; CLARKE, S. Theme: An approach for aspect-oriented analysis and design. In:
Proceedings of the 26th International Conference on Software Engineering (ICSE’04). [S.l.: s.n.],
2004.
BAXTER, I. D.; PIDGEON, C. W. Software change through design maintenance. In: Proceedings
of the 13th International Conference on Software Maintenance (ICSM’97). [S.l.]: IEEE Computer
Society Press, 1997. p. 250–259. ISBN 0-8186-8014-8, 0-8186-8013-X, 0-8186-8015-6.
BAYER, J. Towards engineering product lines using concerns. In: Workshop on Multi-Dimensional
Separation of Concerns in Software Engineering (ICSE 2000). [s.n.], 2000. Disponível em:
<http://www.research.ibm.com/hyperspace/workshops/icse2000/Papers/bayer.pdf>.
108
BENNETT, K. H.; RAJLICH, V. T. Software maintenance and evolution: a roadmap. In: Pro-
ceedings of the 22nd International Conference on Software Engineering (ICSE’2000). Future of
Software Engineering Track. [S.l.]: ACM Press, 2000. p. 73–87. ISBN 1-58113-253-0.
BERGMANN, U.; LEITE, J. From applications domains to executable domains: Achieving reuse
with a domain network. In: Proceedings of the 6th International Conference on Software Reuse
(ICSR’2000). [S.l.: s.n.], 2000.
BERGMANN, U.; LEITE, J. C. Domain networks in the software development process. Pro-
ceedings of the 7th International Conference on Software Reuse (ICSR’2002), Lecture Notes in
Computer Science, v. 2319, p. 194–209, abr. 2002.
BIANCHI, A. et al. Iterative reengineering of legacy systems. IEEE Trans. Softw. Eng., IEEE
Press, v. 29, n. 3, p. 225–241, 2003. ISSN 0098-5589.
BIANCHI, A.; CAIVANO, D.; VISAGGIO, G. Method and process for iterative reengineering of
data in a legacy system. In: Proceedings of the Seventh Working Conference on Reverse Enginee-
ring (WCRE’00). [S.l.]: IEEE Computer Society, 2000. p. 86–97. ISBN 0-7695-0881-2.
BOOCH, G. Object-Oriented Analysis and Design with Applications. Second. Redwood City:
Benjamin Cummings, 1994. ISBN 0-8053-5340-2.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language User Guide. 1.
ed. Reading, Massachusetts, USA: Addison-Wesley, 1999. ISBN 0-201-57168-4.
BRUEL, J. et al. Using aspects to develop built-in tests for components. In: The 4th AOSD Mode-
ling With UML Workshop, UML’2003. [S.l.: s.n.], 2003.
CALDIERA, G.; BASILI, V. R. Identifying and qualifying reusable software components. IEEE
Computer, v. 24, n. 2, p. 61–71, fev. 1991. ISSN 0018-9162.
CASTOR, F. et al. Jats: A java transformation system. In: Anais XV Simpósio Brasileiro de Enge-
nharia de Software, Sessão de Ferramentas. [S.l.: s.n.], 2001.
CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. IEEE Trans.
Softw. Eng., IEEE Press, v. 20, n. 6, p. 476–493, 1994. ISSN 0098-5589.
CHIKOFSKY, E. J.; CROSS, J. H. Reverse engineering and design recovery: a Taxonomy. IEEE
Software, v. 1, n. 7, p. 13–17, jan. 1990.
CLARKE, S.; WALKER, R. Towards a standard design language for AOSD. In: Proceedings of
the 1st International Conference on Aspect-Oriented Software Development (AOSD’2002). [S.l.]:
ACM Press, 2002. p. 113–119.
CLEMENTE, P.; SÁNCHEZ, F.; PÉREZ, M. Modeling with UML Component-based and Aspect
Oriented Programming Systems. In: Proceedings of the 12th Workshop for PhD Students in Object
Oriented Systems. ECOOP Workshops 2002. [S.l.]: Springer-Verlag, 2002. p. 44–54.
CORDY, J.; CARMICHAEL, I. The TXL Programming Language Syntax and Informal Semantics.
[S.l.], 1993. v. 7.
DEURSEN, A. v.; MARIN, M.; MOONEN, L. Aspect Mining and Refactoring. In: UNIVERSITY
OF WATERLOO, CANADA. Proceedings of the First International Workshop on REFactoring:
Achievements, Challenges, Effects (REFACE03). Held in conjunction with WCRE 2003. [S.l.],
2003.
DONNELLY, C.; STALLMAN, R. Bison. The YACC-compatible Parser Generator. ago. 2004.
Disponível em: <http://dinosaur.compilertools.net/bison/index.html>.
D’SOUZA, D.; WILLS, A. Objects, Components, and Frameworks with UML: The Catalysis
Approach. First. [S.l.]: Addison-Wesley, 1999. ISBN 0-201-31012-0.
ELRAD, T. et al. Discussing Aspects of AOP. Communications of ACM, v. 44, n. 10, p. 33–38,
out. 2001a.
FOWLER, M. et al. Refactoring: improving the design of existing code. [S.l.]: Addison-Wesley,
1999. (Object Technology Series). ISBN 0-201-48567-2.
GALL, H.; KLÖSCH, R. Capsule oriented reverse engineering for software reuse. European Soft-
ware Engineering Conference (ESEC’93), Lecture Notes in Computer Science(LNCSD9), v. 717,
p. 418–433, 1993. ISSN 0302-9743.
GALL, H.; KLÖSCH, R. Program transformation to enhance the reuse potential of procedural
software. In: Proceeding of the ACM Symposium on Applied Computing (SAC’1994). [S.l.]: ACM
Press, 1994. p. 99–104. ISBN 0-89791-647-6.
GARCIA, V. et al. Em direção a uma abordagem para separação de interesses por meio de minera-
ção de aspectos e refactoring. In: SOLAR, M.; FERNÁNDEZ-BACA, D.; CUADROS-VARGAS,
E. (Ed.). 30ma Conferencia Latinoamericana de Informática (CLEI2004). [S.l.], 2004a. p. 317–
328. ISBN 9972-9876-2-0.
GARCIA, V. C. et al. Uma ferramenta case para o desenvolvimento de software orientado a aspec-
tos. In: XI Sessão de Ferramentas do XVIII Simpósio Brasileiro de Engenharia de Software (SBES
2004). [S.l.: s.n.], 2004b. ISBN 85-7669-004-7.
GARCIA, V. C. et al. Using aspect mining and refactoring to recover knowlegde embedded in
object-oriented legacy system. In: Proceedings of the IEEE International Conference on Informa-
tion Reuse and Integration (IEEE IRI-2004). [S.l.]: IEEE Systems, Man, and Cybernetics Society
(SMC), 2004c. p. 30–35. ISBN 0-7803-8819-4.
111
GARCIA, V. C. et al. Towards an approach for aspect-oriented software reengineering. In: Proce-
edings of the 7th International Conference on Enterprise Information Systems (ICEIS-2005). [S.l.:
s.n.], 2005.
HERRERO, J. L. et al. Introducing Separation of Aspects at Design Time. In: Proceedings of the
14th European Conference Object-Oriented Programming (ECOOP’2000). Workshop on Aspects
and Dimensions of Concerns. [S.l.: s.n.], 2000.
HILSDALE, E.; KICZALES, G. Aspect-oriented programming with AspectJ. In: . [S.l.: s.n.],
2001. Proceedings of the 16th Object Oriented Programming Systems Languages and Applications
(OOPSLA’2001). Tutorial. Tampa Bay, FL, USA.
HUGHES, D.; GREENWOOD, P. Aspect testing framework. In: FMOODS/DAIS 2003 Student
Workshop. [S.l.: s.n.], 2003.
IWAMOTO, M.; ZHAO, J. Refactoring aspect-oriented programs. In: The 4th AOSD Modeling
With UML Workshop, UML’2003. [S.l.: s.n.], 2003.
JANZEN, D.; De Volder, K. Navigating and querying code without getting lost. In: Proceedings
of the 2nd international conference on Aspect-oriented software development. [S.l.]: ACM Press,
2003. p. 178–187. ISBN 1-58113-660-9.
JESUS, E.; FUKUDA, A.; PRADO, A. Reengenharia de software para platafomas distribuídas
orientadas a objetos. In: XIII Simpósio Brasileiro de Engenharia de Software (SBES’99). [S.l.:
s.n.], 1999. p. 289–304.
112
KICZALES, G. et al. Getting started with AspectJ. Communications of ACM, v. 44, n. 10, p. 59–65,
out. 2001a.
KICZALES, G. et al. An overview of AspectJ. In: KNUDSEN, J. L. (Ed.). Proceedings of 15th Eu-
ropean Conference on Object-Oriented Programming (ECOOP’2001), Lecture Notes in Computer
Science (LNCS) 2072. Berlin: Springer-Verlag, 2001b. p. 327–353.
KICZALES, G. et al. Aspect-Oriented Programming. In: Proceedings of the 11st European Confe-
rence Object-Oriented Programming (ECOOP’97). [S.l.]: Springer Verlag, 1997. (LNCS, v. 1241),
p. 220–242.
KLEPPE, A. et al. MDA Explained : The Model Driven Architecture: Practice and Promise. [S.l.]:
Boston, EUA : Addison-Wesley, 2003.
LEE, E. et al. A reengineering process for migrating from an object-oriented legacy system to a
component-based system. In: Proceedings of the 27th Annual International Computer Software
and Applications Conference (COMPSAC). [S.l.]: IEEE Computer Society Press, 2003. p. 336–
341.
LEITE, J. C.; SANT’ANNA, M.; FREITAS, F. G. Draco-PUC: A Technology Assembly for Do-
main Oriented Software Development. In: Proceedings of the 3rd International Conference on
Software Reuse (ICSR’94). [S.l.]: IEEE Computer Society Press, 1994. p. 94–100.
LEITE, J. C.; SANT’ANNA, M.; PRADO, A. F. do. Porting cobol programs using transformatio-
nal approach. Journal of Software Maintenance: Research and Practice, John Wiley & Sons Ltd,
v. 9, p. 3–31, out. 1996.
LIPPERT, M.; LOPES, C. V. A study on exception detecton and handling using aspect-oriented
programming. In: Proceedings of the 22nd International Conference on Software Engineering.
[S.l.]: ACM Press, 2000. p. 418–427. ISBN 1-58113-206-9.
MENDONÇA, N. et al. RefaX: A refactoring framework based on XML. In: Proceedings of the
20th. International Conference on Software Maintenace (ICSM’2004). [S.l.]: IEEE Computer So-
ciety Press, 2004.
MONK, S.; HALL, S. Virtual Mock Objects using AspectJ with JUnit. 2002.
XProgramming.com. jan. 2002. Acessado em: 06/01/2005. Disponível em:
<http://xprogramming.com/xpmag/virtualMockObjects.htm>.
MOONEN, L. Exploring software systems. In: Proceedings of the 19th International Conference
on Software Maintenance (ICSM’2003). [S.l.]: IEEE Computer Society Press, 2003.
MORAES, J. ao Luis Cardoso de. Uma Abordagem para Construção e Reutilização de Fra-
meworks de Componentes de Software implementados em Delphi. Dissertação (Mestrado) — Pro-
grama de Pós Graduação em Ciência da Computação, Universidade Federal de São Carlos, 2004.
MÜLLER, H. A. et al. Reverse engineering: a roadmap. In: Proceedings of the 22nd International
Conference on Software Engineering (ICSE’2000). Future of Software Engineering Track. [S.l.]:
ACM Press, 2000. p. 47–60. ISBN 1-58113-253-0.
NEIGHBORS, J. The Draco approach to constructing software from reusable components. In:
IEEE Transactions on Software Engineering. v.se-10, n.5. [S.l.: s.n.], 1983. p. 567–574.
NEIGHBORS, J. M. Draco: A method for engineering reusable software systems. In: BIGGERS-
TAFF, T. J.; PERLIS, A. J. (Ed.). Software Reusability – Concepts and Models. [S.l.]: ACM Press,
1989. I, p. 295–319.
PAWLAK, R. et al. A UML notation for aspect-oriented software design. In: Proceedings of the 1st
International Conference on Aspect-Oriented Software Development (AOSD’2002). [S.l.]: ACM
Press, 2002.
PERES, D. R. et al. TB-REPP - Padrões de Processo para a Engenharia Reversa baseada em Trans-
formações. In: HAMMER, R.; ANDRADE, R. M. C. (Ed.). The Third Latin American Conference
on Pattern Languages of Programming (SugarLoafPLOP 2003). [s.n.], 2003. p. 191–215. ISBN
85-87837-08-7. Disponível em: <http://www.cin.ufpe.br/ sugarloafplop/final_articles/12_TB-
REPP-Final.pdf>.
RAMOS, R. A. Aspecting: Abordagem para Migração de Sistemas OO para Sistemas AO. Dis-
sertação (Mestrado) — Programa de Pós Graduação em Ciência da Computação, Universidade
Federal de São Carlos, 2004.
ROSS, D. T. Structured analysis (SA): A language for communicating ideas. IEEE Transactions
on Software Engineering, v. 3, n. 1, p. 16–34, jan. 1977. ISSN 0098-5589. Special collection on
Requirement Analysis.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language Reference Ma-
nual. First. Reading, Massachusetts, USA: Addison-Wesley, 1999. ISBN 0-201-30998-x.
SNEED, H. M. Planning the reengineering of legacy systems. IEEE Software, v. 12, n. 1, p. 24–34,
jan. 1995. ISSN 0740-7459.
SNEED, H. M. Object-oriented cobol recycling. In: Proceedings of the 3rd Working Conference on
Reverse Engineering (WCRE’96). [S.l.]: IEEE Computer Society Press, 1996. p. 169–178. ISBN
0-8186-7674-4, 0-8186-7676-0.
SOMMERVILLE, I. Software Engineering. Fifth edition. [S.l.]: Addison-Wesley, 1996.
STEIN, D.; HANENBERG, S.; UNLAND, R. An UML-based Aspect-Oriented Design Notation.
In: Proceedings of the 1st International Conference on Aspect-Oriented Software Development
(AOSD’2002). [S.l.]: ACM Press, 2002. p. 106–112.
STEVENS, P.; POOLEY, R. Systems reengineering patterns. In: Proceedings of the ACM SIG-
SOFT 6th International Symposium on the Foundations of Software Engineering (FSE-98). New
York: ACM Press, 1998. (Software Engineering Notes, v. 23, 6), p. 17–23. ISSN 0163-5948.
SUZUKI, J.; YAMAMOTO, Y. Extending UML with aspects: Aspect support in the de-
sign phase. In: Proceedings of 13rd the European Conference Object-Oriented Programming
(ECOOP’99). International Workshop on Aspect-Oriented Programming. [s.n.], 1999. Disponí-
vel em: <http://trese.cs.utwente.nl/aop-ecoop99/papers/suzuki.pdf>.
SYSTA, T. The relationships between static and dynamic models in reverse engineering java soft-
ware. In: Proceedings of the 6th Working Conference on Reverse Engineering (WCRE’99). [S.l.]:
IEEE Computer Society Press, 1999.
TARR, P. et al. N degrees of separation: Multi-dimensional separation of concerns. In: Proceedings
of 21st International Conference on Software Engineering (ICSE’99). Los Angeles CA, USA:
IEEE Computer Society Press, 1999. p. 107–119.
TOGETHER. Borland Together. Borland Software Corporation. 2004. Disponível em:
<http://www.borland.com/together/>.
UMAR, A. Application (Re)Engineering: Building Web-Based Applications and Dealing with Le-
gacies. Upper Saddle River, NJ: Prentice-Hall, 1997.
UML. Unified Modeling Language (UML) - Version 1.5. Object Management Group. maio 2004.
Disponível em: <http://www.uml.org>.
VISAGGIO, G. Ageing of a data intensive legacy system: Symptoms and remedies. Journal of
Soft. Maintenance and Evolution, v. 13, n. 5, p. 281–308, 2001.
WATERS, R. C. Program translation via abstraction and reimplementation. IEEE Trans. Softw.
Eng., IEEE Press, v. 14, n. 8, p. 1207–1228, 1988. ISSN 0098-5589.
WILE, D. POPART: Producer of Papers and Related Tools System Builders Manual. [S.l.], 1993.
WILKENING, D. E. et al. A reuse approach to software reengineering. Journal of Systems and
Software, v. 30, n. 1-2, p. 117–125, 1995. ISSN 0164-1212.
YEH, A. S.; HARRIS, D. R.; REUBENSTEIN, R. Recovering abstract data types and object
instances from a conventional procedural language. In: WILLS, L. M.; NEWCOMB, P.; CHI-
KOFSKY, E. J. (Ed.). Proceedings: Second Working Conference on Reverse Engineering. [S.l.]:
IEEE Computer Society Press, 1995. p. 227–236. ISBN 0-8186-7111-4.
116
Apêndice A
Durante este trabalho foram publicados diversos artigos, nacionais e internacionais, comple-
tos e resumidos. Além disso, também foi obtida uma premiação na Sessão de Ferramentas do
Simpósio Brasileiro de Engenharia de Software realizado em Brasília, Outubro de 2004.
Prêmio
Ano: 2004
Publicações
Ano: 2005
ALVARO, Alexandre; ALMEIDA, Eduardo Santana de; LUCRÉDIO, Daniel; GARCIA, Vi-
nicius Cardoso; PRADO, Antonio Francisco do; MEIRA, Silvio Romero de Lemos. ASPECT
IPM: Towards an Incremental Process Model Based on AOP for Component-Based Systems.
In the 7th International Conference on Enterprise Information Systems (ICEIS’2005), 24-28 May
2005, Miami, USA. Lecture Notes in Computer Science (LNCS) Springer-Verlag. A ser publicado
GARCIA, Vinicius Cardoso; LUCRÉDIO, Daniel; PRADO, Antonio Francisco do; AL-
MEIDA, Eduardo Santana de; ALVARO, Alexandre; MEIRA, Silvio Romero de Lemos. Towards
an Approach for Aspect-Oriented Software Reengineering. In the 7th International Conference
on Enterprise Information Systems (ICEIS’2005), 24-28 May 2005, Miami, USA. A ser publicado
Ano: 2004
GARCIA, Vinicius Cardoso; LUCRÉDIO, Daniel; PRADO, Antonio Francisco do; PIVETA,
Eduardo Kessler; ZANCANELLA, Luiz Carlos; ALMEIDA, Eduardo Santana de; ALVARO, Ale-
xandre. Reengenharia de sistemas orientados a objetos através de transformações e minera-
118
ção de aspectos. Portuguese/Spanish Tracks In the Third International Information and Telecom-
munication Technologies Symposium (I2TS’2004), December 6-9, 2004 São Carlos, SP - Brazil.
ALVARO, Alexandre; ALMEIDA, Eduardo Santana de; LUCRÉDIO, Daniel; GARCIA, Vi-
nicius Cardoso. Aspect IPM: Towards an Incremental Process Model based on AOP for
Component-Based Development. In the First Brazilian Workshop on Aspect-Oriented Software
Development (WASP’2004), in conjunction with SBES 2004 Conference, 2004, Brasília, Brazil.
GARCIA, Vinicius Cardoso; LUCRÉDIO, Daniel; PRADO, Antonio Francisco do; ALVARO,
Alexandre; ALMEIDA, Eduardo Santana de. Using Reengineering and Aspect-based Techni-
ques to Retrieve Knowledge Embedded in Object-Oriented Legacy System. In the IEEE In-
ternational Conference on Information Reuse and Integration (IEEE IRI-2004), 2004, Hilton, Las
Vegas, Nevada, USA.
ALMEIDA, Eduardo Santana de; ALVARO, Alexandre; LUCRÉDIO, Daniel; GARCIA, Vini-
cius Cardoso; MEIRA; Silvio Romero de Lemos. RiSE Project: Towards a Robust Framework
for Software Reuse. In the IEEE International Conference on Information Reuse and Integration
(IEEE IRI-2004), 2004, Hilton, Las Vegas, Nevada, USA.
GARCIA, Vinicius Cardoso; PIVETA, Eduardo Kessler; LUCRÉDIO, Daniel; ALVARO, Ale-
xandre; ALMEIDA, Eduardo Santana de; PRADO, Antonio Francisco do; ZANCANELLA, Luiz
Carlos. Em direção a uma abordagem para separação de interesses por meio de Mineração de
Aspectos e Refactoring. In XXX LATIN AMERICAN CENTER OF STUDIES IN COMPUTER
SCIENCE (CLEI 2004 Conference), 2004, Arequipa, Peru.
GARCIA, Vinicius Cardoso; PRADO, Antonio Francisco do. Phoenix: Uma Abordagem
para a Reengenharia de Software Orientada a Aspectos. In IX Workshop de Teses e Disserta-
ções em Engenharia de Software - XVIII Simpósio Brasileiro de Engenharia de Software. (SBES
2004 Conference), 2004, Brasília, Brazil.
119
GARCIA, Vinicius Cardoso; LUCRÉDIO, Daniel; FROTA, Luíza; ALVARO, Alexandre; AL-
MEIDA, Eduardo Santana de; PRADO, Antonio Francisco do. Uma ferramenta CASE para o
Desenvolvimento de Software Orientado a Aspectos. In XI Sessão de Ferramentas do XVIII
Simpósio Brasileiro de Engenharia de Software. 2004. (SBES 2004 Conference), 2004, Brasília,
Brazil.
GARCIA, Vinicius Cardoso; PIVETA, Eduardo Kessler; LUCRÉDIO, Daniel; ALVARO, Ale-
xandre; ALMEIDA, Eduardo Santana de; PRADO, Antonio Francisco do; ZANCANELLA, Luiz
Carlos. Manipulating Crosscutting Concerns. In The Fourth Latin American Conference on Pat-
tern Languages of Programming (SugarLoafPLoP 2004 Conference), 2004, Porto das Dunas-CE,
Brazil.
LUCRÉDIO, Daniel; ALMEIDA, Eduardo Santana de; GARCIA, Vinicius Cardoso; AL-
VARO, Alexandre; PIVETA, Eduardo Kessler. Student’s PLoP Guide: A Pattern Family to
Guide Computer Science Students during PLoP Conferences. In The Fourth Latin Ameri-
can Conference on Pattern Languages of Programming (SugarLoafPLoP 2004 Conference), 2004,
Porto das Dunas-CE, Brazil.
MORAES, João Luis Cardoso de; BOSSONARO, Adriano Aleixo; FONTANETTE, Valdi-
rene; LUCRÉDIO, Daniel; GARCIA, Vinicius Cardoso; PRADO, Antonio Francisco do. An
Approach for Construction and Reuse of Software Components Frameworks implemented
in Delphi. In Proceedings of The Fourth International School and Symposium on Advanced Dis-
tributed Systems (ISSADS’2004), 2004, March 8-10 2004 in Guadalajara Jalisco, Mexico.
Ano: 2003