AspectJ Programacao orientada a aspectos em Java

S rgio Soares , Paulo Borba e

Centro de Inform tica a Universidade Federal de Pernambuco Caixa Postal 7851 CEP 50740-540 Recife, PE
scbs,phmb@cin.ufpe.br

Abstract. This document presents a tutorial about AspectJ, an aspect-oriented extension to Java. Aspect-oriented programming (AOP) tries to solve some inefciency of object-orientation, such as tangled code and code spread over several units, making harder software development and maintainability. AOP increases system modularity by separating code that implements specic functions, affecting different parts of the system, called crosscutting concerns. We present the main constructions of AspectJ, as well as examples of aspects to assist the assimilation of the concepts. We also discuss using design patterns to implement some features of AspectJ, and its benets and liabilities. Resumo. Este documento apresenta um tutorial sobre AspectJ, uma extens ao orientada a aspectos de Java. Programacao orientada a aspectos (AOP) procura solucionar algumas ineci ncias da orientacao a objetos, como o e entrelacamento e espalhamento de c digo com diferentes prop sitos. Este o o entrelacamento e espalhamento tornam o desenvolvimento e a manutencao destes sistemas extremamente difcil. AOP aumenta a modularidade separando c digo que implementa funcoes especcas, afetando diferentes partes do siso tema, chamadas preocupacoes ortogonais (crosscutting concern). Nos apresen tamos as principais construcoes de AspectJ, bem como exemplos de aspectos para auxiliar a assimilacao dos conceitos. Tamb m discutimos o uso de padr es e o de projetos para implementar algumas caractersticas de AspectJ, e discutimos suas vantagens e desvantagens.

1. Introducao
A necessidade de desenvolver software de qualidade aumentou o uso da orientacao a obje tos [Meyer, 1997, Booch, 1994] em busca de maiores nveis de reuso e manutenibilidade, aumentando a produtividade do desenvolvimento e o suporte a mudancas de requisitos. Entretanto, o paradigma orientado a objetos tem algumas limitacoes [Ossher et al., 1996, Ossher and Tarr, 1999], como o entrelacamento e o espalhamento de c digo com difer o entes prop sitos, por exemplo, o entrelacamento de c digo de neg cio com c digo de o o o o apresentacao, e o espalhamento de c digo de acesso a dados em v rios m dulos do sis o a o tema. Parte destas limitacoes podem ser compensadas com o uso de padr es de proje o tos [Buschmann et al., 1996, Gamma et al., 1994].

Apoiado pela CAPES Apoiado em parte pelo CNPq, processo 521994/969.

Figura 1: Diagrama de classe do sistema Health Watcher.

