A Programação Orientada a Aspectos

A.1 Introdução
À medida que aumenta a complexidade dos sistemas de software surge a necessidade de
melhores técnicas de programação, objetivando organizar e apoiar o processo de
desenvolvimento de software. Com isso, no âmbito da Ciência da Computação, essas
técnicas de programação têm evoluindo desde construções de baixo nível – como
linguagens de máquina – até abordagens de alto nível – como Programação Orientada a
Objetos (POO) [Elrad et al., 2001].
Segundo [Gradeck and Lesiecki, 2003], a engenharia de software e as linguagens de
programação possuem um relacionamento mútuo. Os sistemas são considerados pela
maioria dos processos de desenvolvimento de software como unidades (módulos) cada
vez menores. Enquanto, as linguagens de programação fornecem meios para definir e
compor abstrações das unidades do sistema de diversas maneiras para produção do
sistema como um todo.
Em meados da década de 70, com o advento de um novo paradigma de programação,
a Programação Orientada a Objetos (POO), teve grandes avanços no desenvolvimento
de software até os dias atuais, sendo atualmente, o paradigma de programação
dominante no desenvolvimento de sistemas de software [Laddad, 2003]. Este paradigma
possibilitou a construção de sistemas particionados em módulos (classes) que trabalham
em conjunto para fornecer funcionalidades específicas de um conjunto de requisitos do
sistema com responsabilidades bem definidas, permitindo maiores níveis de reuso e
manutenibilidade [Gradeck and Lesiecki, 2003].
O princípio da separação de interesses (concerns) foi introduzido em [Dijkstra,
1976], tendo como objetivo dividir o domínio do sistema em partes menores com o
intuito de entender melhor cada parte isoladamente. Um interesse (concern) é alguma
parte do domínio do sistema que se deseja tratar com uma unidade conceitual única. No
desenvolvimento de software, um interesse pode ser visto como um requisito funcional
ou não funcional de um sistema. De forma geral, os vários interesses do sistema devem
ser separados em módulos – modularizados – de acordo com as abstrações do
desenvolvimento de software providas por linguagens, métodos e ferramentas. Pode-se
classificar os interesses de um sistema de software como [Laddad, 2003]:
 • Interesses do negócio - capturam a funcionalidade central de um módulo, por
exemplo, procedimento de quitação de uma compra;
• Interesses em nível de sistema - capturam requisitos periféricos, no nível do
sistema e que atravessam múltiplos módulos, por exemplo, segurança, logging,
persistência.
A POO permitiu uma melhor separação dos diversos interesses do sistema, com a
estruturação de projetos e códigos mais próximos do que é idealizado naturalmente
pelos desenvolvedores [Elrad et al., 2001]. No caso da POO, as abstrações básicas para
os interesses são classes, objetos, métodos e atributos. Entretanto, essas abstrações
podem não ser suficientes para separar em um único módulo, alguns dos interesses
contidos em muitos sistemas de software complexos, tendo assim os comportamentos
distribuídos ao longo de vários e, às vezes não relacionados, módulos. Esses interesses
são chamados de interesses transversais (crosscutting concerns), já que, inerentemente,
a sua implementação se dá através da adição de código em diversos objetos ao longo do
software não estando diretamente relacionado com a funcionalidade definida pra estes
objetos. Desta forma, a implementação mapeia os requisitos em uma única dimensão
como pode ser visualizado na Figura 1. Podemos citar como exemplos de interesses
transversais logging, integridade de transações, autenticação, segurança, desempenho,
distribuição, persistência e profiling [Elrad et al., 2001].

Figura 1 – Mapeamento de um interesse transversal sem o uso da Programação Orientada a Aspectos.

Como exemplo de um interesse transversal, utilizaremos um editor de figuras

apresentado em [Elrad et al., 2001]. O sistema de edição de figuras é composto por duas
classes concretas de elementos de figura, pontos e linhas. Sempre que os elementos da

