Jornada de Atualizac ao em Inform atica JAI 2004

Desenvolvimento de Software Orientado por Aspectos

Fabio Tirelo
1
, Roberto da Silva Bigonha
2
,
Mariza Andrade da Silva Bigonha
2
, Marco T ulio de Oliveira Valente
1
1
Departamento de Ci encia da Computac ao
Pontifcia Universidade Cat olica de Minas Gerais
Av. D. Jos e Gaspar, 500 Pr edio 34 30.535-610 Belo Horizonte, MG
2
Departamento de Ci encia da Computac ao
Universidade Federal de Minas Gerais
Av. Ant onio Carlos, 6627 31.270-000 Belo Horizonte, MG
{ftirelo,mtov}@pucminas.br, {bigonha,mariza}@dcc.ufmg.br
Resumo. O desenvolvimento de software orientado por aspectos e uma t ecni-
ca nova cujo objetivo e permitir a denic ao separada de requisitos transver-
sais ` as classes de um sistema orientado por objetos. Por atravessarem todo o
c odigo, tais requisitos s ao, em geral, de difcil modularizac ao em linguagens
orientadas por objetos puras. Com a orientac ao por aspectos, requisitos trans-
versais, tais como gerac ao de registros de operac oes, controle sincronizac ao e
comunicac ao, podem ser implementados de maneira elegante, eciente e modu-
lar, aumentando o nvel de reutilizac ao de c odigo em sistemas.
Abstract. Aspect-oriented software development is a new technique whose ob-
jective is to modularize crosscutting concerns in object-oriented systems. Modu-
larizing such concerns in pure object-oriented languages is difcult since their
implementation can be scattered throughout many program classes. By using
aspect-oriented programming, one can implement crosscutting concerns such
as logging generation, synchronization and communication control in an ele-
gant, efcient, and modular manner, which may improve system reusability.
Conte udo
1 Introduc ao 3
2 Implementac ao de Requisitos de Sistemas 4
2.1 Introduc ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Programac ao Orientada por Aspectos . . . . . . . . . . . . . . . . . . . 4
2.3 Exemplo I: Gerac ao de Registro de Operac oes . . . . . . . . . . . . . . . 6
2.4 Exemplo II: Padr ao Observador . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Desenvolvimento de Software Orientado por Aspectos 10
3.1 Introduc ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Metodologia de Orientac ao por Aspectos . . . . . . . . . . . . . . . . . . 10
3.3 Recursos da Programac ao Orientada por Aspectos . . . . . . . . . . . . . 10
3.4 Modelagem de Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 A Linguagem de Programac ao AspectJ 15
4.1 Introduc ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 A Linguagem AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Pontos de Junc ao . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Conjuntos de Junc ao . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3 Outros Recursos Para Transversalidade Din amica . . . . . . . . . 17
4.2.4 Reex ao Computacional . . . . . . . . . . . . . . . . . . . . . . 20
4.2.5 Regras de Junc ao . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.6 Aspectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Transversalidade Est atica . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Exemplos de Aplicac oes de Orientac ao por Aspectos 28
5.1 Introduc ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Gerac ao de Registros de Operac oes . . . . . . . . . . . . . . . . . . . . 28
5.3 Padr ao Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Padr ao Observador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Padr ao Wormhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6 Conclus oes 39
2
1. Introduc ao
A Programac ao Orientada por Aspectos (AOP), proposta por Gregor Kiczales em 1997
[23] tem por objetivo modularizar decis oes de projeto que n ao podem ser adequadamente
denidas por meio da programac ao orientada por objetos (POO). Isto se deve ao fato de
que alguns requisitos violam a modularizac ao natural do restante da implementac ao [22].
Na Programac ao Orientada por Aspectos, requisitos de sistemas s ao modelados
por meio de classes, que implementam os objetos do mundo real, e aspectos, que imple-
mentam requisitos transversais do sistema, tais como gerac ao de registro de operac oes,
tratamento de erros, seguranca e comunicac ao.
Na denic ao de classes, o uso de heranca permite a criac ao de relac oes do tipo e-
um e o uso de composic ao permite a criac ao de relac oes do tipo e-parte-de. Por exemplo,
um objeto da classe Carro de um sistema e-um objeto da classe Veculo, se for denida
uma hierarquia de classes em que a classe Carro e subclasse de Veculo. Neste mesmo
sistema, um objeto Roda e-parte-de um objeto Carro se for considerada a composic ao das
classes Carro e Roda. No entanto, certos elementos de projeto, tais como Aerodin amica
ou Conforto, n ao s ao denidos adequadamente com heranca ou composic ao, pois estes
requisitos atravessam as decis oes de implementac ao de diversos itens do carro. Tais re-
quisitos s ao implementados na AOP por meio de aspectos.
Algumas linguagens permitem a implementac ao de programas orientados por as-
pectos, dentre elas, destacam-se as implementac oes para as linguagens: Java, representada
por AspectJ [22] e HyperJ [32, 33]; C++, com a implementac ao de AspectC++ [41]; C,
com a implementac ao de AspectC [11]. Existem tamb em propostas para a AOP indepen-
dente de linguagem [25].
Para a modelagem de sistemas, h a estudos de adaptac oes da Linguagem Uni-
cada de Modelagem (UML) [37, 38] para o projeto de sistemas orientados por aspectos
[7, 8, 42]. Padr oes de composic ao [6, 39] podem ser destacados como metodologias de
projeto para a separac ao de requisitos transversais. A orientac ao por aspectos pode auxi-
liar tamb em na reestruturac ao (refactoring) de c odigo [17, 18], tornando-o mais legvel e
reutiliz avel.
Os mecanismos de AOP s ao tamb em poderosas ferramentas de instrumentac ao de
c odigo, permitindo inclusive alterar a estrutura interna das classes, como na implementa-
c ao de padr oes de projetos [15, 19].
Dentre as aplicac oes de desenvolvimento de software orientado por aspectos, des-
tacam-se a reestruturac ao do n ucleo do sistema operacional FreeBSD [9, 10, 11], a im-
plementac ao de sistemas distribudos [35, 40], a implementac ao de frameworks [12] e
implementac ao de persist encia como requisito transversal [36, 40].
Este minicurso tem por objetivos: apresentar os princpios e as t ecnicas do de-
senvolvimento de software orientado por aspectos; mostrar a aplicac ao de seus conceitos
na linguagem AspectJ; realizar um estudo comparativo entre o desenvolvimento orientado
por aspectos e o desenvolvimento puramente orientado por objetos; exibir estudos de caso
que mostrem a aplicabilidade da orientac ao por aspectos.
Sec ao 2 deste texto dene requisitos transversais e justica, por meio do levanta-
mento das limitac oes da POO, a necessidade de se criar construc oes pr oprias para a sua
modularizac ao. Sec ao 3 enfoca os elementos metodol ogicos do desenvolvimento orien-
tado por aspectos. Sec ao 4 tem por objetivo apresentar a linguagem AspectJ. Sec ao 5
cont em exemplos de implementac oes utilizando orientac ao por aspectos. Sec ao 6 apre-
senta as conclus oes do minicurso.
3
2. Implementac ao de Requisitos de Sistemas
2.1. Introduc ao
Um m odulo e um artefato de programac ao que pode ser desenvolvido e compilado se-
paradamente de outras partes que comp oem o programa [34, 13, 44]. Na programac ao
estruturada, a modularizac ao se limita ` a implementac ao de abstrac oes dos comandos (pro-
cedimentos) necess arios ` a realizac ao de uma tarefa. Com o advento da orientac ao por ob-
jetos [30], pode-se obter um grau mais elevado de modularizac ao, por ser possvel realizar
abstrac oes de estruturas de dados, tipos e de suas operac oes por meio da implementac ao
de interfaces. Al em disso, com o polimorsmo, e possvel denir comportamentos distin-
tos para interface comuns a objetos relacionados, sem a necessidade de acessar elementos
b asicos da implementac ao.
Desenvolvedores criam sistemas a partir de requisitos que podem ser classica-
dos como requisitos funcionais, que constituem o objetivo nal do sistema, e requisitos
n ao-funcionais, que compreendem elementos especcos de projeto, muitas vezes sem
relac ao direta com o problema em quest ao. Por exemplo, em um sistema de processa-
mento de cart oes de cr edito, um exemplo de requisito funcional e o processamento de
pagamentos, ao passo que gerac ao de registro de operac oes (logging), garantia de inte-
gridade de transac oes, autenticac ao de servicos, seguranca e desempenho s ao requisitos
n ao-funcionais.
Por facilitar a express ao dos objetos do problema em soluc ao, a orientac ao por ob-
jetos permite a boa modularizac ao dos requisitos funcionais do sistema [30]. Entretanto,
um problema que este modelo n ao e capaz de resolver adequadamente est a relacionado ` a
modularizac ao de requisitos n ao mape aveis diretamente em uma ou poucas classes de um
sistema, pois estes tendem a se espalhar por todo o c odigo do programa [21, 23]. Estes
requisitos s ao denominados requisitos transversais.
2.2. Programac ao Orientada por Aspectos
A Programac ao Orientada por Aspectos (AOP) [23] foi desenvolvida a partir da constata-
c ao de que certos requisitos n ao se encaixam em um unico m odulo de programa, ou pelo
menos em um conjunto de m odulos altamente relacionados. Em sistemas orientados por
objetos, a unidade de modularizac ao e a classe, e os requisitos transversais se espalham
por m ultiplas classes. Estes requisitos s ao tamb em denominados aspectos. Ainda nesse
trabalho, defende-se a tese de que tais requisitos s ao difceis de modularizar por serem
transversais aos requisitos funcionais do sistema.
A falta de tratamento adequado aos requisitos transversais pode resultar no baixo
grau de modularizac ao do sistema. Por estar espalhado em diversos m odulos do sistema,
torna-se difcil conceber, implementar e modicar c odigo relacionado ` a implementac ao
de um requisito transversal.
Figura 1 ilustra a relac ao entre alguns dos requisitos de um carro. Nesta repre-
sentac ao, percebe-se que os componentes de um carro formam uma dimens ao e cada
requisito transversal forma uma dimens ao distinta, cuja evoluc ao deve ser independente
das demais. Entretanto, em linguagens orientadas por objetos, a implementac ao destes
elementos, naturalmente multidimensionais, deve ser feita em uma unica dimens ao: a
dimens ao de implementac ao dos requisitos funcionais. Em outras palavras, o espaco de
requisitos, que e multidimensional, deve ser projetado no espaco de implementac ao que e
unidimensional.
Este problema e exemplicado na classe denida a seguir, extrada de [16]:
4
Componentes:
Peas, rodas, pneus, motor,
chassi, etc.
Segurana
Aerodinmica
Figura 1: Espac o multidimensional dos requisitos de um carro
public class SomeBusinessClass extends OtherBusinessClass {
"Dados membros do m odulo"
"Outros dados membros" // stream de logging, ag de consist encia de dados
"M etodos redenidos da superclasse"
public void performSomeOperation(OperationInformation info) {
"Garante autenticidade"
"Garante que info satisfaca contrato"
"Bloqueia o objeto para garantir consist encia caso outras threads o acessem"
"Garante que a cache est a atualizada"
"Faz o logging do incio da operac ao"
"REALIZA A OPERAC

AO OBJETIVO"
"Faz o logging do nal da operac ao"
"Desbloqueia o objeto"
}
"Outras operac oes semelhantes ` a anterior"
public void save(PersistenceStorage ps) { "..." }
public void load(PersistenceStorage ps) { "..." }
}
Neste c odigo, alguns problemas podem ser identicados:
a parte de Outros dados membros n ao pertence ao objetivo principal da classe;
o m etodo performSomeOperation faz mais operac oes do que realizar a operac ao
objetivo: registra e autentica a operac ao, sincroniza threads, valida de contrato e
gerencia cache;
n ao e claro se as operac oes save e load, que realizam a ger encia de persist encia,
s ao m etodos da parte principal da classe.
Outro problema e que a modicac ao em alguns dos requisitos, como por exemplo,
a alterac ao da poltica de registro de operac oes pode originar modicac oes em diversas
partes do programa, o que e uma tarefa desagrad avel e propensa a erros.
O problema da modularizac ao de requisitos transversais pode ser dividido em
espalhamento e intrus ao [23]. O espalhamento (scattering) diz respeito a c odigo para
5
implementac ao de um requisito transversal estar disperso no programa; por exemplo, o
c odigo de gerac ao de registro de operac oes ou o c odigo para vericar coer encia de cache
est a distribudo ao longo de toda a implementac ao. A intrus ao (tangling) diz respeito
` a confus ao gerada por c odigos de mais de um requisito transversal estarem presentes em
uma unica regi ao do programa, como ocorre no m etodo performSomeOperation do exem-
plo anterior, que n ao realiza apenas operac oes relacionadas ao seu objetivo principal, mas
tamb em gerac ao de registro de operac oes, validac ao de contrato e coer encia de cache.
As implicac oes destes problemas s ao diversas. Primeiramente, observa-se que
elas dicultam o rastreamento do programa, pois a implementac ao simult anea de v arios
requisitos em um unico m etodo torna obscura a correspond encia entre os requisitos e suas
implementac oes, resultando em um mapeamento pobre entre os dois.
Al em disso, obt em-se baixa produtividade, pois a implementac ao simult anea de
v arios requisitos em um m odulo pode desviar a atenc ao do desenvolvedor do requisito
principal para os requisitos perif ericos, podendo levar ` a ocorr encia constante de erros.
Outro ponto importante e que este modelo possui baixo grau de re uso, pois, dado que
um unico m odulo implementa v arios requisitos, outros sistemas que precisarem de im-
plementar funcionalidades semelhantes podem n ao ser capazes de utilizar prontamente o
m odulo, diminuindo ainda mais a produtividade do desenvolvedor.
Por estes pontos, pode-se perceber ainda que o c odigo apresenta pouca qualidade
interna, com baixa coes ao modular e alto grau de acoplamento de m odulos [31], uma vez
que a intrus ao pode produzir c odigo com problemas ocultos, pois ao se preocupar com
diversos requisitos ao mesmo tempo, o desenvolvedor pode n ao dar atenc ao suciente a
um ou mais requisitos.
Todos estes problemas levam ` a produc ao de c odigo de difcil evoluc ao ou baixa
extensibilidade [30], visto que modicac oes posteriores no sistema podem ser dicultadas
pela pouca modularizac ao. Por exemplo, modicac oes na poltica de consist encia da
cache ou na poltica de validac ao de contratos pode levar ` a reorganizac ao de diversos
m odulos do sistema.
2.3. Exemplo I: Gerac ao de Registro de Operac oes
Um exemplo de c odigo que se espalha ao longo de todo o programa e a gerac ao de registro
de operac oes. A implementac ao exibida nesta sec ao e utilizada ao longo do texto para
exemplicac ao dos conceitos apresentados.
Para a implementac ao desta funcionalidade, dene-se uma classe Logger, con-
tendo m etodos para escrever na sada padr ao informac oes a respeito da entrada e do
t ermino da execuc ao de um m etodo da classe.
public class Logger {
public static void logEntry(String message) {
System.out.println("Entering " + message);
}
public static void logExit(String message) {
System.out.println("Exiting " + message);
}
}
Os m etodos cujas execuc oes deseja-se acompanhar devem possuir chamadas aos
m etodos desta classe, como mostrado a seguir.
6
<<stereotype>>
6XEMHFW
<<stereotype>>
2EVHUYHU
{ interface}
+update(Subject) { abstract}
<<stereotype>>
&RQFUHWH6XEMHFW
<<stereotype>>
&RQFUHWH2EVHUYHU
+subjectState
notifyObservers() {
for all obs in observers
obs.update();
}
+addObserver(Observer)
+removeObserver(Observer)
+notifyObservers( )
+update(Subject)
+getState()
+setState(State)
observers
subject
Figura 2: Diagrama UML do Padr ao Observador
public class SomeClass {
public void doSomething(int aParameter) {
Logger.logEntry("doSomething(" + aParameter + ")");
// Realiza a operac ao principal do sistema
Logger.logExit("doSomething");
}
}
A gerac ao de registro de operac oes e um exemplo de espalhamento, devido ` as
chamadas dos m etodos da classe Logger por todo o programa, e de intrus ao, visto que as
chamadas de m etodos da classe s ao colocadas no mesmo local de c odigo relacionado aos
objetivos principais dos m odulos.
2.4. Exemplo II: Padr ao Observador
O padr ao de projeto observador tem por objetivo denir uma depend encia de um para
muitos entre objetos, de modo que, quando o estado de um objeto for alterado, todos os
seus dependentes ser ao noticados e atualizados automaticamente [15].
O padr ao observador e utilizado para desacoplar o objeto alvo de observac ao
de seus observadores, permitindo maior grau de re uso. Por exemplo, em bibliotecas
de implementac ao de interfaces gr acas com o usu ario, os objetos alvo de observac ao
s ao as componentes de interface e os observadores s ao respons aveis pela realizac ao das
operac oes de tratamento da manipulac ao da interface pelo usu ario. O padr ao observador
permite, portanto, a separac ao entre dados e apresentac ao.
Figura 2 mostra a estrutura do padr ao observador, utilizando a linguagem UML
[37, 38]. Sua implementac ao consiste geralmente na denic ao da classe Subject, que re-
presenta os elementos alvos de observac ao, e de uma interface Observer, que representa
os observadores de Subject. A classe Subject dene tamb em a interface de anexac ao
(m etodo Subject.addObserver) e remoc ao (m etodo Subject.removeObserver) de obser-
7
vadores e implementa o protocolo de noticac ao dos observadores em caso de alterac ao
no estado interno do objeto alvo (m etodo Subject.notifyObservers).
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
public class Subject {
private List observers = new LinkedList();
public void addObserver(Observer observer) {
observers.add(observer);
}
public void removeObserver(Observer observer) {
observers.remove(observer);
}
public void notifyObservers() {
Iterator it = observers.iterator();
while (it.hasNext())
((Observer) it.next()).update(this);
}
}
A interface Observer dene o protocolo de noticac ao de objetos que observam a
mudanca de estado interno (m etodo Observer.update).
public interface Observer {
public void update(Subject s);
}
Um pequeno exemplo do padr ao observador e a implementac ao de term ometros
para graus Celsius e Fahrenheit, que s ao observadores de uma classe que registra tempe-
ratura. Toda vez que a temperatura e alterada, os observadores s ao noticados e as ac oes
apropriadas s ao tomadas.
A classe Temperature deve ser subclasse de Subject, para possuir os m etodos de
registro e noticac ao de observadores.
public class Temperature extends Subject {
private double value;
public double getValue() {
return value;
}
public void setValue(double value) {
this.value = value;
notifyObservers();
}
}
As classes TermometerCelsius e TermometerFahrenheit s ao observadores de tem-
peratura e, portanto, s ao noticados toda vez que uma alterac ao da temperatura e reali-
zada.
8
public class TermometerCelsius implements Observer {
public void update(Subject s) {
double value = ((Temperature) s).getValue();
System.out.println("Celsius: " + value);
}
}
public class TermometerFahrenheit implements Observer {
public void update(Subject s) {
double value = 1.8 * ((Temperature) s).getValue() + 32;
System.out.println("Fahrenheit: " + value);
}
}
A implementac ao do padr ao observador e um exemplo de intrus ao, visto que
c odigo especco do padr ao ca misturado com o c odigo da funcionalidade principal
do sistema. Por exemplo, e necess ario indicar que a classe Temperature e uma subclasse
de Subject, o que n ao est a de acordo com os objetivos do programa, mas sim com a
implementac ao do requisito transversal.
Conforme identicado em [19], a implementac ao direta de padr oes de projeto
pode produzir diversos efeitos colaterais n ao desejados. Um dos principais efeitos rela-
tados e o fato de o padr ao desaparecer no c odigo, perdendo assim a sua modularidade.
Al em disso, adicionar ou remover um padr ao no sistema e geralmente uma substituic ao
invasiva e de difcil retrocesso. Assim, enquanto a especicac ao do padr ao e reus avel, a
sua implementac ao em geral n ao pode ser totalmente modularizada.
2.5. Conclus ao
Nesta sec ao foram relatados alguns problemas encontrados no desenvolvimento de sis-
temas orientados por objetos. Dentre os mais importantes, pode-se citar a intrus ao e o
espalhamento de c odigo gerados na implementac ao de requisitos transversais.
A exist encia de c odigo de mais de um requisito em um mesmo m odulo pode gerar
alto acoplamento quando e necess ario denir interfaces complexas para m odulos. Al em
disso, a implementac ao de mais de um requisito em um mesmo m odulo pode implicar no
desenvolvimento de m odulos com baixa coes ao interna. Estes problemas geram c odigos
com baixo grau de re uso e alto custo para extens ao.
9
3. Desenvolvimento de Software Orientado por Aspectos
3.1. Introduc ao
Nesta sec ao, mostra-se como a separac ao de requisitos transversais proposta na orientac ao
por aspectos pode ser aplicada nas fases de desenvolvimento de sistemas. Inicialmente,
s ao mostrados os passos de desenvolvimento de programas orientados por aspectos. Em
seguida, mostram-se os elementos da programac ao orientada por aspectos. No nal, e
feita uma breve descric ao sobre a modelagem de aspectos por meio da UML.
3.2. Metodologia de Orientac ao por Aspectos
Segundo [16], o desenvolvimento de software orientado por aspectos e realizado em tr es
fases: a decomposic ao, a implementac ao e a recomposic ao de requisitos.
A decomposic ao de requisitos consiste na seperac ao dos requisitos em funcio-
nais e transversais. No exemplo da classe SomeBusinessClass da Sec ao 2.2, pode-se
identicar os seguintes requisitos: operac ao objetivo, autenticac ao e registro de operac ao,
sincronizac ao de threads, validac ao de contrato, coer encia de cache e persist encia. A
operac ao objetivo deve ser implementada na classe, por representar um de seus requisi-
tos funcionais. Todos os demais requisitos s ao transversais para este m odulo, devendo,
portanto, ser implementados em outros m odulos.
Em [5], os requisitos transversais s ao classicados em requisitos de infra-estru-
tura, de servicos e de paradigmas. Requisitos de infra-estrutura consistem em requisitos
respons aveis por coordenac ao (escalonamento e sincronizac ao), distribuic ao (toler ancia a
falhas, comunicac ao, serializac ao e replicac ao) e persist encia. Os requisitos de servicos
s ao representados pelos requisitos de seguranca, recuperac ao de erros, operac oes de retro-
cesso (undo), rastreamento e registro de operac oes. Exemplos de requisitos de paradigma
s ao os padr oes visitor e observer [15].
Ap os a decomposic ao, realiza-se a implementac ao independente dos requisitos.
No exemplo da Sec ao 2.2, deve-se implementar as unidades de l ogica do neg ocio, registro
de operac oes, autorizac ao, etc., em m odulos separados. Para a implementac ao de cada
m odulo, utiliza-se os recursos da POO padr ao. Por exemplo, a gerac ao de registro de
operac oes pode ser feita por meio da implementac ao de classes e interfaces especcas
para o problema, possivelmente organizadas por meio de padr ao de projetos.

E possvel,
ainda, utilizar bibliotecas externas, tal como Log4J [27].
Ap os a implementac ao separada de cada requisito, especicam-se as regras de
recomposic ao do sistema. Estas regras s ao implementadas em m odulos denominados as-
pectos. Os aspectos denem como os requisitos s ao compostos para formar o sistema,
em um processo denominado costura (weaving). Ainda no exemplo da Sec ao 2.2, um as-
pecto pode conter regras que denem os pontos do programa onde chamadas de m etodos
de registro de operac oes devem ser inseridas.
3.3. Recursos da Programac ao Orientada por Aspectos
Na programac ao orientada por aspectos, denem-se pontos de junc ao (joinpoints) como
sendo pontos da execuc ao do programa. Exemplos de pontos de junc ao s ao as chamadas
de m etodos de uma classe. Associados aos pontos de junc ao mais dois conceitos s ao
importantes: conjuntos de junc ao e regras de junc ao.
As construc oes do programa que cont em pontos de junc ao s ao denominadas con-
juntos de junc ao (pointcuts) e t em a func ao de reunir informac oes a respeito do contexto
destes pontos. Os c odigos relativos aos requisitos transversais que devem ser executados
em pontos de junc ao s ao denominados regras de junc ao (advices).
10
Linguagens orientadas por aspectos devem possuir como elementos b asicos: um
modelo de denic ao de pontos de junc ao, uma forma de identicar pontos de junc ao, isto
e, denir conjuntos de junc ao, e uma forma de interferir na execuc ao de pontos de junc ao.
Estes elementos s ao encapsulados em m odulos denominados aspectos, que podem ser
denidos como unidades de implementac ao modular de requisitos transversais e cont em
denic oes de conjuntos e regras de junc ao.
Considere, por exemplo, a seguinte denic ao em AspectJ do aspecto LoggingAs-
pect, contida no arquivo LoggingAspect.java:
public aspect LoggingAspect {
pointcut publicMethods(): execution(public * *(..));
pointcut logObjectCalls() : execution(* Logger.*(..));
pointcut loggableCalls() : publicMethods() && ! logObjectCalls();
before(): loggableCalls() {
Logger.logEntry(thisJoinPoint.getSignature().toString());
}
after(): loggableCalls() {
Logger.logExit(thisJoinPoint.getSignature().toString());
}
}
O aspecto LoggingAspect dene os seguintes conjuntos de junc ao:
publicMethods: engloba os pontos de junc ao de execuc ao dos m etodos p ublicos
do programa;
logObjectCalls: engloba os pontos de junc ao de execuc ao dos m etodos da classe
Logger;
loggableCalls: engloba os pontos de junc ao de execuc ao dos m etodos p ublicos do
programa que n ao pertencam ` a classe Logger.
S ao tamb em denidas as regras de junc ao before e after, contendo os c odigos para se-
rem executados antes e depois das execuc oes dos m etodos identicados nos conjuntos de
junc ao indicados. Na regra before, dene-se o c odigo a ser executado antes da execuc ao
dos m etodos p ublicos, que corresponde ` a gerac ao do registro de entrada no m etodo; este
c odigo corresponde ` a chamada do m etodo doEntry da classe Logger, passando-lhe a as-
sinatura do ponto de junc ao
1
. Da mesma forma, na regra after, dene-se o c odigo a ser
executado ap os a execuc ao dos m etodos p ublicos, que corresponde ` a gerac ao do registro
de sada do m etodo.
O compilador de aspectos e denominado weaver e sua func ao e realizar o processo
de costura de c odigo (weaving), entrelacando os c odigos das regras de junc ao com os
c odigos dos pontos de junc ao especicados nos aspectos. O processo de costura consiste
na instrumentac ao do c odigo das classes para executar o c odigo denido nos aspectos.
1
A express ao thisJoinPoint.getSignature().toString() obt em uma cadeia de caracteres que corresponde ` a assi-
natura do m etodo que cont em o ponto de junc ao ao qual a regra se aplica (thisJoinPoint)
11
2EMHFW
<<aspect>>
/RJJLQJ$VSHFW
/RJJHU
<<crosscuts>>
logEntry(String signature)
logExit(String signature)
<<crosscuts>>
Figura 3: Diagrama UML para a gerac ao de registro de operac oes por meio de
aspectos
3.4. Modelagem de Aspectos
Para a modelagem de sistemas, h a estudos de adaptac oes da UML [37, 38] para o projeto
de sistemas orientados por aspectos [7, 8, 42]. Destes, o estudo de padr oes de composic ao
[6, 39] pode ser destacado como uma metodologia de projeto para a separac ao de requi-
sitos transversais. Um aspecto pode ser representado no diagrama de classes da UML
de maneira semelhante a uma classe. Utiliza-se o designador <<aspect>> para deno-
tar um aspecto. Al em disso, no relacionamento de entidades, utiliza-se o designador
<<crosscuts>> para indicar que um aspecto e transversal a uma classe.
Por exemplo, Figura 3 mostra o diagrama de classes para o problema de gerac ao
de registros de operac oes. Nele, dene-se que o aspecto de gerac ao de registros (Loggin-
gAspect) implementa a transversalidade entre a classe Logger, respons avel pela gerac ao
dos registros, e ao estere otipo de classe BusinessClass.
Figura 4 apresenta o diagrama de classes para o padr ao observador, utilizando as-
pectos. O modelo indica um aspecto abstrato que e transversal ` as interfaces Subject e
Observer, que representam um alvo de observac ao e seu observador, respectivamente.
Este aspecto dene m etodos para adicionar e remover um observador de um alvo de
observac ao (addObserver e removeObserver). Al em disso, dene tamb em um m etodo
abstrato updateObservers, que e chamado quando o estado de um alvo de observac ao for
alterado. O conjunto de junc ao abstrato subjectChange (ver Sec ao 4) designa os pontos
do programa que representam alterac oes no estado interno do alvo. Para tornar os ob-
jetos de uma classe do sistema ConcreteSubject observada por objetos de outra classe
ConcreteObserver, cria-se um aspecto ConcreteObserverProtocol que estende Observer-
Protocol.
Este aspecto e transversal ` as classes da aplicac ao e dene os pontos do programa
que representam alterac oes no estado interno do objeto alvo e a ac ao a ser realizada para
atualizar os observadores. Al em disso, este aspecto dene ainda que as classes Concre-
teObserver e ConcreteSubject implementam as interfaces Observer e Subject respecti-
vamente. Observe que as classes alvo e observadora est ao completamente disassociadas,
sendo que o acoplamento entre elas est a somente no aspecto.
12
6XEMHFW
{ interface}
$SSOLFDWLRQ6XEMHFW
+subjectState
+getState()
+setState(State)
<<abstract aspect>>
2EVHUYHU3URWRFRO
2EVHUYHU
{ interface} <<aspect>>
$SSOLFDWLRQ2EVHUYHU3URWRFRO
$SSOLFDWLRQ2EVHUYHU
observerAction()
updateObserver(Subject,Observer)
subjectChange(Subject)
<<crosscuts>>
<<crosscuts>>
addObserver(Subject,Observer)
removeObserver(Subject,Observer)
updateObserver(Subject,Observer) { abstract}
subjectChange(Subject) { abstract pointcut} <<crosscuts>>
<<crosscuts>>
Figura 4: Diagrama de classes para o padr ao observador utilizando aspectos
S : ConcreteSubject
<<aspect>>
ApplicationObserverProtocol O : ConcreteObserver : Application
<<instatiates>>
<<instatiates>>
addObserver(S,O)
setState()
<<after advice>>
observerAction()
updateObserver(S,O)
Figura 5: Diagramas de seq u encia para a noticac ao de observadores.
13
Al em do diagrama de classes, o diagrama de seq u encias da UML pode ser utili-
zado para modelar a relac ao temporal entre as classes e os aspectos de um sistema. Por
exemplo, Figura 5 mostra o diagramas de seq u encias para a instanciac ao de alvo e ob-
servador, anexac ao de observador e alterac ao do estado do alvo de observac ao durante
a execuc ao de um programa. Assim como no diagrama de classes, pode-se observar no
diagrama de seq u encias que o objeto alvo de observac ao e o objeto observador s ao de-
sacoplados, visto que toda interac ao e feita por meio do aspecto, de modo que n ao h a
chamadas diretas de m etodos de um a partir de outro.
3.5. Conclus ao
O desenvolvimento de sistemas orientado por aspectos possui semelhancas com o desen-
volvimento de sistemas orientados por objetos. A proposta metodol ogica consiste em
denir e implementar os requisitos do sistema por meio de orientac ao por objetos e, em
seguida, denir regras de costura que facam o entrelacamento dos requisitos em diferentes
m odulos.
Para modelagem de aspectos, pode-se utilizar a pr opria linguagem UML, com
alguns estere otipos apropriados para os novos elementos introduzidos pela metodolo-
gia. Dentre os diagramas da UML, os mais utilizados s ao os diagramas de classes, de
seq u encia e de colaborac ao. Como poucos conceitos s ao introduzidos nestes diagra-
mas, conclui-se que a orientac ao por aspectos, no nvel de projeto do sistema, e bastante
acessvel aos desenvolvedores de sistemas de software.
14
4. A Linguagem de Programac ao AspectJ
4.1. Introduc ao
Nesta sec ao, e apresentada a linguagem AspectJ [21, 16, 24, 3], uma das linguagens ori-
entadas por aspectos mais importantes da literatura. Seus aspectos sint aticos e sem anticos
s ao discutidos e, no m da sec ao, apresenta-se um panorama das demais linguagens ori-
entadas por aspectos seguida de um estudo comparativo com AspectJ.
4.2. A Linguagem AspectJ
A linguagem AspectJ [21] e uma extens ao de Java com suporte a dois tipos de implemen-
tac ao de requisitos transversais: a transversalidade din amica, que permite denir imple-
mentac ao adicional em pontos bem denidos do programa, e a transversalidade est atica,
que afeta as assinaturas est aticas das classes e interfaces de um programa Java.
Atualmente, o desenvolvimento do ambiente de execuc ao da linguagem e um pro-
jeto Eclipse [14, 3], cujo website cont em ferramentas para o desenvolvimento de progra-
mas orientados por aspectos.
4.2.1. Pontos de Junc ao
Pontos de junc ao s ao posic oes bem denidas da execuc ao de um programa, como por
exemplo, chamadas de m etodos ou execuc ao de blocos de tratamento de excec oes. Pontos
de junc ao podem tamb em possuir contexto associado. Por exemplo, o contexto de um
ponto de junc ao de chamada de m etodo cont em o objeto alvo da chamada e a lista de
argumentos da chamada do m etodo.
4.2.2. Conjuntos de Junc ao
Um conjunto de junc ao e formado por um conjunto de pontos de junc ao e as informac oes
de contexto destes pontos. Eles permitem a especicac ao de colec oes de pontos de junc ao
e a exposic ao de seus contextos para a implementac ao de regras de junc ao. Conjuntos de
junc ao podem ser vistos como registros de identicac ao de pontos de junc ao em tempo
de execuc ao. Por exemplo, o designador de conjunto de junc ao call(void Point.setX(int))
identica todos os pontos de junc ao formados por chamadas do m etodo de assinatura void
Point.setX(int).
A denic ao de conjuntos de junc ao em AspectJ obedece ` a seguinte sintaxe:
pointcut nome-conjunto(arg1, ..., argn): denic ao;
dene um conjunto de junc ao de nome nome-conjunto com os par ametros arg1, ..., argn
para identicar os pontos de junc ao representados por denic ao.
O ponto de junc ao a seguir dene todas as chamadas do m etodo Point.setX(int),
em que o valor passado como par ametro seja menor que zero:
pointcut conjunto(int x): call(void Point.setX(int) && args(x) && if(x < 0);
A linguagem AspectJ permite a coleta dos seguintes pontos de junc ao: (i) chama-
das de m etodos e construtores; (ii) execuc oes de m etodos e construtores; (iii) acesso a
campos de classes e objetos; (iv) execuc oes de tratadores de excec oes; (v) execuc oes de
inicializac ao de classes.
15
Chamadas de M etodos e Construtores
Os conjuntos de junc ao de chamadas de m etodos e construtores descrevem os
pontos de execuc ao ap os a avaliac ao dos argumentos no ponto de chamada de um m etodo.
Para denir este tipo de conjunto de junc ao, utiliza-se o operador call, parametrizado com
a assinatura do m etodo. Por exemplo, o designador call(void Point.getX(int)) representa
os pontos de junc ao que s ao chamadas do m etodo getX da classe Point sem valor de
retorno e com um par ametro inteiro.
Para identicar chamadas de construtores, utiliza-se a palavra new no lugar do
nome do m etodo e n ao se utiliza o tipo de retorno. Por exemplo, os pontos de junc ao
que s ao chamadas do construtor da classe Point que recebe dois par ametros inteiros s ao
representados pela construc ao call(Point.new(int,int)).
Execuc oes de M etodos e Construtores
Os conjuntos de junc ao de execuc ao de m etodos e construtores capturam as suas
execuc oes. Em contraste com os conjuntos de junc ao de chamada, conjuntos de junc ao
de execuc ao representam o corpo de um m etodo ou construtor.
Para denir este tipo de conjunto de junc ao, utiliza-se o operador execution, para-
metrizado com a assinatura do m etodo. Por exemplo, para representar todas as execuc oes
do m etodo getX da classe Point sem valor de retorno e com um par ametro inteiro, pode-se
utilizar a construc ao execution(void Point.getX(int)).
A denic ao de conjuntos de junc ao de execuc oes de construtores e semelhante ` a
denic ao de chamadas. Por exemplo, a construc ao execution(Point.new(int,int)) designa
os pontos de junc ao de execuc ao do construtor da classe Point que recebe dois par ametros
inteiros.
Os pontos de junc ao de chamada e de execuc ao de m etodos e construtores t em
como diferencas b asicas:
o contexto no qual est ao inseridos: por exemplo, a chamada do m etodo f no corpo
do m etodo g leva como informac ao de contexto para o call os elementos de g, ao
passo que, para execution, leva os elementos de f;
o local onde o c odigo do aspecto e costurado: os c odigos das regras s ao espalhados
no ponto de chamada para conjuntos de junc ao call e no ponto de denic ao do
m etodo para conjuntos de junc ao execution.
Acessos a Campos de Classes e Objetos
Os conjuntos de junc ao referentes a operac oes com campos de classe capturam
acessos de leitura e escrita a atributos est aticos e n ao-est aticos de uma classe. A captura
da leitura de um campo utiliza o operador get e a de escrita, o operador set, ambos
parametrizados com a assinatura do campo. Por exemplo, a construc ao get(PrintWriter
System.out) representa os acessos de leitura do campo out da classe System, ao passo
que set(int MyClass.x) representa as operac oes de escrita ao campo x da classe MyClass.
16
Execuc oes de Tratadores de Excec oes
Os conjuntos de junc ao referentes a tratamento de excec ao capturam a execuc ao
dos blocos catch. Eles podem ser denidos por meio do operador handler, parametrizado
pelo nome da classe de excec ao. Por exemplo, para representar os blocos catch que tratam
a excec ao NumberFormatException, utiliza-se handler(NumberFormatException).
Execuc oes de Inicializac ao de Classes
Os conjuntos de junc ao referentes ` a inicializac ao de classes capturam a execuc ao
do c odigo especicado no bloco static dentro das denic oes de classes. A identicac ao e
feita por meio do operador staticinitialization, parametrizado pelo nome da classe.
4.2.3. Outros Recursos Para Transversalidade Din amica
Combinac oes de Conjuntos de Junc ao
Conjuntos de junc ao podem ser combinados utilizando-se os operadores de inter-
sec ao (&&), uni ao () e complemento (!). Por exemplo, o seguinte designador composto
representa todas as chamadas dos m etodos getX e getY da classe Point:
call(void Point.setX(int)) call(void Point.setY(int))
Smbolos Curinga

E possvel ainda utilizar smbolos curinga (wildcard) para identicar todos os

m etodos que casam com denic oes parciais.
O smbolo .. pode ser utilizado para designar que se devem ser casados os
m etodos com quaisquer n umeros e tipos de argumentos. Por exemplo, a construc ao void
MyClass.myMethod(..) representa todos os m etodos de nome myMethod que pertencam ` a
classe MyClass e que retornem void.
O smbolo * pode ser utilizado para designar:
Qualquer tipo de retorno, como em: * MyClass.myMethod(..)
Qualquer classe, como em: * *.myMethod(..)
Qualquer m etodo, como em: * MyClass.*(..)
Nomes parciais de m etodos, como em: * MyClass.get*(..)
Nomes parciais de campos, como em: * MyClass.id*
Por exemplo, a construc ao
execution(public * *(..)) && !execution(* Logger.*(..))
dene todos os pontos de junc ao de execuc oes de m etodos p ublicos que n ao pertencam ` a
classe Logger.
Utiliza-se o smbolo + para indicar o tipo e suas subclasses. Por exemplo, a
construc ao handler(IOException+) representa os blocos catch que tratam IOException
ou suas subclasses. Outro exemplo, pode-se representar construtores de subclasses por
meio do smbolo + , como em MyClass+.new(..).
17
Os smbolos curinga podemser combinados para formar conjuntos de junc ao com-
plexos, como em call(void Figure+.set*(..)), que descreve todos os pontos de junc ao de
chamadas de m etodos cujos nomes iniciem com set e que pertencam ` a classe Figure ou a
uma de suas subclasses.
Denic oes Baseadas em Modicadores