Por outro lado, extens es do paradigma orientado a objetos, como aspectoriented o programming (programacao orientada a aspectos) [Elrad et al., 2001], subjectoriented programming [Ossher and Tarr, 1999], e adaptive programming [J. et al., 1994], tentam solucionar as limitacoes do paradigma orientado a objetos. Estas t cnicas visam obter e uma maior modularidade de software em situacoes pr ticas onde a orientacao a objetos e a padr es de projetos n o fornecem suporte adequado. o a Uma destas t cnicas, programacao orientada a aspectos (AOP), parece bastante e promissora [Murphy et al., 2001, Elrad et al., 2001, Laddad, 2002]. AOP procura solucionar a ineci ncia em capturar algumas das importantes decis es de projeto que um e o sistema deve implementar. Esta diculdade faz com que a implementacao destas decis es o de projeto sejam distribudas pelo c digo, resultando num entrelacamento e espalhamento o de c digo com diferentes prop sitos. Este entrelacamento e espalhamento tornam o o o desenvolvimento e a manutencao destes sistemas extremamente difcil. Desta forma, AOP aumenta a modularidade separando c digo que implementa funcoes especcas, o afetando diferentes partes do sistema, chamadas preocupacoes ortogonais (crosscutting concern). Exemplos de crosscutting concerns s o persist ncia, distribuicao, controle de a e concorr ncia, tratamento de excecoes, e depuracao. O aumento da modularidade implica e em sistemas legveis, os quais s o mais facilmente projetados e mantidos. a AOP permite que a implementacao de um sistema seja separada em requisitos funcionais e n ofuncionais. Dos requisitos funcionais resultam um conjunto de coma ponentes expressos em uma linguagem de programacao atual, por exemplo, a linguagem Java [Gosling et al., 2000]. J dos requisitos n ofuncionais resultam um conjunto de asa a pectos (crosscutting concerns) relacionados as propriedades que afetam o comportamento ` do sistema. Com o uso da abordagem, os requisitos n ofuncionais podem ser facilmente a manipulados sem causar impacto no c digo de neg cio (requisitos funcionais), uma vez o o que estes c digos n o est o entrelacados e espalhados em v rias unidades do sistema. o a a a Desta forma, AOP possibilita o desenvolvimento de programas utilizando tais aspectos, o que inclui isolamento, composicao e reuso do c digo de implementacao dos aspectos. o

2. Um exemplo de crosscutting concern distribuicao

Vamos tomar como exemplo um sistema que registra queixas para o sistema p blico de u sa de. O nosso objetivo e distribuir este sistema utilizando RMI [Microsystems, 2001]. u A Figura 1 e um diagrama de classes UML [Booch et al., 1999] que mostra parte das classes do sistema Health Watcher. No diagrama est o representadas a a

classe fachada [Gamma et al., 1994], o ponto unico de acesso ao sistema, um Servlet Java [Hunter and Crawford, 1998], que implementa a interface com o usu rio, e neste a caso e respons vel por atualizar informacoes sobre uma queixa no sistema. Al m disso, a e ) do sistema e o respons vel a est o presentes classes que modelam as queixas ( a pela queixa ( ). A comunicacao a ser distribuda e a entre a classe fachada e a interface com o usu rio (servlets). a
!        & $ # %'%"

Distribuicao sem AOP Para implementar a distribuicao no sistema sem utilizar AOP teremos de alterar uma s rie e de classes. A Figura 2 mostra como o c digo de distribuicao afeta o c digo fonte das o o classes do sistema. O c digo que est selecionado (por ret ngulos) nestas classes e reo a a spons vel pela implementacao da distribuicao com RMI. a

Figura 2: Codigo fonte do sistema distribudo sem AOP.

Note que o c digo de distribuicao (selecionado por caixas) est entrelacado com o a c digo funcional das classes e est espalhado por v rias classes do sistema. Esta falta de o a a modularidade torna o sistema difcil de manter e evoluir. Imagine que queiramos alterar o protocolo de comunicacao, por exemplo, para CORBA [Orfali and Harkey, 1998], ou outro protocolo qualquer. Teramos que alterar diretamente v rias classes do sistema. a

Distribuicao com AOP Para distribuir o mesmo sistema utilizando AOP, teramos de denir um aspecto de distribuicao que faz as alteracoes necess rias no sistema, para torn lo distribudo. a a Lembre-se que AspectJ pode alterar a estrutura est tica e din mica das classes de um a a sistema. A Figura 3 mostra o resultado do uso de AOP.

Figura 3: Codigo fonte do sistema distribuido com AOP.

Note que as classes do sistema foram preservadas. Al m de n o haver c digo de e a o distribuicao espalhado pelo sistema e entrelacamento com c digo funcional, a alteracao o do sistema n o e invasiva, ou seja, n o e feita com alteracao direta do c digo fonte. A a a o mesma e feita automaticamente atrav s da composicao do sistema com o aspecto denido. e Este processo e chamado de weaving, ou recomposicao aspectual. A Figura 4 mostra o processo de recomposicao. O weaver e um compilador que dado o c digo fonte de um sistema e um con o junto de aspectos gera uma vers o do sistema com estes aspectos, como, por exemplo, o a aspecto de distribuicao. Para tornar o sistema distribudo utilizando outro protocolo, se ria necess rio implementar outro aspecto que utiliza o protocolo requerido e em seguida a utilizar o weaver de AspectJ para gerar a vers o do sistema distribuda com tal protocolo. a

Figura 4: Recomposicao aspectual, ou weaving.

Desta forma teremos a denicao de um aspecto de distribuicao que afeta as classes do sistema para implementar a sua distribuicao com RMI, como mostrado no diagrama de classes na Figura 5.

Figura 5: Diagrama de classe do sistema Health Watcher levando em conta o aspecto de distribuicao.

Observe que o aspecto de distribuicao afeta a interface com o usu rio, a fachada e a os dados que s o transmitidos entre eles. a

3. AspectJ
Nesta secao apresentamos a linguagem AspectJ [Kiczales et al., 2001], uma extens o ori a entada a aspectos, de prop sito geral, da linguagem Java [Gosling et al., 2000]. o 3.1. Anatomia de um aspecto A principal construcao em AspectJ e um aspecto. Cada aspecto dene uma funcao es pecca que pode afetar v rias partes de um sistema, como, por exemplo, distribuicao. a Um aspecto, como uma classe Java, pode denir membros (atributos e m todos) e uma e hierarquia de aspectos, atrav s da denicao de aspectos especializados. e Aspectos podem alterar a estrutura est tica de um sistema adicionando membros a (atributos, m todos e construtores) a uma classe, alterando a hierarquia do sistema, e e convertendo uma excecao checada por uma n o checada (excecao de runtime). Esta car a acterstica de alterar a estrutura est tica de um programa e chamada static crosscutting. a Al m de afetar a estrutura est tica, um aspecto tamb m pode afetar a estrutura e a e din mica de um programa. Isto e possvel atrav s da interceptacao de pontos no uxo a e de execucao, chamados join points, e da adicao de comportamento antes ou depois dos mesmos, ou ainda atrav s da obtencao de total controle sobre o ponto de execucao. Exe emplos de join points s o: invocacao e execucao de m todos, inicializacao de objetos, a e execucao de construtores, tratamento de excecoes, acesso e atribuicao a atributos, entre outros. Ainda e possvel denir um join point como resultado da composicao de v rios a join points. Normalmete um aspecto dene pointcuts, os quais selecionam join points e valores nestes join points e advices que denem o comportamento a ser tomado ao alcancar os join points denidos pelo pointcut.

Nas secoes seguintes, a medida que apresentamos as construcoes de AspectJ, ex ` emplicamos as mesmas mostrando a implementacao do aspecto de distribuicao para o sistema Health Watcher. 3.2. Modelo de join point Um join point e um ponto bem denido no uxo de execucao de um programa. A Figura 6 mostra um exemplo de uxo execucao entre dois objetos e identica alguns join points no mesmo.