2
figura forem movimentados, é necessário que a tela seja atualizada. Desta maneira,
observa-se através do diagrama de classes apresentado na Figura 2, que o interesse de
atualização da tela não pertence a nenhuma das duas classes (Ponto e Linha), mas
entrecorta ambas e, por isso, pode ser entendido como transversal a essas classes [Elrad
et al., 2001].

Figura 2 – Interesse transversal de atualização da tela (adaptado de [Elrad et al., 2001]).

Sem o uso de técnicas apropriadas para a separação de interesses e modularização,

alguns fenômenos são observados e podem ser classificados nas seguintes categorias:
• Código entrelaçado (code tangling) - acontece quando a implementação de
um módulo em um sistema de software interage simultaneamente com vários
interesses, tais como logging, autenticação, multi-threaded safety, validações,
entre outras. Na Figura 3 é ilustrado o código entrelaçado em um módulo,
causado pela execução simultânea de múltiplos interesses.

Figura 3 – Código entrelaçado causado pela execução simultânea de múltiplos interesses [Laddad, 2003].

• Código espalhado (code scattering) - acontece quando um interesse é

implementado em múltiplos módulos. Desde que interesses transversais, por

3
 definição, são espalhados por vários módulos, logo sua implementação
também se espalha por esses módulos. Por exemplo, considere o mecanismo
de logging, fazendo uso das classes do Apache TomCat, um servidor web
baseado em Java. Na Figura 4 as colunas representam cada uma das classes
do sistema e, a linhas grifadas são referentes à funcionalidade de logging.

Figura 4 – Interesse de logging no TomCat.

A implementação de códigos entrelaçados e espalhados afetam o desenvolvimento

do software de diversas maneiras:
• Forte acoplamento - métodos das classes primárias precisam conhecer
métodos das classes que implementam funcionalidades espalhadas
(crosscutting concerns);
• Fraca coesão - métodos das classes afetadas contêm instruções que não estão
diretamente relacionadas a funcionalidades que implementam;
• Redundância - muitos fragmentos de código semelhantes ocorrem em
diversos pontos do código-fonte;
• Dificuldades de compreender, manter e reusar - como consequência da
implementação de crosscutting concerns ser dependente do código espalhado
pelo software, sua compreensão, manutenção e reutilização ficam
prejudicadas.
Contudo, parte dessas limitações podem ser solucionadas com o uso de técnicas com
o intuito de modularizar o desenvolvimento de software incluindo mix-in classes,
padrões de projeto, soluções específicas de domínio. Por outro lado, existem algumas
extensões do paradigma POO que tentam solucionar suas limitações visando uma maior

4
modularidade de software, tais como Aspect-Oriented Programming (Programação
Orientada a Aspectos) [Kiczales et al., 1997], Subject-Oriented Programming
(Programação Orientada a Sujeito) [Osser and Tarr, 1999] e Adaptive Programming
(Programação Adaptativa) [Lieberherr et al., 1994]. Dentre essas extensões a que tem se
mostrado mais promissora é a Programação Orientada a Aspectos (POA) [Elrad et al.,
2001].
A POA foi proposta em [Kiczales et al., 1997] como uma técnica objetivando
melhorar o suporte à modularização dos interesses transversais por meio de abstrações
que possibiltem a separação e composição destes interesses na construção dos sistemas
de software.

A.2 Desenvolvimento de Software Orientado a Aspectos