E possvel ainda denir conjuntos de junc ao baseados em modicadores: public,

private, static, etc. Por exemplo, a construc ao call(public * *(..)) representa todos os
m etodos p ublicos do programa.
Conjuntos de junc ao podem ser denidos tamb em por meio da negac ao de mo-
dicadores, utilizando-se o smbolo ! . Por exemplo, a construc ao call(!static * *(..))
representa todos os m etodos n ao est aticos do programa, ao passo que todos os m etodos
p ublicos n ao-est aticos s ao representados pela construc ao call(public !static * *(..)).
Denic oes Baseadas na Estrutura do Programa
A estrutura do programa pode ser utilizada na denic ao de conjuntos de junc ao.
Em AspectJ, pode-se denir conjuntos de junc ao que ocorram dentro de classes ou dentro
de m etodos.
O operador within, e utilizado para denir pontos de junc ao que ocorrem no es-
copo da classe cujo nome e dado como par ametro. Por exemplo, a construc ao within(Point)
captura todos os pontos de junc ao que ocorrem dentro da classe Point.
O operador withincode permite capturar pontos de junc ao no escopo de m etodos
de classe, passando no lugar de um nome de classe a assinatura de um m etodo. Por exem-
plo, a construc ao withincode(void Device.update()) captura todos os pontos de junc ao
que ocorrerem dentro do m etodo void Device.update().
Denic oes Baseadas no Contexto
Contextos podem ser utilizados na denic ao de conjuntos de junc ao. Em AspectJ,
pode-se denir conjuntos de junc ao nos seguintes elementos de contexto: tipo do objeto
no qual o ponto de junc ao ocorre; tipo do objeto receptor de uma chamada de m etodo;
uxo de controle a que pertence um ponto de junc ao; argumentos de m etodos e constru-
tores.
A construc ao this(algum-tipo) e utilizada para denir pontos de junc ao que ocor-
rem durante a execuc ao de m etodos cujo objeto receptor e do tipo algum-tipo. Por exem-
plo, a construc ao this(Figure) captura todos os pontos de junc ao que ocorrem quando o
objeto corrente (this) for do tipo Figure.
Os contextos this e within representam, respectivamente, os tipos din amico e
est atico de um objeto. Por exemplo, considere que Point seja subclasse de Figure e de-
na um m etodo de assinatura void setX(int). Um ponto de junc ao que ocorre dentro
deste m etodo pode ser identicado por this(Figure), pois o tipo do objeto corrente, Point,
e tamb em da classe Figure. Entretanto, estes mesmos pontos de junc ao n ao podem ser
identicados por within(Figure), se o m etodo n ao estiver denido dentro desta classe.
A construc ao target(algum-tipo) e utilizada para denir pontos de junc ao de cha-
18
2
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
draw()
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
draw()
Figure
moveBy(int, int)
refresh()
Figura 6: Exemplo utilizado na diferenciac ao de operadores de escopo e con-
texto
madas de m etodos em que o tipo do objeto receptor e algum-tipo. Por exemplo, a cons-
truc ao target(Point) captura todos os pontos de junc ao de chamadas de m etodos que t em
Point como tipo dos objetos receptores.
A construc ao args(arg1, ..., argn) e utilizada para denir pontos de junc ao que uti-
lizam os valores dos argumentos de uma chamada de m etodo. Por exemplo, a construc ao
call(void Device.move(Figure,int,int)) && args(Point,int,int) captura todos os pontos de
junc ao de chamada do m etodo Device.move, em que o primeiro par ametro passado seja
uma inst ancia do tipo Point, subclasse de Figure.
Denic oes Baseadas no Fluxo de Execuc ao
A construc ao cow(algum-ponto-de-junc ao) e utilizada para denir pontos de
junc ao que ocorrem no uxo de controle gerado a partir de um ponto de junc ao. Por
exemplo, a construc ao cow(execution(void Device.update())) captura todos os pontos
de junc ao que ocorrem no uxo de controle da execuc ao do m etodo Device.update.
Pode-se utilizar ainda o especicador cowbelow, para designar os pontos de
junc ao que ocorrem no uxo de controle a partir de um ponto de junc ao, excluindo-se o
ponto de junc ao gerador do uxo.
Para diferenciar os especicadores de escopo e contexto, considere as classes de-
nidas na Figura 6. Considere ainda o seguinte trecho de c odigo:
public class ClientClass {
public void someMethod() {
//...
Line L = new Line(new Point(10,6),new Point(30,5));
//...
L.moveBy(10,16);
//...
}
}
Achamada do m etodo Line.moveBy no corpo do m etodo ClientClass.someMethod
pode ser representada pelo conjunto de junc ao within(ClientClass), pois ocorre dentro do
19
corpo de ClientClass. Da mesma forma, este ponto de junc ao pode ser representado por
withincode(void ClientClass.someMethod()), por ocorrer no corpo deste m etodo.
Com relac ao ao contexto, este ponto pode ser identicado tamb em por meio da
construc ao this(ClientClass), pois ocorre durante a execuc ao do m etodo someMethod,
cujo objeto receptor e da classe ClientClass, ou ainda como target(Line), pois o seu objeto
receptor, L, e da classe Line.