Figura 6: Join points de um uxo de execucao [Hilsdale and Kiczales, 2001].

O primeiro join point e a invocacao de um m todo do objeto A, o qual pode re e tornar com sucesso, ou levantar uma excecao. O pr ximo join point e a execucao deste o m todo, que por sua vez tamb m pode retornar com sucesso ou levantar uma excecao. Due e rante a execucao do m todo do objeto A e invocado um m todo do objeto B. A invocacao e e e execucao deste m todo s o join points, e da mesma forma que os do objeto A podem e a retornar com sucesso ou levantar uma excecao. 3.3. Pointcut Pointcuts s o formados pela composicao de join points, atrav s dos operadores a e (e), (ou), e (n o). Utilizando pointcuts podemos obter valores de argumentos de m todos, a e objetos em execicao, atributos e excecoes dos join points. Considere a denicao do aspecto de distribuicao para o sistema Helth Watcher. O trecho de c digo a seguir e a denicao de um pointcut que identica as invocacoes de o todos os m todos da classe fachada, com quaisquer tipo de retorno, nomes, ou par metros, e a 1 devido ao uso dos wildcards e .
pointcut facadeMethodsCall(): within(HttpServlet+) && call(* IFacade.*(..));
1

Este wildcard e utilizado para representar qualquer seq encia de par metros u a