A POA foi proposta com o objetivo de facilitar a modularização dos interesses
transversais, complementando a POO. A POA não tem o intuito de ser um novo
paradigma de programação, mas uma nova técnica que deve ser utilizada em conjunto
com linguagens de programação para construção de sistemas de software de melhor
arquitetura, auxiliando na manutenção dos vários interesses e a compreensão do
software. Entretanto, não é um antídoto para um design ruim ou insuficiente [Elrad et al.,
2001].
Em um sistema de software os interesses são implementados em blocos de código,
que manipulam dados. Os interesses que podem ser encapsulados de forma clara em
uma unidade de função são chamados de componentes. Em POO esses interesses são
modularizados em objetos, compostos por métodos que contêm a implementação do
interesse, e os atributos compostos pelos dados manipulados pelos métodos. Em POA é
introduzido um novo mecanismo para abstração e composição, que facilita a
modularização dos interesses transversais, o aspecto (aspect). Desta forma, os sistemas
de software são decompostos em componentes e aspectos. Assim, os requisitos
funcionais normalmente são organizados em componentes através de uma linguagem
POO, como Java, e os requisitos não funcionais como aspectos relacionados as
propriedades que afetam o comportamento do sistema [Kiczales et al., 1997].
A POA envolve basicamente três etapas distintas de desenvolvimento:
• Decompor os interesses (aspectual decomposition) – identificar e separar os
interesses transversais dos interesses do negócio;

5
 • Implementar os interesses (concern implementation) – implementar cada
um dos interesses identificados separadamente;
• Recompor o aspectual (aspectual recomposition) – nesta etapa, tem-se
integrador de aspectos que especifica regras de recomposição para criação de
unidades de modularização – aspectos. A esse processo de junção da
codificação dos componentes e dos aspectos é denominada combinação
(weaving).
Na Figura 5, é ilustrado as etapas de desenvolvimento da POA.

Figura 5 – Etapas de desenvolvimento de software orientado a aspectos [Laddad, 2003].

Uma implementação de POA consiste dos seguintes elementos [Kiczales et al.,

1997]:
• Linguagem de componentes – responsável por implementar interesses do
negócio do sistema de software, por exemplo, Java;
• Linguagem de aspecto – deve suportar a implementação de interesses
transversais de forma clara e concisa, fornecendo meios para construção de
estruturas que descrevam o comportamento do aspecto e definam em que
situações estes ocorrem, por exemplo, AspectJ;
• Combinador de aspectos – sua tarefa é combinar aspectos (aspect weaver)
com programas escritos na linguagem de componentes com os programas
escritos na linguagem de aspectos.
As linguagens de aspectos são classificadas em linguagens de propósito específico e
de propósito geral. Como o próprio nome diz, as linguagens de propósito específico
tratam somente de determinados aspectos, impondo geralmente algumas restrições
quanto ao uso das linguagens de componentes. Por outro lado, as linguagens de
propósito geral permitem a implementação de qualquer tipo de aspecto, sendo de uso

6
mais familiar e de fácil adoção pelos desenvolvedores, uma vez que geralmente a
linguagem de aspecto compartilha o mesmo ambiente de desenvolvimento utilizado
pela linguagem de componente [Kiczales et al., 2001].
No contexto deste trabalho será abordada como linguagem de componentes a
linguagem Java e no contexto da linguagem de aspecto a linguagem AspectJ.

A.3 AspectJ
A linguagem AspectJ [Kiczales et al., 2001] é uma extensão orientada a aspectos de
propósito geral da linguagem Java. Foi criada pela Xerox Palo Alto Research Center em
1997 e posteriormente agregada ao projeto Eclipse da IBM EM 2002. Além dos
elementos oferecidos pela POO como classes, métodos, atributos e etc, são
acrescentados novos conceitos e construções ao AspectJ, tais como: aspectos (aspects),
conjuntos de junção (point cuts), pontos de junção (join points), adendos (advices) e
declarações inter-tipos (inter-type declarations)1.
Aspects são os elementos básicos dessa abordagem, pois podem alterar a estrutura
estática ou dinâmica de um programa. A estrutura estática é alterada adicionando, por
meio das declarações inter-tipos, membros (atributos, métodos ou construtores) a uma
classe, modificando assim a hierarquia do sistema. Já a alteração numa estrutura
dinâmica de um programa ocorre em tempo de execução por meio dos conjuntos de
junção, os quais são selecionados por pointcuts, e através da adição de comportamentos
(adendos) antes ou depois dos pontos de junção [Kiselev, 2002].
A seguir, são apresentados cada um dos conceitos e construções que compõem o
AspectJ.

A.3.1 Pontos de Junção (Join Points)