E possvel tamb em identic a-lo como target(Figure), pois o
objeto L e tamb em do tipo Figure, superclasse de Line.
Por outro lado, durante a execuc ao do m etodo Line.moveBy, os pontos de junc ao
que ocorrerem durante esta execuc ao podem ser identicados por within(Line) ou ent ao
por withincode(void Line.moveBy). Por em, n ao e possvel identic a-los por meio da
construc ao within(Figure) ou withincode(void Figure.moveBy), pois n ao ocorrem no
corpo da classe Figure. Estes pontos de junc ao podem ser representados tamb em por
meio das construc oes this(Line) ou this(Figure).
A construc ao cow(execution(void ClientClass.someMethod())) pode ser utili-
zada para identicar tamb em todos os pontos de junc ao deste exemplo, pois ocorrem no
uxo de controle de execuc ao do programa gerado a partir da execuc ao do m etodo Client-
Class.someMethod.
Condicionais
A construc ao if(express ao-l ogica) pode ser utilizada para identicar pontos de
junc ao em que a condic ao expressa por uma express ao l ogica seja verdadeira.
Por exemplo, a construc ao call(void Point.setX(int)) && args(x) && if(x < 0) cap-
tura todos os pontos de junc ao de chamada do m etodo Point.setX, em que o valor passado
como par ametro seja menor que zero.
4.2.4. Reex ao Computacional
A linguagem AspectJ suporta uma forma limitada de reex ao, que permite examinar
informac oes nos pontos de execuc ao de algum ponto de junc ao. Cada corpo de regra de
junc ao possui um objeto especial, thisJoinPoint, que cont em informac oes sobre o ponto
de junc ao. Este tipo de reex ao e importante, por exemplo, para denic ao de aspectos de
registro de operac oes e depurac ao.
4.2.5. Regras de Junc ao
Regras de junc ao representam c odigos que devem ser executados em pontos de junc ao.
Em AspectJ, e possvel denir regras que s ao executados antes (before), ap os (after) ou
ao redor de (around) pontos de junc ao.
Uma regra before e executada imediatamente antes da execuc ao do ponto de
junc ao, ao passo que uma regra after e executada imediatamente ap os a execuc ao do
ponto de junc ao.
Por exemplo, considere as seguintes denic oes de conjuntos de junc oes e regras:
pointcut publicMethods(): execution(public * *(..));
pointcut logObjectCalls() : execution(* Logger.*(..));
pointcut loggableCalls() : publicMethods() && ! logObjectCalls();
20
before(): loggableCalls() {
Logger.doEntry(thisJoinPoint.getSignature().toString());
}
after(): loggableCalls() {
Logger.doExit(thisJoinPoint.getSignature().toString());
}
O conjunto de junc ao loggableCalls representa todos os pontos de junc ao de exe-
cuc oes de m etodos p ublicos que n ao pertencem ` a classe Logger. A regra before indica
que, antes de um ponto de junc ao pertencente ao conjunto loggableCalls, deve-se emitir
uma mensagem indicando que o m etodo est a iniciando sua execuc ao; isto e feito por meio
do m etodo Logger.doEntry. Da mesma forma, a regra after indica que, ap os a execuc ao de
um ponto de junc ao pertencente ao conjunto loggableCalls, deve-se emitir uma mensagem
indicando que o m etodo est a terminando sua execuc ao; isto e feito por meio do m etodo
Logger.doExit. Observe que o objeto thisJoinPoint e utilizado para obter a assinatura do
m etodo.

E possvel, ainda, denir regras after para serem executadas ap os o retorno normal
de um m etodo, utilizando-se para isso a construc ao after returning. Para denir regras a
serem executadas em caso de retorno com lancamento de excec ao, utiliza-se a construc ao
after throwing.
Por exemplo, a regra after do programa anterior pode ser reescrita como:
after() returning (): loggableCalls() {
Logger.doExit(thisJoinPoint.getSignature() + " with normal return");
}
after() throwing (Exception exc): loggableCalls() {
Logger.doExit(thisJoinPoint.getSignature() + " with " + exc + " thrown");
}
A primeira regra indica que deve ser feito o registro do retorno normal do m etodo
no ponto de junc ao. A segunda regra indica que, se a sada do m etodo foi feita por um
lancamento de excec ao, ent ao o registro da sada deve exibir a excec ao lancada.
Regras podem ser parametrizadas. Por exemplo, as regras after no trecho de
c odigo a seguir imprimem valores passados como par ametro para setX ou retornados
de getX.
pointcut settingX(int val): execution(void Point.setX(int)) && args(val);
pointcut gettingX(): execution(int Point.getX());
after(int val): settingX(val) {
System.out.println("Value assigned to x: " + val);
}
after() returning (int val): gettingX() {
System.out.println("Value of x: " + val);
}
Uma regra around envolve um ponto de junc ao e dene se a execuc ao deve prosse-
guir normalmente, ou com uma lista de par ametros diferente, ou ainda se outra operac ao
deve ser realizada sem a execuc ao do ponto de junc ao. A regra around dene tamb em
um tipo de retorno, de modo que e possvel especicar um valor de retorno diferente do
obtido na execuc ao do ponto de junc ao.
21
O exemplo a seguir mostra o uso de regras around para garantir os limites do
valor de x na classe Point. O conjunto de junc ao capturado e o conjunto das chamadas do
m etodo Point.setX. Na regra, testa-se o valor de x. Se este for v alido, ent ao a execuc ao do
ponto de junc ao continua normalmente com o valor passado. Caso contr ario, a excec ao
IllegalArgumentException e lancada.
void around(Point p, int x) : target(p) && args(x) && call(void setX(int)) {
if (x >= 0 && x < 100)
proceed(p, x);
else
throw new IllegalArgumentException();
}
4.2.6. Aspectos
Um aspecto e uma unidade modular de implementac ao de requisitos transversais. Aspec-
tos s ao denidos por declarac oes de aspectos, que s ao similares a declarac oes de classes
em Java. Declarac oes de aspectos podem declarar conjuntos de junc ao e regras, incluir
m etodos e campos e podem estender classes ou outros aspectos.
Ao contr ario de classes, aspectos n ao podem ser instanciados. Para obter re-
fer encia a um aspecto, utiliza-se o m etodo est atico aspectOf(), presente em todos os as-
pectos.
Para ilustrar, o exemplo a seguir mostra a declarac ao do aspecto LoggingAspect,
que dene os conjuntos de junc ao publicMethods, logObjectCalls e loggableCalls, e regras
after e before para loggableCalls.
public aspect LoggingAspect {
pointcut publicMethods(): execution(public * *(..));
pointcut logObjectCalls() : execution(* Logger.*(..));
pointcut loggableCalls() : publicMethods() && ! logObjectCalls();
before(): loggableCalls() {
Logger.logEntry(thisJoinPoint.getSignature().toString());
}
after(): loggableCalls() {
Logger.logExit(thisJoinPoint.getSignature().toString());
}
}
O controle de visibilidade de membros de aspectos em AspectJ e igual ao controle
de visibilidade de membros de classes em Java, sendo possvel utilizar os modicadores
public, private ou protected, ou ainda denir visibilidade de pacotes, se nenhum dos
tr es modicadores for utilizado.
Aspectos podem ser estendidos ou especializados, sendo neste caso denominados
subaspectos, formando uma hierarquia de aspectos. N ao e permitida a denic ao de hie-
rarquias m ultiplas de aspectos. As regras para redenic ao de conjuntos e regras de junc ao
em subaspectos s ao similares ` as regras de redenic ao de m etodos em Java.
22
Um aspecto pode ser abstrato, ou pode possuir conjuntos de junc ao abstratos.
A sem antica de conjuntos de junc ao abstratos e semelhante a de m etodos abstratos: as
decis oes de implementac ao s ao adiadas para aspectos concretos que estendam aspectos
abstratos. O exemplo da Sec ao 5.4 mostra uma implementac ao de aspecto e conjunto de
junc ao abstratos.
Em AspectJ, e possvel ainda declarar conjuntos est aticos de junc ao dentro de
classes. Entretanto, n ao e permitido a uma classe declarar regras; apenas aspectos podem
conter regras. Aspectos internos a classes devem ser est aticos, pois n ao pertencem ` as suas
inst ancias. Por exemplo, a classe a seguir dene um aspecto est atico interno SetterEn-
forcement, que obriga o uso dos m etodos setX e setY em todos os pontos do programa,
evitando acesso direto aos campos x e y exceto nos corpos dos m etodos de alterac oes (ver
Sec ao 4.2.7).
public class Point {
private int x, y;
public Point(int x, int y) { this.x = x; this.y = y; }
public int getX() { return x; }
public int getY() { return y; }
public void setX(int x) { this.x = x; }
public void setY(int y) { this.y = y; }
static aspect SetterEnforcement {
declare error: set(int Point.*) && !withincode(void Point.set*(int)):
"Use setter method, even inside Point class.";
}
}
4.2.7. Transversalidade Est atica
Algumas implementac oes de aspectos, como por exemplo a implementac ao de padr oes de
projeto, necessitam de recursos para alterar tanto o comportamento das classes em tempo
de execuc ao, quanto a sua estrutura est atica.
A transversalidade din amica, obtida a partir de regras de junc ao, permite modi-
car o comportamento da execuc ao do programa, ao passo que a transversalidade est atica
permite redenir a estrutura est atica dos tipos classes, interfaces ou outros aspectos e
o seu comportamento em tempo de execuc ao.
EmAspectJ, e possvel implementar os seguintes tipos de transversalidade est atica:
(i) introduc ao de campos e m etodos em classes e interfaces; (ii) modicac ao da hierarquia
de tipos; (iii) declarac ao de erros e advert encias de compilac ao; (iv) enfraquecimento de
excec oes.
Introduc ao de Campos e M etodos em Classes e Interfaces
A linguagem AspectJ possui um mecanismo denominado introduc ao, que permite
a inclus ao de atributos e m etodos em classes ou interfaces de forma transversal.

E possvel
tamb em adicionar campos e m etodos n ao-abstratos em implementac oes de interfaces de
Java, permitindo adicionar um comportamento default ` as classes que as implementem.
Isto permite que o desenvolvedor evite duplicidade de c odigo em cada classe, visto que
tal adic ao informa ao compilador de aspectos que este c odigo deve ser includo nas classes
que implementem as interfaces.
23
Sem AspectJ, a estrat egia usual consiste na criac ao de uma classe com a im-
plementac ao default da interface, de modo que uma classe que implemente a interface
possa ser denida como subclasse da classe com a implementac ao default. Por exem-
plo, a classe MouseAdapter e uma implementac ao default da interface MouseListener,
fornecendo uma implementac ao vazia para cada um dos seus m etodos. Uma classe que
precisar, por exemplo, denir somente o comportamento do m etodo mouseClicked pode
estender esta classe, sem a necessidade de implementar os demais m etodos. Entretanto,
isto s o pode ser utilizado se a classe n ao precisar estender outra classe do programa. O
uso simplesmente de classes abstratas no lugar de interfaces impede o re uso de outras
classes via heranca. Este problema pode tamb em ser resolvido por meio de composic ao.
Entretanto, esta soluc ao consiste na implementac ao de diversos m etodos de uma unica
linha, dando origem a espalhamento.
Por exemplo, considere a interface a seguir cujo objetivo e modelar entidades que
possam possuir um nome:
public interface Nameable {
public void setName(String name);
public String getName();
}
Cada classe que implementa esta interface deve denir os seus dois m etodos, como
no exemplo a seguir:
public class Entity implements Identiable, Nameable {
private String name;
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
C odigo semelhante deve ser inserido em todas as classes que implementarem esta
interface. Para evitar esta duplicidade de c odigo, e possvel denir um aspecto que in-
troduza a implementac ao default dos m etodos para a interface. Para incluir atributos e
m etodos em interfaces e classes em Java, qualica-se o seu nome com o nome da classe
ou interface onde ser a inserido, seguido de um ponto.
public interface Nameable {
public void setName(String name);
public String getName();
static aspect DefaultImplementation {
private String Nameable.name;
public void Nameable.setName(String name) {
this.name = name;
}
public String Nameable.getName() {
return name;
}
}
}
Com esta nova implementac ao, as classes que implementam a interface Nameable
24
n ao precisam mais denir os m etodos, se a implementac ao default estiver adequada para
a classe. Se alguma classe que implementa uma interface com comportamento default
precisar personalizar algum m etodo, basta fazer a sua implementac ao direta, pois estes
ir ao redenir a implementac ao default introduzida no aspecto.
A nova vers ao da classe Entity e mostrada a seguir:
public class Entity implements Identiable, Nameable {
}
A soluc ao tradicional de Java consiste em criar uma classe DefaultNameable, con-
tendo as implementac oes default. A classe Entity deve ser, portanto, subclasse de Default-
Nameable. Entretanto, esta abordagem funciona adequadamente somente para a imple-
mentac ao de uma unica interface. Considere, por exemplo, a interface Identiable denida
a seguir:
public interface Identiable {
public long getId();
public void setId(long id);
}
Se Entity implementar as interfaces Nameable e Identiable, sem o uso de AspectJ,
ser a necess ario estender uma das classes de implementac ao default e implementar a outra
interface, isto pode gerar duplicidade de c odigo. Entretanto, se a mesma abordagem de
comportamento default em AspectJ for utilizada para a interface Identiable, a classe
Entity n ao precisar a implementar os seus m etodos, podendo utilizar as implementac oes
default de ambas interfaces.
public interface Identiable {
public long getId();
public void setId(long id);
static aspect DefaultImplementation {
public long Identiable.id;
public long Identiable.getId() {
return id;
}
public void Identiable.setId(long id) {
this.id = id;
}
}
}
Com isto, a classe Entity implementa ambas as interfaces e o efeito e o mesmo de
estender as duas implementac oes default se heranca m ultipla fosse permitida em Java.
Modicac ao da Hierarquia de Tipos
Em AspectJ, e possvel modicar a hierarquia de classes, de modo a denir su-
perclasses e implementac ao de interfaces para classes e interfaces j a existentes, desde que
isto n ao viole as regras de heranca de Java. Como conseq u encia, obt em-se o desacopla-
mento dos aspectos e das classes especcas da aplicac ao, aumentando, assim, o grau de
re uso dos aspectos.
25
Tais declarac oes t em a forma:
declare parents: tipo-lho implements lista-interfaces;
declare parents: tipo-lho extends classe-ou-lista-interfaces;
Por exemplo, a declarac ao a seguir dene que a classe Temperature implementa a
interface Subject:
declare parents: Temperature implements Subject;
A declarac ao de parents deve obedecer ` as regras de hierarquias de classes em
Java. Por exemplo, n ao e possvel declarar superclasses para interfaces, ou ent ao denir
superclasses que resultem em heranca m ultipla.
Declarac ao de Erros e Advert encias de Compilac ao
Em AspectJ, e possvel declarar erros e advert encias de compilac ao. Com este
mecanismo, obt em-se comportamento similar ao obtido por meio das diretivas de compi-
lac ao #error e #warning.
A construc ao declare error permite denir erros de compilac ao para serem exi-
bidos quando o compilador detectar a presenca de pontos de junc ao identicados por um
dado conjunto de junc ao. O compilador de AspectJ ent ao lanca um erro, imprime a men-
sagem especicada para cada uso indevido e termina o processo de compilac ao. Esta
construc ao tem a forma:
declare error: conjunto-junc ao : mensagem-erro;
Da mesma forma, e possvel denir advert encias de compilac ao, em que uma
mensagem de erro e gerada, mas o processo de compilac ao n ao e interrompido:
declare warning: conjunto-junc ao : mensagem-erro;
O exemplo abaixo permite controlar a operac ao de escrita no campo x da classe
Point, permitindo que somente o m etodo setX lhe faca o acesso direto. Isto obriga todos
os demais m etodos a utilizarem setX, mesmo dentro da classe Point:
declare error: set(int Point.*) && !withincode(void Point.set*(int)):
"Use setter method, even inside Point class.";
Enfraquecimento de Excec oes
A linguagem Java obriga que todas as excec oes, com excec ao das subclasses de
RuntimeException e Error, sejam declaradas na assinatura dos m etodos ou capturadas e
tratadas. Esta abordagem e util por lembrar o desenvolvedor de tratar condic oes de erro
no programa.
Entretanto, emalgumas situac oes, e possvel ter certeza de que uma excec ao nunca
ocorre, de modo que o c odigo necess ario para tratar a excec ao torna-se in util e polui
a implementac ao. Por exemplo, considere que um m etodo escreva informac oes em um
arquivo tempor ario e, logo em seguida, abra este arquivo para leitura. A operac ao de
abertura do arquivo deve estar contida em um trecho de c odigo que trate a excec ao de
arquivo n ao encontrado, FileNotFoundException. Entretanto, o c odigo de tratamento ou
26
de relancamento da excec ao e in util, pois tem-se certeza de que o arquivo existe ele
acabou de ser criado pelo pr oprio programa.
Em AspectJ, e possvel, por meio da construc ao declare soft, silenciar excec oes
de forma seletiva e relanc a-las como excec oes n ao checadas. Esta construc ao e constituda
por uma excec ao e por um conjunto de junc ao. A sua sem antica consiste em enfraquecer
a excec ao para o conjunto de junc ao especicado, fazendo com que o compilador Java
n ao exija o seu tratamento.
declare soft: tipo-excec ao : conjunto-de-junc ao;
No exemplo acima considere que o m etodo void SomeClass.someMethod() crie
um arquivo tempor ario e, em seguida reabra este arquivo para leitura, de modo que n ao h a
d uvidas de que o arquivo exista. A declarac ao a seguir dene que a excec ao n ao precisa
ser tratada, o que simplica a escrita do m etodo:
declare soft: FileNotFoundException
: withincode(void SomeClass.someMethod());
4.3. Conclus ao
A linguagem AspectJ permite a implementac ao de programac ao orientada por aspectos
em Java. Seus mecanismos de transversalidade permitem realizar interfer encias tanto na
estrutura est atica das classes de umprograma Java quanto no comportamento do programa
durante a sua execuc ao.
Dentre as linguagens que implementam orientac ao por aspectos, destacam-se Hy-
perJ [32], Jiazzi [29], AspectC++ [2], DemeterJ [26], AspectWerkz [4].
A linguagem HyperJ [32] foi desenvolvida pela IBM para o suporte ` a metodologia
de separac ao multi-dimensional e integrac ao de requisitos em Java. O objetivo desta me-
todologia e quebrar a tirania da decomposic ao dominante, permitindo que cada requisito
seja implementado em uma dimens ao distinta, de modo que o ambiente de compilac ao
faca a composic ao, de forma semelhante ` a feita em AspectJ.
A linguagem Jiazzi [29] e uma extens ao de Java que permite a compilac ao se-
parada de m odulos denominados units. Estas units funcionam de forma semelhante a
aspectos em AspectJ, podendo alterar a estrutura e o comportamento de classes.
A linguagem AspectC++ [2] e uma implementac ao de orientac ao por aspectos em
C++, com projeto baseado na linguagem AspectJ.
DemeterJ [26] e uma implementac ao da metodologia de programac ao adaptativa
em Java. O seu objetivo e modularizar a implementac ao de requisitos relacionados a
travessia de objetos em um sistema.
AspectWerkz [4] implementa transversalidades est atica e din amica, permitindo
que o processo de costura de c odigo seja feito durante a compilac ao ou durante a execuc ao.
A sua implementac ao e exvel, permitindo que c odigo de transversalidade seja imple-
mentada como combinac ao de c odigo Java com anotac oes e arquivos XML.
O poder de express ao e recursos especiais destas linguagens para desenvolvimento
de sistemas baseados em aspectos situam-se em um mesmo patamar de equival encia.
Entretato, AspectJ destaca-se por sua grande difus ao e alta ader encia ` a proposta inicial do
criador da programac ao orientada por aspectos.
27
5. Exemplos de Aplicac oes de Orientac ao por Aspectos
5.1. Introduc ao
Nesta sec ao, s ao discutidas implementac oes de bibliotecas reutiliz aveis utilizando orien-
tac ao por aspectos. Na primeira parte, e mostrada a implementac ao de um mecanismo
modular e n ao-intrusivo para a gerac ao de registros de operac oes. Em seguida, mostra-se
uma implementac ao em AspectJ do padr ao singleton [15], em que o c odigo de controle
do padr ao e separado do c odigo da classe implementada para se ter inst ancia unica. O
terceiro exemplo da sec ao e a implementac ao em AspectJ de outro importante padr ao de
projetos, o observador [15]; esta implementac ao e tamb em n ao-intrusiva e n ao exige que
as classes participantes implementem as interfaces pr e-denidas para o padr ao.
5.2. Gerac ao de Registros de Operac oes
Apresenta-se, nesta sec ao a implementac ao completa das classes e aspectos para gerac ao
de registros de operac oes. A implementac ao por meio de aspectos desta funcionalidade
foi adaptada da soluc ao apresentada em [16].
A classe respons avel pela gerac ao dos registros de operac oes e a classe Logger,
denida a seguir. Esta classe possui m etodos para registrar entradas de m etodos, sadas
de m etodos por meio de retorno ou por meio de lancamento de excec oes e registro de
tratamento de excec oes.
public class Logger {
public static void logEntry(String signature) {
System.out.println("Entering " + signature);
}
public static void logNormalExit(String signature) {
System.out.println("Normal return of " + signature);
}
public static void logExitWithException(String signature, Exception exc) {
System.out.println("Return of " + signature + " with exception " + exc);
}
public static void logExceptionHandling(Exception exc) {
System.out.println("Handling exception " + exc);
}
}
Observando-se os m etodos que cont em chamadas dos m etodos da classe Logger,
observa-se quais pontos do programa s ao os candidatos a pontos de junc ao. Pelo exemplo
da Sec ao 2, v e-se que h a c odigo de gerac ao de registros espalhados no incio e no nal
dos corpos de cada m etodo. Esta constatac ao leva ` a denic ao do conjunto de junc ao
loggableCalls. Al em disso, e preciso registrar tamb em as execuc oes dos tratadores de
excec oes, sendo assim necess ario denir o conjunto de junc ao exceptionHandling.
28
Considere o aspecto denido a seguir:
public aspect LoggingAspect {
pointcut publicMethods(): execution(public * *(..));
pointcut logObjectCalls() : execution(* Logger.*(..));
pointcut loggableCalls() : publicMethods() && ! logObjectCalls();
pointcut exceptionHandling(Exception exc): handler(Exception+) && args(exc);
before(): loggableCalls() {
Logger.logEntry(thisJoinPoint.getSignature().toString());
}
after() returning: loggableCalls() {
Logger.logNormalExit(thisJoinPoint.getSignature().toString());
}
after() throwing (Exception exc) : loggableCalls() {
Logger.logExitWithException(thisJoinPoint.getSignature().toString(), exc);
}
before(Exception exc): exceptionHandling(exc) {
Logger.logExceptionHandling(exc);
}
}
O aspecto LoggingAspect dene os conjuntos de junc ao para captura dos m etodos
cujas execuc oes devem ser registradas (loggableCalls) e para captura de tratamento de
excec oes (exceptionHandling). O conjunto de junc ao exceptionHandling e parametrizado
para permitir a impress ao do nome da excec ao na gerac ao do registro de operac oes.
As regras de junc ao do aspecto chamam os m etodos da classe Logger com os
par ametros apropriados para fazer os registros da execuc ao. A regra before no conjunto
de junc ao loggableCalls indica que a chamada de Logger.logEntry deve ser includa antes
da execuc ao de todos os m etodos p ublicos do programa. Da mesma forma, as regras after
para o mesmo conjunto de junc ao denem os m etodos a serem chamados ao nal de cada
execuc ao de m etodo. O uso de returning e throwing permite que o retorno normal e o
retorno com lancamento de excec ao sejam tratados diferentemente.
Como aspecto LoggingAspect e possvel modularizar toda a poltica de gerac ao de
registros de operac ao do programa. No momento do weaving, as chamadas dos m etodos
da classe Logger s ao adicionadas nos pontos de junc ao identicados por loggableCalls, de
modo que o comportamento do programa e id entico ao obtido no exemplo da Sec ao 2.3.
5.3. Padr ao Singleton
O padr ao singleton tem por objetivo denir classes das quais se pode ter apenas uma
inst ancia. Exemplos de uso do padr ao singleton s ao f abricas de sess oes, que possuem,
geralmente, uma unica inst ancia no programa. Em geral, as subclasses podem criar
inst ancias da classe singleton.
Nesta sec ao apresentam-se o padr ao singleton [15] e as diculdades em denir
este padr ao em linguagens orientadas por objetos, em especial quando as classes parti-
cipantes n ao implementam as interfaces pr e-denidas para o padr ao. Mostra-se a partir
da como a denic ao de um pequeno conjunto de aspectos permite tornar qualquer classe
29
participante do padr ao, independentemente do seu intuito inicial. A implementac ao por
meio de aspectos para este padr ao foi adaptada da soluc ao apresentada em [19].
O exemplo ilustrado nesta sec ao e uma implementac ao do padr ao singleton para
uma classe Printer. Para garantir inst ancia unica deve-se denir o construtor da classe
como privado ou protegido. O uso de protegido garante, ainda, que as subclasses podem
criar inst ancias da superclasse. Os objetos do programa que desejarem obter a inst ancia
unica da classe devem utilizar o m etodo est atico instance, que retorna a inst ancia unica
caso exista, ou cria uma nova inst ancia se ainda nenhuma tiver sido criada. Utiliza-se um
atributo est atico, uniqueInstance para armazenar a inst ancia unica da classe.
// Implements a Printer as a singleton
public class PrinterSingleton {
private static int objectsSoFar = 0; // Counts the instances of this class
private static PrinterSingleton uniqueInstance = null; // Stores the printer unique instance
private int id; // Each instance has a distinct id
protected PrinterSingleton() { // Creates a new printer: note it is protected
id = ++objectsSoFar;
}
public static PrinterSingleton instance() { // Factory method used to create a new instance
if (uniqueInstance == null) {
uniqueInstance = new PrinterSingleton();
}
return uniqueInstance;
}
public void print() { // Prints the instance of the printer
System.out.println("\tMy ID is " + id);
}
}
Os seguintes problemas de modularizac ao podem ser vistos neste c odigo: (i) o
c odigo de denic ao do padr ao e intrusivo no c odigo da classe; (ii) o c odigo de denic ao
do padr ao n ao pode ser reaproveitado em outras classes que precisarem fazer controle de
unica inst ancia; (iii) e possvel violar o protocolo singleton dentro de pacotes ou subclas-
ses em Java. Para evitar estes problemas, pode-se criar o aspecto abstrato SingletonProto-
col, denido a seguir.
import java.util.Hashtable;
// Denes the general behavior of the Singleton design pattern.
public abstract aspect SingletonProtocol {
private Hashtable singletons = new Hashtable(); // Stores the singletons instances
public interface Singleton {} // Denes Singleton interface, implemented by singleton classes
public pointcut protectionExclusions(); // Denes which points are allowed to create new instances
// Protects the constructor of a singleton class
Object around() : call((Singleton +).new (..)) && !protectionExclusions() {
Class singleton = thisJoinPoint.getSignature().getDeclaringType();
if (singletons.get(singleton) == null)
singletons.put(singleton, proceed());
return singletons.get(singleton);
}
}
30
Este aspecto usa uma tabela, singletons, para conter as inst ancias unicas de cada
classe, e dene uma interface Singleton, que e utilizada nos subaspectos de Singleton-
Protocol para garantir consist encia de tipos com a implementac ao. O conjunto de junc ao
protectionExclusions pode ser utilizado para denir pontos que t em a permiss ao de criar
inst ancias de uma classe singleton; por exemplo, subclasses de uma classe singleton po-
dem criar novas inst ancias da classe.
A garantia de unicidade de inst ancia de uma classe e feita pela regra around, que e
executada ao redor das chamadas de construtor das classes que implementam a interface
Singleton. Oc odigo da regra tenta localizar na tabela singletons a inst ancia unica da classe
cujo construtor est a sendo chamado. Se nenhuma inst ancia da classe for encontrada na
tabela, ent ao armazena-se uma nova inst ancia criada por meio da chamada de proceed().
A inst ancia na tabela e ent ao retornada como resultado da chamada do construtor.
A seguir, apresentam-se a classe Printer, que n ao possui c odigo de implementac ao
do padr ao, e uma subclasse PrinterSubclass, que n ao implementa o padr ao singleton.
public class Printer {
private static int objectsSoFar = 0; // Counts the instances of the class
private int id; // Each instance has a distinct id
public Printer() { // Constructor: note it is not protected
id = ++objectsSoFar;
}
public void print() { // Prints the id of the instance
System.out.println("\tMy ID is " + id);
}
}
// This class has access to the singleton constructor
public class PrinterSubclass extends Printer {
public PrinterSubclass() { // Creates an instance of this class
super();
}
}
Para garantir a exist encia de uma unica inst ancia da classe Printer, dene-se o as-
pecto SingletonInstance, que estende SingletonProtocol. Dene-se neste aspecto que a
classe Printer implementa a interface Singleton. Al em disso, redene-se o conjunto de
junc ao protectionExclusions, que captura todas as chamadas de construtor de PrinterSub-
class; isto permite que esta classe e suas subclasses possam instanciar Printer.
// Implements a concrete instance of the Singleton pattern. It declares
// Printer to be Singleton and denes an exception to the constructor
// protection: PrinterSubclass (a subclass of the Singleton) can still
// access Printers constructor.
public aspect SingletonInstance extends SingletonProtocol {
// Gives Printer the Singletons protection
declare parents : Printer implements Singleton;
// Allows Printer subclasses to access the constructor
public pointcut protectionExclusions(): call((PrinterSubclass +).new (..));
}
31
A implementac ao do padr ao singleton via aspectos e n ao-intrusiva, pois n ao e ne-
cess ario alterar a interface da classe para que esta seja adequada ao padr ao. Al em disso, o
c odigo do padr ao pode ser completamente reaproveitado em outras implementac oes; com
efeito, para denir que outra classe qualquer possui inst ancia unica, basta acrescentar ou-
tra declarac ao de implementac ao da interface Singleton no aspecto SingletonInstance. Por
meio da redenic ao do conjunto de junc ao protectionExclusion, e possvel ainda permitir
que subclasses possuam m ultiplas inst ancias, sem a necessidade de denir o construtor da
classe de unica inst ancia como protegido (protected). Desta maneira, n ao e necess ario vi-
olar o princpio aberto-fechado
2
[28, 30] para permitir m ultiplas inst ancias das subclasses
de uma classe de unica inst ancia.
5.4. Padr ao Observador
A implementac ao do padr ao observador por meio de linguagens orientadas por objetos
puras, como a mostrada na Sec ao 2.4, apresenta problemas de modularizac ao, devido a
c odigo de atualizac ao dos observadores estar espalhado ao longo do c odigo dos objetos
observados. Nesta sec ao, apresenta-se uma implementac ao do padr ao observador utili-
zando AspectJ. A implementac ao por meio de aspectos para este padr ao foi adaptada da
soluc ao apresentada em [19].
O aspecto abstrato ObserverProtocol, denido a seguir, e respons avel por mapear
objetos em seus observadores. Este aspecto possui os seguintes elementos:
as interfaces Subject e Observer representam, respectivamente, um objeto alvo
de observac ao, doravante denominado alvo, e um observador; estas interfaces s ao
utilizadas para consist encias de tipos nos demais elementos do aspecto;
o mapeamento perSubjectObservers e respons avel por armazenar as listas de ob-
servadores de cada alvo;
os m etodos addObserver e removeObserver s ao respons aveis por adicionar e re-
mover um observador da lista de observadores de um alvo, respectivamente;
o m etodo getObserver e respons avel por retornar a lista de observadores de um
alvo, armazenada na tabela perSubjectObservers; e respons avel tamb em por criar
uma nova lista vazia e associ a-la a um alvo, caso este ainda n ao esteja cadastrado
na tabela;
o conjunto de junc ao abstrato subjectChange deve ser redenido nos subaspec-
tos de ObserverProtocol; nos subaspectos, ele dene os m etodos respons aveis por
alterar o estado interno dos objetos observados (ver aspecto TemperatureObser-
vation, denido a seguir);
o m etodo abstrato updateObserver deve ser redenido nos subaspectos, de modo
que dena as ac oes de noticac ao dos observadores quando o estado interno do
sujeito for alterado;
a regra after denida para o conjunto de junc ao subjectChange e respons avel por
obter a lista de observadores de um alvo e chamar o m etodo de noticac ao para
cada observador; este c odigo e includo ap os cada ponto de junc ao que represente
uma mudanca de estado do objeto alvo.
A implementac ao do aspecto e a seguinte:
2
A classe de unica inst ancia e aberta para extens oes, mas fechada para modicac oes.
32
import java.util.List;
import java.util.LinkedList;
import java.util.Iterator;
import java.util.WeakHashMap;
public abstract aspect ObserverProtocol {
public interface Subject {}
public interface Observer {}
private WeakHashMap perSubjectObservers;
private List getObservers(Subject s) {
if (perSubjectObservers == null) {
perSubjectObservers = new WeakHashMap();
}
List observers = (List) perSubjectObservers.get(s);
if (observers == null) {
observers = new LinkedList();
perSubjectObservers.put(s, observers);
}
return observers;
}
public void addObserver(Subject s, Observer o) {
getObservers(s).add(o);
updateObserver(s,o);
}
public void removeObserver(Subject s, Observer o) {
getObservers(s).remove(o);
}
abstract public pointcut subjectChange(Subject s);
abstract public void updateObserver(Subject s, Observer o);
after(Subject s): subjectChange(s) {
Iterator it = getObservers(s).iterator();
while (it.hasNext()) {
updateObserver(s, (Observer) it.next());
}
}
}
Para implementar o padr ao observador utilizando aspectos, deve-se denir: (i) os
objetos alvo de observac ao; (ii) os objetos observadores; (iii) as operac oes dos alvos que
denem as alterac oes do estado interno; (iv) o algoritmo de atualizac ao de cada observa-
dor; (v) os momentos em que a observac ao sobre um alvo inicia e termina.
Para denir que uma classe e observadora de outra, deve-se implementar um as-
pecto que estenda ObserverProtocol e que dena o conjunto de junc ao de modicac ao do
estado interno e o m etodo de noticac ao de observadores.
33
Considere, por exemplo, as classes Termometer e Temperature a seguir:
public abstract class Termometer {
public abstract void printTemperature(double value);
}
public class Temperature {
private double value;
public Temperature(double initialValue) {
value = initialValue;
}
public double getValue() {
return value;
}
public void setValue(double value) {
this.value = value;
}
}
O aspecto TemperatureObservation, mostrado a seguir, estende o aspecto Obser-
verProtocol, denindo que Termometer implementa a interface Observer, Temperature
implementa a interface Subject. Denem-se tamb em que o conjunto de junc ao sub-
jectChange representa todas as execuc oes do m etodo Temperature.setValue, e que a
noticac ao dos observadores e feita por meio da chamada do m etodo de impress ao da
temperatura, Termometer.printTemperature.
public aspect TemperatureObservation extends ObserverProtocol {
declare parents: Temperature implements Subject;
declare parents: Termometer implements Observer;
public pointcut subjectChange(Subject s)
: target(s) && execution(void Temperature.setValue(double));
public void updateObserver(Subject s, Observer o) {
Temperature temperature = (Temperature) s;
Termometer termometer = (Termometer) o;
termometer.printTemperature(temperature.getValue());
}
}
A seguir, denem-se duas subclasses Termometer: TermometerCelsius e Termo-
meterFahrenheit.
public class TermometerCelsius extends Termometer {
public void printTemperature(double value) {
System.out.println("Celsius: " + value);
}
}
34
<<stereotype>>
&DOOHU
<<stereotype>>
2SHUDWLRQ
+operation( ... )
+context: CallerContext
+doSomething( )
suboperations
<<stereotype>>
:RUNHU
+work( ... )
Figura 7: Representac ao em UML do padr ao wormhole.
public class TermometerFahrenheit extends Termometer {
public void printTemperature(double value) {
System.out.println("Fahrenheit: " + value);
}
}
Para associar uma inst ancia de uma classe term ometro como observadora de uma
inst ancia de temperatura, utiliza-se o m etodo addObserver do aspecto, como mostrado a
seguir:
TermometerCelsius term1 = new TermometerCelsius();
TermometerFahrenheit term2 = new TermometerFahrenheit();
TemperatureObservation.aspectOf().addObserver(t,term1);
TemperatureObservation.aspectOf().addObserver(t,term2);
O m etodo aspectOf e utilizado para referenciar a inst ancia unica de um aspecto.
As principais vantagens da abordagem s ao:
a modularizac ao completa do padr ao: foram retirados das classes do objeto ob-
servado e do observador os c odigos necess arios para implementac ao do padr ao
observador;
aumento do grau de re uso do padr ao: pode-se denir de maneira n ao-intrusiva
qualquer classe como observador ou alvo de observac ao, denindo-se somente
um aspecto que implemente o respectivo protocolo de observac ao.
5.5. Padr ao Wormhole
Considere o conjunto de classes denido na Figura 7, em que uma chamada tpica de
operac ao gera a execuc ao de diversas operac oes secund arias, representadas na forma do
grafo da Figura 8. A implementac ao por meio de aspectos para este padr ao foi adaptada
da soluc ao apresentada em [16].
Se um objeto Worker precisar de informac oes a respeito do contexto do objeto
Caller que iniciou a execuc ao das operac oes, pode-se denir par ametros nas chamadas de
m etodos dos objetos Operation para que este contexto seja propagado at e os objetos Wor-
ker. Esta implementac ao gera intrus ao, pois os objetos Operation podem n ao necessitar
35
Caller Operation
Worker Worker Worker
op op
op op
op op
<<context>>
<<context>> <<context>>
<<context>> <<context>>
<<context>>
<<context>>
<<context>>
<<context>> <<context>> <<context>>
Figura 8: Implementac ao de transmiss ao de contexto via passagem de
par ametros (Extrada de [20])
Caller Operation
Worker Worker Worker
op op
op op
op op
<<context>>
<<context>> <<context>> <<context>>
Figura 9: Representac ao gr aca do padr ao wormhole (Extrada de [20]).
36
das informac oes de contexto. Neste caso, a exist encia destes par ametros pode tornar com-
plexas as interfaces das classes Operation, produzindo assim alto grau de acoplamento
entre m odulos. Outra soluc ao possvel e denir uma area de acesso global, onde o objeto
Caller armazena seus dados para leitura pelos objetos Worker. Esta situac ao tamb em gera
alto grau de acoplamento entre os objetos Caller e Worker.
O padr ao wormhole tem por objetivo denir um canal direto de comunicac ao entre
os objetos Caller e Worker, tornando disponvel para os objetos Worker as informac oes
de contexto que ele precisar. Este padr ao permite encapsular a comunicac ao entre estes
objetos, propiciando uma implementac ao com grau de acoplamento menor que as im-
plementac oes que passam o contexto como par ametro ou o armazenam em uma area de
acesso global.
Figura 9 esquematiza a implementac ao da passagem de contexto por meio do
padr ao wormhole. Nesta implementac ao, a informac ao de contexto e transmitida dire-
tamente do objeto Caller para os objetos Worker, sem a necessidade de alterar a interface
dos objetos Operation.
O aspecto WormholePattern dene o padr ao wormhole.
public aspect WormholePattern {
pointcut invocations(Caller c):
this(c) && call(void Operation.doOperation());
pointcut workPoints(Worker w):
target(w) && call(void Worker.doWork());
pointcut perCallerWork(Caller c, Worker w):
cow(invocations(c)) && workPoints(w);
before (Caller c, Worker w): perCallerWork(c, w) {
w.setCallerContext(c.getContext());
}
}
Neste aspecto, denem-se os seguintes conjuntos de junc ao:
invocations: pontos de chamadas de m etodos da classe Operation, ou suas sub-
classes, que ocorrerem em m etodos cujo objeto receptor e da classe Caller;
workPoints: pontos de chamadas do m etodo doWork da classe Worker;
perCallerWork: pontos de chamadas do m etodo Worker.doWork() ou suas subclas-
ses, que ocorrerem no uxo de execuc ao de uma invocac ao de operac ao a partir
de m etodos da classe Caller.
A regra before aplicada ao conjunto de junc ao perCallerWork propaga para o
objeto Worker o contexto do objeto Caller cujo uxo de execuc ao gerou a chamada ao
m etodo Worker.doWork().
A implementac ao por meio de aspectos permite obter a propagac ao direta de
informac oes de contexto, sem aumentar a interface da classe Operation ou aumentar o
acoplamento entre as classes Caller e Worker por meio de valores globais. Al em disso,
todo o acoplamento entre as classes Caller e Worker e controlado pelo aspecto Wormhole-
Pattern, que funciona como mediador. Quaisquer alterac oes no contexto geram alterac oes
somente neste aspecto, de modo que as classes participantes n ao precisam ser alteradas.
37

E possvel denir tamb em um aspecto abstrato que represente o protocolo do

padr ao wormhole de maneira semelhante ` a feita nas implementac oes dos padr oes sin-
gleton e observador. Com isso, este padr ao tamb em pode possuir uma implementac ao
gen erica e reutiliz avel.
5.6. Conclus ao
Os exemplos apresentados nesta sec ao ilustram o poder de modularizac ao da orientac ao
por aspectos. Todos os exemplos geraram aspectos reutiliz aveis e permitiram a produc ao
de m odulos com baixo acoplamento e alta coes ao.
A gerac ao de registros de operac ao por meio de aspectos e totalmente indepen-
dente das classes do sistema. Ao se incluir uma nova classe no sistema, n ao e necess ario
que esta classe possua c odigo para gerar registros, pois a caracterstica transversal do
aspecto faz com que as operac oes desta nova classe sejam alvo de registro.
As implementac oes dos padr oes singleton e observador por meio de aspectos re-
tirou toda a intrus ao de c odigo das classes participantes. Os c odigos dos padr oes s ao to-
talmente reutiliz aveis, de modo que a criac ao de novas classes participantes pode ser feita
pela simples denic ao de um subaspecto do aspecto que dene o protocolo do padr ao.
A implementac ao do padr ao wormhole permite a criac ao de um canal de comu-
nicac ao direta entre classes, evitando aumentar a interface de classes intermedi arias no
uxo de execuc ao, ou o aumento do acoplamento via uso de dados de acesso global. A
soluc ao mostrada pode ser tamb em generalizada, o que a torna totalmente reutiliz avel.
38
6. Conclus oes
Odesenvolvimento de software orientado por aspectos foi proposto como objetivo de per-
mitir melhor modularizac ao de requisitos transversais de sistemas. A linguagem AspectJ
e uma linguagem que permite a implementac ao orientada por aspectos em Java.
Aprogramac ao orientada por aspectos n ao e umsubstituto para a programac ao ori-
entada por objetos. Os requisitos funcionais de um sistema continuar ao a ser implementa-
dos por meio da POO. A orientac ao por aspectos simplesmente adiciona novos conceitos
` a POO, facilitando a implementac ao de requisitos transversais e retirando grande parte da
atenc ao dada a tais requisitos nas fases iniciais de desenvolvimento. Com efeito, o desen-
volvedor pode se concentrar na implementac ao dos m odulos de requisitos funcionais do
sistema, permitindo que a implementac ao da distribuic ao dos requisitos transversais aos
m odulos seja feita separadamente.
O desenvolvimento orientado por aspectos permite denir claramente as respon-
sabilidades dos m odulos individuais, uma vez que cada m odulo e respons avel unicamente
por seu requisito principal. Al em disso, o nvel de modularizac ao do sistema e melhorado,
com baixo acoplamento e alta coes ao modular. Com efeito, ao retirar c odigo intruso dos
m odulos, e possvel diminuir a interface de cada m odulo e, ao mesmo tempo, aumentar
o seu nvel de coes ao, por tratar somente um requisito. As conseq u encias diretas destes
fatos s ao a melhoria do processo de manutenc ao de sistemas e aumento no grau de re uso.
Al em disso, a evoluc ao de sistemas e facilitada, visto que, se novos aspectos forem
criados para implementar novos requisitos transversais, as classes do programa podem
permanecer inalteradas. Da mesma forma, ao adicionar novas classes ao programa, os
aspectos existentes tamb em s ao transversais a estas classes.
Como principal ponto negativo, tem-se que a orientac ao por aspectos pode quebrar
o encapsulamento de m odulos, ao permitir acesso a detalhes de sua implementac ao e a
alterac ao da estrutura est atica de tipos.
Uma limitac ao importante da orientac ao por aspectos est a na integrac ao de m odu-
los, conforme destacado em [43]. Neste artigo discute-se o fato de que as implementac oes
atuais das linguagens de programac ao orientada por aspectos n ao permitem que aspectos
sejam instanciados, e isto pode dicultar a integrac ao de certos m odulos do sistema.
Ap os a leitura deste tutorial, os autores recomendam aos interessados em aprofun-
dar seus estudos no assunto a visita ao site [1], que e um dos reposit orios mais importantes
de material sobre o assunto. Nele, h a refer encias para projetos de pesquisa na area e uma
relac ao bastante extensa das ferramentas existentes.
Programac ao por aspectos ainda n ao resolve denitivamente a importante quest ao
da modularidade de sistemas computacionais complexos, mas, sem d uvida, trata-se de
area de pesquisa promissora e representa um dos mais importantes avancos desde o ad-
vento da programac ao orientada por objetos.
39
Refer encias
[1] Aosd.net. http://aosd.net/.

Ultimo acesso: 23 de maio de 2004.
[2] AspectC++. http://www.aspectc.org/.

Ultimo acesso: 23 de maio de 2004.
[3] Aspectj.org. http://www.aspectj.org.

Ultimo acesso: 23 de maio de 2004.
[4] AspectWerks. http://aspectwerkz.codehaus.org/.

Ultimo acesso: 23 de maio de 2004.
[5] Colin Atkinson and Thomas K uhne. Aspect-Oriented Development with Stratied Fra-
meworks. IEEE Software, 20:8189, 2003.
[6] Johan Brichau, Maurice Glandrup, Siobh an Clarke, and Lodewijk Bergmans. Advanced
Separation of Concerns. In Proceedings of 15th European Conference on Object-
Oriented Programming (ECOOP) Workshop Reader. Springer-Verlag, 2001.
[7] Siobh an Clarke. Extending Standard UML with Model Composition Semantics. Science
of Computer Programming, 44(1):71100, 2002.
[8] Siobh an Clarke and Robert J. Walker. Towards a Standard Design Language for AOSD.
In Proceedings of the 1st International Conference on Aspect-Oriented Software
Development, 2002.
[9] Yvonne Coady and Gregor Kiczales. Back to the Future: A Retroactive Study of Aspect
Evolution in Operating System Code. In Proceedings of the 2nd Aspect-Oriented
Software Development. Springer-Verlag, 2003.
[10] Yvonne Coady, Gregor Kiczales, Mike Feeley, Norm Hutchinson, and Joon Suan Ong.
Structuring Operating System Aspects: Using AOP to Improve OS Structure Modu-
larity. Commun. ACM, 44(10):7982, 2001.
[11] Yvonne Coady, Gregor Kiczales, Mike Feeley, and Greg Smolyn. Using AspectC to Im-
prove the Modularity of Path-specic Customization in Operating System Code. In
Proceedings of the 8th European software engineering conference held jointly with
9th ACM SIGSOFT international symposium on Foundations of software enginee-
ring, pages 8898. ACM Press, 2001.
[12] Constantinos A. Constantinides, Atef Bader, Tzilla H. Elrad, P. Netinant, and Mohamed E.
Fayad. Designing an Aspect-oriented Framework in an Object-oriented Environ-
ment. ACM Computing Surveys, 32(1es):41, 2000.
[13] Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.
[14] Eclipse.org. http://www.eclipse.org.

Ultimo acesso: 23 de maio de 2004.
[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, 1995.
[16] Joseph D. Gradecki and Nicholas Lesieck. Mastering AspectJ: Aspect-Oriented Program-
ming in Java. Wiley Publishing, Inc., 2003.
[17] Kris Gybels and Johan Brichau. Arranging language features for more robust pattern-
based crosscuts. In Proceedings of the 2nd international conference on Aspect-
oriented software development, pages 6069. ACM Press, 2003.
[18] Jan Hannemann, Thomas Fritz, and Gail C. Murphy. Refactoring to Aspects: an Interac-
tive Approach. In Proceedings of the 2003 OOPSLA workshop on eclipse technology
eXchange, pages 7478. ACM Press, 2003.
[19] Jan Hannemann and Gregor Kiczales. Design Pattern Implementation in Java and as-
pectJ. In Proceedings of the 17th ACM SIGPLAN conference on Object-oriented
40
programming, systems, languages, and applications, pages 161173. ACM Press,
2002.
[20] Gregor Kiczales. Aspect-Oriented Programming Keynote Talk at EclipseCon 2004.
Disponvel em http://www.cs.ubc.ca/gregor/.

Ultimo acesso: 23 de maio de 2004.
[21] Gregor Kiczales and Erik Hilsdale. Aspect-oriented programming. In Proceedings of the
8th European software engineering conference held jointly with 9th ACM SIGSOFT
international symposium on Foundations of software engineering, page 313. ACM
Press, 2001.
[22] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G.
Griswold. An Overview of AspectJ. In Proceedings of the 15th European Confe-
rence on Object-Oriented Programming. Springer-Verlag, 2001.
[23] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lo-
pes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In Pro-
ceedings of the 11th European Conference on Object-Oriented Programming, page
220ff. Springer-Verlag, 1997.
[24] Ramnivas Laddad. AspectJ in Action: Practical Aspect-Oriented Programming. Man-
ning, 2003.
[25] Donal Lafferty and Vinny Cahill. Language-independent Aspect-oriented Programming.
In Proceedings of the 18th ACM SIGPLAN conference on Object-oriented progra-
ming, systems, languages, and applications, pages 112. ACM Press, 2003.
[26] Karl J. Lieberherr and Doug Orleans. Preventive program maintenance in Demeter/Java
(research demonstration). In International Conference on Software Engineering,
pages 604605, Boston, MA, 1997. ACM Press.
[27] Log4J. http://www.log4j.org.

Ultimo acesso: 23 de maio de 2004.
[28] Robert C. Martin. The Open-Closed Principle. Disponvel em
www.objectmentor.com/resources/articles/ocp.pdf.

Ultimo acesso: 23 de maio
de 2004.
[29] Sean McDirmid and Wilson Hsieh. Aspect-Oriented Programming in Jiazzi. In Procee-
dings of the 2nd Aspect-Oriented Software Development. Springer-Verlag, 2003.
[30] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1997.
[31] Glenford J. Myers. Reliable Software through Composite Design. Petrocelli/Charter,
1975.
[32] Harold Ossher and Peri Tarr. Hyper/J: Multi-Dimensional Separation of Concerns for
Java. In Proceedings of the 22nd international conference on Software engineering,
pages 734737. ACM Press, 2000.
[33] Harold Ossher and Peri Tarr. Using Multidimensional Separation of Concerns to
(Re)Shape Evolving Software. Communications of the ACM, 44(10):4350, 2001.
[34] David L. Parnas. On the Criteria to be Used in Decomposing Systems into Modules.
Commun. ACM, 15(12):10531058, 1972.
[35] Rajeev R. Raje, Ming Zhong, and Tongyu Wang. Case Study: a Distributed Concurrent
System with AspectJ. SIGAPP Appl. Comput. Rev., 9(2):1723, 2001.
[36] Awais Rashid and Ruzanna Chitchyan. Persistence as an Aspect. In Proceedings of the
2nd Aspect-Oriented Software Development, pages 120129. Springer-Verlag, 2003.
[37] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unied Modeling Language
Reference Manual. Addison-Wesley Longman, 1999.
41
[38] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unied Modeling Language
User Guide. Addison-Wesley Longman, 1999.
[39] Robert J. Walker Siobh an Clarke. Composition Patterns: An Approach to Designing
Reusable Aspects. In Proceedings of the 23rd International Conference on Software
Engineering (ICSE), 2001.
[40] S ergio Soares, Eduardo Laureano, and Paulo Borba. Implementing Distribution and Per-
sistence Aspects with AspectJ. In Proceedings of the 17th ACM SIGPLAN confe-
rence on Object-oriented programming, systems, languages, and applications, pages
174190. ACM Press, 2002.
[41] Olaf Spinczyk, Andreas Gal, and Wolfgang Schr oder-Preikschat. AspectC++: An Aspect-
oriented Extension to the C++ Programming Language. In Proceedings of the For-
tieth International Conference on Tools Pacic, pages 5360. Australian Computer
Society, Inc., 2002.
[42] Dominik Stein, Stefan Hanenberg, and Rainer Unland. A UML-based Aspect-oriented
Design Notation for AspectJ. In Proceedings of the 1st international conference on
Aspect-oriented software development, pages 106112. ACM Press, 2002.
[43] Kevin Sullivan, Lin Gu, and Yuanfang Cai. Non-Modularity in Aspect-Oriented Lan-
guages: Integration as a Crosscutting Concern for AspectJ. In Proceedings of the
1st international conference on Aspect-oriented software development, pages 1937.
ACM Press, 2002.
[44] Arndt von Staa. Programac ao Modular. Editora Campus, 2000.
42