( )(

4 14

0 10

Al m disso o pointcut restringe os join points aqueles os quais o c digo em e ` o execucao pertencer aos subtipos (devido ao uso do wildcard ) da classe . Ou seja, este pointcut, chamado identica as invocacoes de m todos feitas a classe fachada pela interface com o usu rio. Estas s o as chamadas e ` a a que dever o ser executadas remotamente. a Para denir pointcuts, identicando os join points a serem afetados, utilizamos construtores de AspectJ chamados designadores de pointcut (pointcut designators), como os apresentados a seguir. Assinatura Assinatura Assinatura Assinatura Padr oTipo a Padr oTipo a Padr oTipo, ... a Padr oTipo a
I I I I I I I I ! #  9 $ # 8  ! ! @'77%76 5    & C F ! # E # C  B  DG'@%@@D@A Y

Invocacao de m todo/construtor identicado por Assinatura e Execucao de m todo/construtor identicado por Assinatura e Acesso a atributo identicado por Assinatura Atribuicao de atributo identicado por Assinatura O objeto em execucao e inst ncia de PadraoTipo a O objeto de destino e inst ncia de PadraoTipo a Os argumentos s o inst ncias de PadraoTipo a a O c digo em execucao est denido em PadraoTipo o a

Onde Padr oTipo e uma construcao que pode denir um conjunto de tipos utia lizando wildcards, como e . O primeiro e um wildcard conhecido, pode ser usado sozinho para representar o conjunto de todos os tipos do sistema, ou com depois de caracteres, representando qualquer seq encia de caracteres. O ultimo deve ser utilizado junto u ao nome de um tipo para assim representar o conjunto de todos os seus subtipos. A lista completa de wildcards e pointcut designators pode ser encontrada no guia de programacao de AspectJ [Team, 2002]. 3.4. Advices Advices s o construcoes que denem c digo adicional que dever executar nos join points. a o a Considerando o aspecto de distribuicao vamos denir um advice que utiliza o pointcut denido na secao anterior. O advice dever se assegurar de que a inst ncia remota a a est disponvel antes de executar qualquer m todo na interface com usu rio. Desta forma a e a devemos utilizar um advice da seguinte forma.
before(): facadeMethodsCall() this.getRemoteInstance();
` # $ A # DG'X 5 3

Onde o m todo e obt m uma refer ncia para a inst ncia remota da e e a classe fachada, que e armazenada por um atributo do aspecto
# B   ! & c # ! # a ! @VGR bRG7@#

H   ! B # P SRDQ D# H  F S V%!  H ! U@# H ! # U@@& T

H &  $ T HU!# ! $  T H &  F %V%!

H    7D@B W

private IFacade remoteFacade; private synchronized void getRemoteInstance() if (healthWatcher == null) try remoteFacade = (IFacade) java.rmi.Naming.lookup("..."); catch (java.rmi.RemoteException rmiEx) ... catch (java.rmi.NotBoundException rmiEx) ... catch (java.net.MalformedURLException rmiEx) ...
` ` Y Y Y ` ` ` Y Y Y `

Ainda e necess rio redirecionar chamadas locais para a inst ncia remota da a a fachada. Para isso devemos denir um pointcut que recupere a inst ncia local da fachada a
pointcut redirectFacadeCall(IFacade facade): facadeMethodsCall() && target(facade);

com o designator , de modo a o qual comp e o pointcut o obter o objeto alvo das chamadas locais, ou seja a inst ncia local da fachada. Note que o a tem a fachada como par metro. Este pointcut e utilizado a pointcut no seguinte advice , que tamb m deve declarar um par metro do mesmo tipo do e a pointcut
Object around(IFacade facade) throws ... : redirectFacadeCall(facade) try return = proceed(this.remoteFacade);
Y ! @# $  !    & C F ! # E # C  B  7D@'G%GDDA Y    # C  B  d ! B # $  C # 7%DDD$ C  Q $ D7' C  Q $ D7b Y

catch (RemoteException rmiEx)

`

...

e que substitui a inst ncia local pela remota, ao mandar a computacao do join point a prosseguir utilizando a inst ncia remota, atrav s da invocacao do m todo a e e , que continua a executar o join point. Os par metro a serem passados no m todo a e s o a os mesmos do advice . Entretanto, devido a um aparente bug, em an lise pelo time de desenvolvimento a de AspectJ, este advice gera um c digo que leva a um erro de execucao. Desta forma o a solucao e a denicao de um advice para cada m todo da classe fachada. A seguir e mostramos um exemplo de denicao deste advice para o m todo que atualiza queixas no e sistema.
C # # B $ @D C # # B $ 7@DD

void around(Complaint complaint) throws ... : facadeMethodsCall() && args(complaint) && call(void update(Complaint)) try remoteFacade.update(complaint);
Y

catch (RemoteException rmiEx)

`

...

Onde s o identicadas invocacoes do m todo a e que recebe uma queixa como par metro, e atrav s do designator a e obt mse acesso ao argumento utilizado no e momento da chamada do m todo, o qual tamb m e um par metro do advice. Todavia, e e a esta abordagem nos obriga a adicionar um novo advice sempre que um m todo for adie cionado na classe fachada. Impacto similar ocorre no caso de alteracao de algum m todo e da fachada, onde seramos obrigados a alterar o advice correspondente, o que n o seria a necess rio com a abordagem anterior. a Os advices de AspectJ s o apresentados a seguir. a Executa quando o join point e alcancado, mas imediatamente antes da sua computacao Executa ap s a computacao com sucesso do join point o Executa ap s a computacao sem sucesso do join point o Executa ap s a computacao do join point, em qualquer situacao o Executa quando o join point e alcancado e tem total controle sobre a sua computacao
T # $ A # GX # !  C  @D7Q & T $ 

3.5. Static crosscutting Como mencionamos anteriormente, a linguagem AspectJ permite alterar a estrutura est tica de um programa atrav s da adicao de membros de classe, da alteracao a hiera e arquia de classes ou da substituicao de excecoes checadas por n o checadas. Nas secoes a seguintes apresentamos e exemplicamos estas situacoes. Introduction O mecanismo que adiciona membros a uma classe e chamado introduction. Em AspectJ n s podemos introduzir m todos concretos ou abstratos, construtores e atributos em uma o e classe. At o momento, denimos pointcut e advices que afetam apenas as classes de e interface com o usu rio. O seguinte trecho de c digo introduz na classe fachada um a o m todo e , respons vel por exportar e nomear, utilizando a API de RMI, uma inst ncia a a da classe fachada tornando-a assim disponvel para responder a invocacoes remotas.
   f''

 f D%g% $ F ! $ # ! A W    $ Q ! # $ $ # ! A fV%@De%

C  Q $ 7

$ # ! A %

public static void HealthWatcherFacade.main(String[] args) try HealthWatcherFacade facade = HealthWatcherFacade.getInstance(); UnicastRemoteObject.exportObject(facade); java.rmi.Naming.rebind("/HealthWatcher"); catch (RemoteException rmiEx) ... catch (MalformedURLException rmiEx) catch(Exception ex) ...
Y ` Y ` Y ` Y `

...
Y p

A seguir apresentamos as construcoes do tipo introduction de AspectJ.

h iI

Modicadores Tipo Padr oTipo Id Formais a

4 H 4 ! B  $ ! & X RG

Corpo
H

Outras construcoes Devido a uma exig ncia da API de RMI devemos denir uma interface para a classe e fachada adicionando a excecao especca da API ( ) nas clausulas dos m todos. Esta interface e um tipo auxiliar do aspecto de distribuicao. Al m e e da denicao da interface remota
Y

public interface IFacade extends java.rmi.Remote

public void update(Complaint complaint) throws TransactionException, RepositoryException, ObjectNotFoundException, ObjectNotValidException, RemoteException; ...
`

temos de alterar a hierarquia da classe fachada para que a mesma passe a implementar a interface remota atrav s da seguinte construcao e
declare parents: HealthWatcherFacade implements IFacade;

Outra alteracao na hierarquia do programa e necess ria. Os tipos dos obje a tos que s o recebidos e retornados pela classe fachada devem implementar a interface a de modo a permitir a sua serializacao no canal de comunicacao entre a interface com o usu rio e a fachada. a
#  X  x     $ # 84 4  9 @DDD@7wDv'@ u

  !  # B P t # ! # RDG@'bRba

h sI

Modicadores Padr oTipo new Formais a

H 4

Corpo

q rI

Modicadores Tipo Padr oTipo Id Formais a

Dene um m todo nos e tipos em Padr oTipo a Dene um m todo abstrato e nos tipos em Padr oTipo a Dene um construtor nos tipos em Padr oTipo a

&

$ F D%!

declare parents: Complaint || Person implements Serializable;

A seguir apresentamos as outras construcoes em AspectJ que alteram a estrutura est tica de um programa. a Declara que os tipos em Padr oTipo herdam dos a tipos em ListaTipos Declara que os tipos em Padr oTipo implementam a os tipos em ListaTipos Declara que qualquer excecao de um tipo em Padr oTipo que for a lancada em qualquer join point identicado por Pointcut ser encaa psulada em uma excecao n o checada a
q

Maiores informacoes sobre crosscutting concerns podem ser encontradas no guia de programacao de AspectJ [Team, 2002]. 3.6. Aspectos reus veis a AspectJ permite a denicao de aspectos abstratos, os quais devem ser estendidos provendo a implementacao do componente abstrato. Os componentes abstratos podem ser m todos, e como em uma classe Java, e pointcuts, os quais devem ser denidos em um aspecto concerto, permitindo o reuso do comportamento dos aspectos abstratos. Vamos considerar um aspecto de tratamento de excecoes. Podemos denir um as pecto geral que dene um pointcut abstrato, respons vel por denir os pontos em que a as excecoes s o lancadas e um m todo abstrato respons vel por aplicar o tratamento a e a que utiliza necess rio. Dessa forma denimos o aspecto a o pointcut abstrato e o m todo abstrato em um advice que captura a excecao lancada e ap s a execucao dos join points e chama o m todo abstrato que deve prover o tratamento o e adequado para a excecao.
! B #  & 7T    C   6   !  # B P fD'DGbRG't

protected abstract void exceptionHandling(Throwable ex);

`

public abstract aspect ExceptionHandlingAspect public abstract pointcut exceptionJoinPoints(); after() throwing (Throwable ex): exceptionJoinPoints() this.exceptionHandling(ex);
Y `

Padr oTipo Pointcut a

& !  # #   @'bD

Padr oTipo a

ListaTipos

& C  # ! P 'DG7#

Padr oTipo a

ListaTipos

& !  # $   # $   B # GD%y%C & !  # $   # $   B # GD%y%C ! A & # $   B # %@%%C

A partir deste aspecto podem ser criados v rios aspectos especializados para a prover tratamentos de excecao para diferentes interfaces com o usu rio, como o as a pecto a seguir que prov tratamentos de excecao para servlets Java. Note que apenas e e fornecida, logo o aspecto ainda e a implementacao do m todo e abstrato.
public abstract aspect ServletsExceptionHandlingAspect extends ExceptionHandlingAspect protected abstract void exceptionHandling(Throwable ex) // handling exceptions in servlets Java
Y Y ` ` T    C   6   !  # B P fDD@VG@'%# ! B #  &

Em seguida s o denidos aspectos mais especializados para serem utilizados por a outros aspectos, como o de distribuicao.
public aspect DistributionExceptionHandlingAspect extends ServletsExceptionHandlingAspect public pointcut exceptionJoinPoints(): DistributionAspect.facadeMethodsCall();
Y `

o qual identica como join point passveis de tratamento de excecao os mesmos alterados pelo aspecto de distribuicao. Note o reuso do pointcut do aspecto de distribuicao ( ). Observe este exemplo de crosscutting concerns, onde distribuicao e o tratamento de suas excecoes s o denidos como preocupacoes em a separado.
   & C F ! # E # C  B  7G'GR%@G@DA   ! Q  $ ! &  bR7X %V

Figura 7: Diagrama de classes com aspectos de tratamento de excecoes.

Com esta abordagem teramos a hierarquia de aspectos mostrada no diagrama da

Figura 7, onde seriam denidos v rios aspectos de tratamento de excecao para tratar as a excecoes adicionadas por outros aspectos. Maiores informacoes sobre aspectos de distribuicao e tratamento de excecoes po dem ser encontradas em outro trabalho [Soares et al., 2002]. 3.7. Um exemplo simples O seguinte c digo em AspectJ dene um aspecto respons vel por imprimir na sada o a padr o todos os comandos sql [Elmasri and Navathe, 1994] antes dos mesmos serem exa ecutados no banco de dados. A id ia e permitir ao programador visualizar a string resule tante, o que normalmente resulta de uma s rie de concatenacoes de strings, muitas vezes e difceis de corrigir.
aspect DatabaseDebugging private interface TypesDebugged
Y Y

declare parents : DataCollection1 || DataCollection2 || ... DataCollectionN implements TypesDebugged; pointcut queryExecution(String sql): call(* Statement.*(String)) && this(TypesDebugged) && args(sql);
Y

before(String sql): queryExecution(sql) System.out.println(sql);

` `

onde declaramos uma interface que e utilizada para marcar as classes que ser o depuradas, a e fazemos estas classes implementarem a interface. Em seguida e denimos um pointcut (da API que identica as invocacoes de todos os m todos de objetos do tipo e de JDBC [White and Hapner, 1999]), respons vel pela execucao dos comandos sql, que a recebam como par metro um string e retornem qualquer tipo. O pointcut ainda obt m a a e string utilizada como argumento nessas invocacoes de m todos. Em seguida denimos e um advice que imprime a string (sql) que ser executada no banco de dados. Isto deve ser a feito antes da sua execucao de modo que a mesma seja visualizada antes de ser submetida ao banco de dados.

4. AOP e padr es de projeto o

Parte da funcionalidade da programacao orientada a aspectos pode ser implementada por padr es de projetos [Gamma et al., 1994], como a separacao de c digo com funcoes eso o peccas. Por exemplo, podemos utilizar o padr o Adapter [Gamma et al., 1994] para a adicionar um comportamento a um m todo de uma classe. e

!  # # !  ! Gb@8

Figura 8: Adaptadores implementando separacao de preocupacoes.

A classe cont m o c digo funcional do sistema, ou seja, o c digo que e o o implementa os requisitos funcionais do sistema. Considere a necessidade de implementar . Para isso um de um aspecto para afetar as execucoes do m todo da classe e adaptador, que possui uma refer ncia para uma inst ncia de e a , deve implementar a interface adicionando o comportamento desejado e delegando, se for o caso, a ` sua inst ncia de a a execucao da parte funcional. Observe que esta abordagem e an loga a do advice a , onde o mesmo det m e controle total sobre o uxo de execucao do join point, assim como o m todo do adapta e dor det m controle total sobre o uxo de execucao do m todo da classe e e . Por m, esta abordagem de padr es de projetos levaria a uma duplicacao de c digo, e o o uma vez que para cada classe interceptada seria necess rio um adaptador, mesmo que para a a implementacao de um mesmo aspecto, como depuracao, por exemplo. Em AspectJ basta denir no pointcut quais pontos devem ser afetados pelo aspecto. Outra desvantagem e que caso o m todo de e invoque outro m todo da classe e que seria afetado pelo aspecto essa invocacao n o seria capturada pelo adaptador. J em AspectJ a a essa invocacao seria capturada. E por m, no caso de uma mudanca da implementacao do aspecto, a alteracao de a que componente a classe esta ligada seria invasiva, ou seja, feita diretamente no c digo fonte. Com AspectJ esta mudanca seria autom tica, o a bastando recompor (weave) o sistema utilizando o novo aspecto.
! @# T $   # B $ Q @'D8 ! @# T $  % ! @# T $   C  Q $ D ! # T $   ! @# T $   ! # ! @# T $   $   ! @# T $   c

5. Conclus es o
A Programacao orientada a aspectos tr s v rios benefcios devido a possibilidade de a a ` tornar programas mais modulares. O objetivo da t cnica e separar preocupacoes ortogoe nais (crosscutting concerns) de modo a evitar o entrelacamento de c digo com diferentes o prop sitos e o espalhamento de c digo com prop sito especco em v rias partes do siso o o a tema. Desta forma obtemos ganhos com manutencao e evolucao do sistema al m de e favorecer o reuso de suas partes.

# B $ Q 'DD8

Considere o diagrama de classes da Figura 8 onde a classe de uma interface .

! @# T $   c T

usa o servico

A linguagem AspectJ e uma extens o orientada a aspectos da linguagem Java, a permitindo assim a programacao orientada a aspectos em Java. Entre as desvantagens da linguagem est o a necessidade de se familiarizar com as novas construcoes de AspectJ e a a pouca maturidade do ambiente de desenvolvimento, resultando em um ambiente ainda n o muito est vel. Entretanto, o ambiente teve uma evolucao consider vel, estando hoje a a a bem mais est vel que nas vers es anteriores. Al m disso, o time de suporte est pronto a o e a a tirar eventuais d vidas e at mesmo sugerir solucoes para problemas, atrav s de uma u e e lista de discuss o. Pontos a melhorar no ambiente de desenvolvimento s o o tempo de a a compilacao (weaving) e o tamanho do bytecode gerado. Outra fraqueza de AspectJ e a sua poltica de tratamento de excecoes. O advice e o unico tipo de advice que suporta a declaracao de uma cl usula a . Nos demais n o e possvel lancar uma excecao checada que j n o seja tratada pelos m todos a a a e afetados. A solucao dada e utilizar excecoes soft, ou seja, encapsular excecoes checadas em uma excecao n o checada (excecoes do tipo runtime). Como este tipo de excecao n o a a obriga o programador a prover o tratamento para a mesma, o programa pode gerar erros inesperados, caso se esqueca de prover o tratamento adequado. AspectJ prov construtores muito poderosos, que devem ser utilizados com e precaucao, uma vez que o uso de wildcards pode afetadar v rias partes de um programa, a inclusive partes indesejadas. Para aumentar ainda mais a expressividade da linguagem, sugerimos [Soares et al., 2002] a criacao de uma funcionalidade que permita introduzir de um m todo. Esta funcionalidade seria mais um tipo e uma excecao na cl usula a de static crosscutting. Desta forma poderamos introduzir excecoes checadas, as quais devem, obrigatoriamente, ser tratadas, n o deixando a cargo do programador assumir o a compromisso de tratar excecoes do tipo runtime. A denicao de um pointcut em AspectJ requer a identicacao de pontos es peccos de um programa. Como estes pontos s o identicados atrav s de nomes e tipos a e de m todos, par metros e etc., os aspectos cam dependentes do sistema, ou da nomene a clatura utilizada por ele, dicultando as chances de reuso. Por exemplo, para identicar todas as chamadas de m todos que inserem dados no sistema poderamos identicar as e invocacoes a m todos com nome e , o que obriga a denicao de m todos que in e serem dados sempre com este nome, e n o a ou . Isto mostra a necessidade de uso de um padr o de nomenclatura, o que tamb m benecia a legibilidade do sistema. a e Outro suporte ao desenvolvimento por parte de AspectJ s o extens es para IDEs a o (ferramentas CASE de programacao) bem disseminadas, como Borland JBuilder. Com isto e possvel utilizar estes ambientes de programacao para desenvolver sistemas com AspectJ. Estas extens es tamb m permitem visualizar que partes do c digo s o afetadas o e o a pelos aspectos. Atualmente est o sendo desenvolvidas extens es para outras IDEs. a o A maior vantagem de AspectJ e a possibilidade de implementar funcionalidades em separado da parte funcional do sistema, e automaticamente inseri ou remover tais aspectos do mesmo. Para remover um aspecto do sistema basta gerar uma nova vers o do a sistema sem o aspecto que se quer remover. Al m disso, para alterar um aspecto, como e mudar o protocolo de distribuicao de um sistema, basta implementar outro aspecto de distribuicao, e passar a us lo no processo de recomposicao. Com a separacao, a legi a bilidade do c digo funcional e favorecida, uma vez que n o h c digos com diferentes o a a o
C C 7 $ # ! & 7 T # D$ ! $ # &  %@Vf & W $ F D%! & W $ F 'D%! C  Q $ D

prop sitos entrelacados entre si e com c digo funcional. Isto tamb m permite a validacao o o e precoce dos requisitos funcionais, antes mesmo da implementacao de aspectos como per sist ncia, distribuicao, e controle de concorr ncia, tendo assim um desenvolvimento proe e gressivo [Soares and Borba, 2002] do sistema.

Refer ncias e
Booch, G. (1994). ObjectOriented Analysis and Design with Applications. jamin/Cummings, second edition. Ben-

Booch, G., Jacobson, I., and Rumbaugh, J. (1999). Unied Modeling Language Users Guide. AddisonWesley. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996). A System of Patterns: PatternOriented Software Architecture. John Wiley & Sons. Elmasri, R. and Navathe, S. (1994). Fundamentals of Database Systems. Addison Wesley, second edition. Elrad, T., Filman, R. E., and Bader, A. (2001). Aspectoriented programming. Communications of the ACM, 44(10):2932. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design Patterns: Elements of Reusable ObjectOriented Software. AddisonWesley. Gosling, J., Joy, B., Steele, G., and Bracha, G. (2000). The Java Language Specication. AddisonWesley, second edition. Hilsdale, E. and Kiczales, G. (2001). Aspectoriented programming with AspectJ. In OOPSLA01, Tutorial, Tampa FL. Hunter, J. and Crawford, W. (1998). Java Servlet Programming. OReilly & Associates, Inc., rst edition. J., L. K., I., S.-L., and et al (1994). Adaptive ObjectOriented Programming Using GraphBased Customization. Communications of the ACM, 37(5):94101. Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W. G. (2001). Getting Started with AspectJ. Communications of the ACM, 44(10):5965. Laddad, R. (2002). I want my aop!, part 1. JavaWorld. Avaliable at http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html. Meyer, B. (1997). ObjectOriented Software Construction. PrenticeHall, second edition. Microsystems, S. (2001). Java Remote Method Invocation (RMI). Disponvel em http:// java.sun.com/products/jdk/1.2/docs/guide/rmi. Murphy, G. C., Walker, R. J., Baniassad, E. L., Robillard, M. P., Lai, A., and Kersten, M. A. (2001). Does aspectoriented programming work? Communications of the ACM, 44(10):7577. Orfali, R. and Harkey, D. (1998). Client/Server Programming with Java and CORBA. Wiley.

Ossher, H., Kaplan, M., Katz, A., Harrison, W., and Kruskal, V. (1996). Specifying sujectoriented composition. TAPOS, 2(3):179202. Special Issue on Subjectivity in OO Systems. Ossher, H. and Tarr, P. (1999). Using subjectoriented programming to overcome common problems in objectoriented software development/evolution. In International Conference on Software Engineering, ICSE99, pages 698688. ACM. Soares, S. and Borba, P. (2002). Progressive implementation with aspectoriented programming. In Verlag, S., editor, The 12th Workshop for PhD Students in ObjectOriented Systems, Malaga, Spain. To appear. Soares, S., Laureano, E., and Borba, P. (2002). Implementing distribution and persistence aspects with AspectJ. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA02), Seattle, WA, USA. ACM Press. To appear. Team, A. (2002). The AspectJ Programming Guide. Disponvel em http://aspectj.org. White, S. and Hapner, M. (1999). JDBC 2.1 API. Version 1.1. Sun Microsystems.