Para o entendimento do AspectJ é de fundamental importância o conceito de ponto de
junção. Pontos de junção são pontos na execução de um programa de componentes
aonde os aspectos serão aplicados. O AspectJ pode detectar e operar sobre os seguintes
tipos de pontos de junção [Gradecki and Lesiecki, 2003]:
• chamada e execução de métodos;
• chamada e execução de construtores;

1
As traduções utilizadas neste trabalho seguem as recomendações definidas no WASP 2004 – 1º
Workshop Brasileiro de Desenvolvimento de Software Orientado a Aspectos, disponíveis em
http://twiki.im.ufba.br/bin/view/AOSDbr/TermosEmPortugues

7
 • execução de inicialização;
• execução de contrutores;
• execução de inicialização estática;
• pré-inicialização de objetos;
• inicialização de objetos;
• referência a campos;
• execução de tratamento de exceções.
Na Figura 6, é demonstrado um exemplo apresentado em [Soares and Borba, 2002],
de um fluxo de execução entre dois objetos, identificando alguns pontos de junção.

Figura 6 – Pontos de junção de um fluxo de execução [Kiczales et al., 2001].

O primeiro ponto de junção é a invocação de um método de um objeto A, o qual

pode retornar sucesso ou lançar uma exceção. O próximo ponto de junção é a execução
deste método, que por sua vez também pode retornar sucesso ou lançar uma exceção.
Durante a execução do método do objeto A é invocado um método de um objeto B,
podendo retornar sucesso ou lançar uma exceção. A invocação e execução destes
métodos são pontos de junção.

A.3.2 Conjuntos de Junção (Pointcuts)

Um aspecto no AspectJ geralmente define conjuntos de junção, que são aninhados por
pontos de junção através de operadores lógicos e, ou e não (&&, ||, e !). Eles são
responsáveis por selecionar pontos de junção, ou seja, eles detectam em que ponto do
programa os aspectos deverão interceptar.

8
 Podemos declarar um conjunto de junção semelhante a uma classe em Java, podendo
da mesma maneira que atributos e métodos dessas classes, especificar um quantificador
de acesso aos conjuntos de junção, podendo ser públicos, privados ou final, mas não
podem ser sobrecarregados. Também podem ser declarados abstratos, mas somente
dentro de aspectos abstratos, e ainda podem ser nomeados ou anônimos [Kiselev, 2002].
A declaração de um pointcut nomeado deve seguir a seguinte sintaxe:
pointcut <Nome> (Argumentos): <corpo>;
Para definir um conjunto de junção utiliza-se construtores de AspectJ nomeados de
designadores, os principais estão listados na Tabela 1:
Tabela 1 – Listagem dos designadores em AspectJ.
Designador Características
Call(Signature) Invocação do método / construtor identificado
por assinatura
Execution(Signature) Execução do método / construtor identificado
por assinatura
Get(Signature) Acesso a atributo identificado por assinatura
Set(Signature) Atribuição do atributo identificado por
assinatura
This(Type pattern) Objeto em execução é instância do padrão
tipo
Target(Type pattern) Objeto de destino é instância do padrão tipo
Args(Type pattern) Os argumentos são instância do padrão tipo
Within(Type pattern) O código em execução está definido em
padrão tipo

Em AspectJ elementos wildcards são utilizados, estes permitem que em

especificações de assinatura (signature) sejam definidos o número de caracteres (*) e o
número dos argumentos (..). Por exemplo: public void set*(.., String), isto irá
refletir sobre todos os métodos que iniciam com a palavra set e que tenham zero ou
mais argumentos como parâmetro. E em padrão tipo (type pattern) utilizam-se os
seguintes wildcards:
• * - qualquer seqüência de caracteres não contendo pontos;
• .. – qualquer seqüência de caracteres, inclusive pontos;
• + – qualquer subclasse de uma classe.

9
A.3.3 Adendos (Advices)
Adendos é o código para ser executado em um ponto de junção que está sendo
referenciado pelo conjunto de junção. Existem três maneiras de adendos: antes, durante
e depois (before, around e after). Portanto, de acordo com seus nomes, before executa
antes do ponto de junção, around executa antes e depois e after executa depois.
O adendo pode modificar a execução do código no ponto de junção, pode substituir
ou passar por ele. Usando o adendo pode-se “logar” as mensagens antes de executar o
código de determinados pontos de junção que estão espalhados em diferentes módulos.
O corpo de um adendo é muito semelhante ao de qualquer método, encapsulando a
lógica a ser executada quando um ponto de junção é alcançado [Gradecki and Lesiecki,
2003].

A.3.4 Declarações Inter-tipos (Inter-type Declarations)

O AspectJ provê uma maneira de alterar a estrutura estática de uma aplicação, isto
ocorre por meio das declarações inter-tipos que são descritas como interesses estáticos
(static crosscutting). Estas declarações provêm uma construção chamada Introduction.
Introduction é um interesse estático que introduz alterações nas classes, interfaces e
aspectos do sistema. Alterações estáticas em módulos não têm efeito direto no
comportamento. Por exemplo, pode ser adicionado um método ou um atributo na classe
[Gradecki and Lesiecki, 2003].

A.3.5 Aspectos (Aspects)

Da mesma maneira que a classe é a unidade central em Java, aspecto é a unidade central
do AspectJ. Aspectos encapsulam conjuntos de junção (point cuts), adendos (advices) e
declarações inter-tipos (inter-type declarations) em uma unidade modular de
implementação. Assim como as classes em Java, os aspectos podem conter atributos,
métodos e classes internas.
Aspectos podem alterar a estrutura estática de um sistema adicionando membros
(atributos, métodos e construtores) a uma classe, alterando a hierarquia do sistema, e
convertendo uma exceção checada por uma não checada (exceção de runtime). Esta
característica de alterar a estrutura estática de um programa é chamada static
crosscutting. Além de afetar a estrutura estática, um aspecto também pode afetar a
estrutura dinâmica de um programa. Isto é possível através da interceptação pontos de

10
junção, e da adição de comportamento antes ou depois dos mesmos, ou ainda através da
obtenção de total controle sobre o ponto de execução [Soares and Borba, 2002].

A.3.6 Exemplo
Para exemplificação do uso de aspectos utilizaremos um exemplo didático
apresentado em [Elrad et al., 2001]. Este exemplo é um sistema simples de elementos
gráficos. Como pode ser observado na Figura 7 é formado pelas classes Ponto, Linha e
Tela, além de ElementoDeFigura e Figura.

Figura 7 – Diagrama de classes do editor de figuras.

Relembrando os conceitos básicos vistos nos tópicos anteriores em AspectJ, têm-se:

• Pontos de junção (joint points) – pontos na execução de programas Java;
• Conjuntos de junção (pointcuts) – especificação de pontos de junção;
• Adendo (advice) – especificação de comportamento que afeta o programa em
seus pontos de junção;
• Declarações inter-tipo (inter-type declarations) – declarações de membros e
relações entre classes que afetam a estrutura e hierarquia de classes do
programa;
• Aspectos (aspects) – unidade que modulariza um interesse transversal,
contendo declarações inter-tipo, adendos, conjuntos de junção, atributos,
métodos e construtores.
Na Figura 8, são apresentadas as implementações em Java das classes Ponto e
Linha sem o uso de POA. Observa-se que após a chamada dos métodos setX e setY da

11
classe Ponto e dos métodos setP1 e setP2 da classe Linha se faz necessário a
invocação do método atualiza da classe Tela.

Figura 8 – Implementação em Java de editor de figuras.

Desta forma, a invocação do método atualiza fica espalhada pelos quatro métodos.
Portanto, visando a moduralização desse interesse deve-se fazer uso de AspectJ, ficando
este interesse localizado no aspecto AtualizaTela. Para isso, deve-se seguir os
seguintes passos:
1. Identificar os pontos de junção. Um ponto de junção é um ponto bem
definido no fluxo de execução de um programa. No caso do AspectJ, este tem
suporte a um modelo de pontos de junção dinâmico, ou seja, que ocorrem
durante a execução de programa Java. Considerando o editor de figuras
apresentado na Figura 9 a identificação dos pontos de junção no caso de
mover uma linha.

Figura 9 – Pontos de junção no fluxo de execução do editor de figuras.

12
2. Especificar os pontos de junção, através de conjuntos de junção. Por
exemplo, o conjunto de junção especificado na Figura 10 identifica chamadas
de métodos que movem figuras.

Figura 10 – Conjunto de junção que identifica chamadas de métodos que movem figuras.

3. Especificar as ações a serem combinadas (advice). Adendos definem

códigos que serão executados nos pontos de junção, podendo ser:
− before advice – executado quando um ponto de junção é
alcançado e antes que a computação prossiga.
− after advice – executado depois que a computação realizada no
ponto de junção se encerra.
− around advice – executado quando se chega no ponto de junção;
pode possuir (ou não) controle explícito sobre a execução da
computação originalmente associada ao ponto de junção.
Como exemplo, é apresentada na Figura 11 a definição do AtualizaDaTela.

Figura 11 – Exemplo de um conjunto de junção para o editor de figura.

4. Definir o aspecto (aspect). Como conclusão da seqüência dos passos

anteriores tem-se então o último passo que é a definição do aspecto
AtualizaDisplay, sendo a modularização do interesse transversal de
AspectJ, podendo conter declarações de pontos de junção, adendos,
declarações inter-tipo (introductions), membros (atributos e métodos) locais e
uma hierarquia de aspectos. No caso do editor de figuras temos então a
seguinte implementação do editor de figuras utilizando aspectos na Figura 12.

13
 Figura 12 – Implementação do editor de figuras com AspectJ.

A.4 Conclusão
A Programação Orientada a Aspectos trás vários benefícios na resolução de muitos
problemas encontrados atualmente. Possibilita a construção de programas mais
modulares, com a separação dos interesses transversais, evitando assim o
entrelaçamento e espalhamento do comportamento no código. Além disso, permite a

14
possibilidade de reutilização de grande parte dos módulos desenvolvidos. Desta forma,
obtêm-se ganhos com a manutenção e evolução do software.
A linguagem AspectJ é uma extensão orientada a aspectos da linguagem Java, sendo
uma abordagem clara e composta por construções simples e eficazes, capazes de
modularizar interesses que anteriormente ficavam espalhados pelo código dificultando o
entendimento do sistema.

15
Referências

[Beck, 2000] Beck, K. eXtreme Programming explained. Addison-Wesley, USA, 2000.

[Brown et al., 1998] Brown, W. H.; Malveau, R. C.; McCormickIII, H. W.; Mowbray, T.
J. AntiPatterns: Refactoring Software, Architectures and Projects in Crisis. Wiley
Computer Publishing, John Wiley & Sins, Inc., 1998.
[Deng et al., 2002] Deng, X., Dwyer, M. B., Hatcliff, J., Mizuno, M. Invariant-based
specification, synthesis, and verification of synchronization in concurrent programs,
ICSE’02: Proceedings of the 24th International Conference on Software Engineering,
ACM Press, pp. 442-452, Orlando, Florida, USA, 2002.
[Dijkstra, 1969] Dijkstra, Edsger W. Notes on Structured Programming. In Structured
Programming, Academic Press, London, U.K, 1969.
[Dijkstra, 1976] Dijkstra, Edsger W. A Discipline of Programming. Prentice Hall, 1976.
[Elrad et al., 2001] Elrad, T.; Kiczales, G.; Aksit, M.; Lieberher, k.; Ossher, H.
Discussing Aspects of AOP. Communications of the ACM, v. 44, n. 10, p. 33-38, 2001.
[Fowler et al., 1999] Fowler, Martin; Beck, Kent; Brant, John; Opdyke, William;
Roberts, Don. Refactoring: Improving the Design of Existing Code. Addison-Wesley,
June 1999.
[Gurp and Bosch, 2002] Gurp, J. van; Bosch, J. Design Erosion: Problems & Causes.
Journal of Systems & Software, 61(2), pp. 105-119, Elsevier, March 2002.
[Gurp et al., 2003] Gurp, J. van; Bosch, J; Brinkkemper, S. Design Erosion in Evolving
Software Products. In: International workshop on the Evolution of Large-scale
Industrial Software Applications, ICSM 2003.
[Gurp et al., 2005] Gurp, J. van; Brinkkemper, S.; Bosch, J. Design preservation over
subsequent releases of a software product: a case study of Baan ERP. Journal of
Software Maintenance And Evolution: Research And Practice, Vol. 17, pp. 277–306,
2005.
[Gradeck and Lesiecki, 2003] Gradeck, Joe; Lesiecki, Nicolas. Mastering AspectJ:
aspect-oriented programming in Java. Indianopolis, Indiana. Wiley, 2003.
[Katoen, 1999] Katoen, J. P. Concepts, algorithms, and tools for models checking. Book
to appear, based on the lecture notes of the course “Mechanised Validation of Paralled
Systems” (course number 10359) at the Friedrich-Alexander Universität Erlangen-
Nürnberg.
[Kiczales et al., 1997] Kiczales, G; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.
V.; Loingtier, J.; Irwin, J. Aspect-Oriented Programming, Proceedings of the European
Conference on Object-Oriented Programming (ECOOP), Finland, Springer-Verlag
LNCS 1241, June 1997.
[Kiczales et al., 2001] Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J.;
Griswold, W.G. An overview of AspectJ, In Knudsen, J. L., editor, proceedings of the
European Conference on Object-Oriented Programming (ECOOP), Berlin, pg 327-353,
Springer-Verlag, 2001.

16
[Kiselev, 2002] Kiselev, I. Aspect-Oriented Programming with AspectJ, Ed. Sams
Publishing, 2002.
[Laddad, 2003] Laddad, R. AspectJ in Action: Practical Aspect-Oriented Programming,
Manning, Greenwich, 2003.
[Lehman, 1998] Lehman, M. m. Software's Future: Managing Evolution, IEEE
Software, v.15, n. 1, 40-44, Jan. 1998.
[Lieberherr et al., 1994] Lieberherr, K. J.; Silva-Lepe, I.; Xiao, C. Adaptive Object-
Oriented Programming Using Graph-Based Customization, Communications of the
ACM, 37(5): 94-101, 1994.
[McGregor and Sykes, 2001] McGregor, J. D.; Sykes, D. A. A practical guide to testing
object-oriented software, Addison-Wesley, 2001.
[Monteiro and Piveta, 2003] Monteiro, Elaine S.; Piveta, Eduardo K. Programação
Orientada a Aspectos em AspectJ, Anais do V Encontro dos Estudantes de Informática
do Tocantins, Palmas, TO, pp. 313-322, October, 2003.
[Ossher and Tarr, 1999] Ossher, H. and Tarr, P. Using subject-oriented programming to
overcome common problems in object-oriented software development/evolution, In
International Conference on Software Engineering, ICSE’99, p. 688 - 698, ACM, 1999.
[Royce, 1970] Royce, W.W. Managing the development of large software systems, In:
Proceedings of IEEE WESCON, p. 1-9, 1970.
[Schwaber et al., 2002] Schwaber, K. and Beedle, M., Agile Software Development with
Scrum, NJ, Prentice-Hall, 2002.
[Soares and Borba, 2002] Soares, S.; Borba, P. AspectJ - Programação orientada a
aspectos em Java, In: VI Simpósio Brasileiro de Linguagens de Programação, Rio de
Janeiro, 2002.
[Tretmans, 1999] Tretmans, J. Testing concurrent systems: A formal approach, In
CONCUR’99 – 10th International Conference on Concurrency Theory, volume 1664 of
Lecture Notes in Computer Science, pages 46-65, 1999.

17