Este documento apresenta os conceitos e benefícios da Orientação a Aspectos no desenvolvimento de software. Aborda as limitações da Programação Orientada a Objetos para modularizar interesses transversais e como a Orientação a Aspectos permite uma separação mais adequada desses interesses através da nova abstração de "aspecto". Apresenta também os benefícios da Orientação a Aspectos, como melhoria da compreensão, manutenção e reutilização do código.

1. Desenvolvimento de Software
Orientado a Aspectos – (DSOA)
Alessandro Ferreira Leite – Sapiens IT Tecnologia

2. Apresentação
v Bacharelando em Ciência da Computação
v Analista de Sistemas e Projetista de software - Sapiens IT
Tecnologia da Informação.
v Trabalha com as plataformas Delphi™ , Java™ e .Net™ .
v Com desenvolvimento, análise e proposições de arquiteturas de
software.
v Experiência em desenvolvimento de software, utilizando o
paradigma da POA. SCPJ e SCWCD 1.4

3. Objetivos
1. Introdução à Orientação a Aspectos (OA)
1. Motivações
2. Objetivos
3. Histórico e evoluções
4. Benefícios
5. Mitos e verdades
6. Linguagens AOPs
2. Desenvolvimento de software orientado a aspectos - (DSOA)
3. Aplicações
4. Referências
5. Espaço aberto a perguntas

4. Desenvolvimento de Software Orientado a Aspecto (DSOA)
v Novo paradigma de desenvolvimento de software, que
provê avançada separação de interesses (crosscutting
concerns).
ü Modularização de Interesses transversais.
v Complementar os atuais paradigmas de
desenvolvimento.
Ex.: Orientação a objetos (OO), Programação estruturada (PE)

5. Motivações/Necessidades
v As aplicações estão ampliando os limites das técnicas
de programação atuais, de modo que certas
características de um sistema afetam seu
comportamento de tal forma que as técnicas atuais não
conseguem capturar essas propriedades de forma
satisfatória.
v Projetar sistemas que possibilitem acomodar novas
necessidades sem comprometer a qualidade.
v Lidar com as complexidades e interesses dos
stakeholders sem deixar que o código das classes, ou
procedimentos se tornem “spaghetti code”, o que
prejudica o projeto (design).

6. Estratégicas
v Quebrar os problemas em partes menores – dividir
para conquistar.
v Suporte das linguagens para representar elementos
do sistema como:
ü Modularização - procedimentos, funções,
bibliotecas.
ü Abstração dos dados Preceitos da
ü Generalização Orientação a
ü Encapsulamento Objetos

7. Estratégica – Desenvolvimento software
v Os interesses são modularizados através de diferentes
abstrações providas pelas linguagens, métodos e ferramentas.
* [ATKINSON, Colin; KÜHNE, Thomas. Aspect-Oriented Development with Stratified Frameworks. IEEE Software, 20:81-89,2003, pp. 84]

8. Programação Orientada a Objetos - OOP
v Sem dúvida proporcionou avanços significativos ao
desenvolvimento de software.
v Baseia-se na decomposição funcional dos problemas,
possuindo como unidade funcional classe/objeto.
v Composição, Herança
v Objetos capturam os dados, comportamentos, estados
e as estruturas internas.
v Suas estruturas são baseadas em apenas uma
dimensão.

9. Programação Orientada a Objetos - OOP
v Possibilita modularizar, de forma satisfatória, alguns
tipos de interesses.
v Normalmente interesses de negócio.
Ex. Conta, Cliente, Extrato, etc.
v Porém, mostrou-se ineficiente na decomposição de
outros interesses (concerns), que atravessam por todo
o sistema.
v Interesses Transversais (Crosscutting Concerns)

10. Exemplo – Crosscutting concerns
import java.util.logging.Level;
import java.util.logging.Logger;
public class Conta{
private static Logger logger = Logger.getLogger("Conta");
private double saldo;
private int numeroConta;
public Conta(int numero){ this.numeroConta = numero;}
public void creditar(double valor){
logger.log(Level.INFO, “Creditar valor:“ + valor);
setSaldo(getSaldo() + valor);
}
public void sacar(double valor) throws SaldoInsuficienteException{
logger.log(Level.INFO, "início método sacar");
double saldo = getSaldo();
if (saldo < valor){
logger.log(Level.WARNING, "Conta: " + numeroConta + " Saldo insuficiente");
throw new SaldoInsuficienteException("Valor não disponível para saque");
}
setSaldo(saldo - valor);
logger.log(Level.INFO, "Operação de saque efetuado!");
}
public double getSaldo(){
logger.log(Level.INFO, “Retornar valor saldo“);
return this.saldo;
}
public void setSaldo(double valor){
logger.log(Level.INFO, “Saldor:“);
this.saldo = valor;
};
} Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp.
51]

11. Limitações da Orientação a Objetos
v Interesse de Logging do Jakarta Tomcat
(c) Copyright 1998-2002 Xerox Corporation

12. Limitações da Orientação a Objetos
v XML Parsing
(c) Copyright 1998-2002 Xerox Corporation

13. Limitações da Orientação a Objetos
v Espalhamento de código (Scattering)
v Entrelaçamento (Tangling)
v A implementação de tratamento de exceção, por
exemplo, é inseparável do código onde a exceção
poderá ser gerada, impedindo o agrupamento da lógica
em uma unidade.

14. Limitações da Orientação a Objetos
v Conseqüências
v Prejudica o reúso
v Dificulta o encapsulamento
v Compromete a legibilidade
v Dificuldade de compreensão
v Dificuldade de manutenção
v Baixa produtividade
v Baixa qualidade interna

15. Separação de interesses – Separation Of Concerns (SOC)
v Teoria que investiga como separar as diversas
preocupações de um sistema.
v Cada preocupação deve ser tratada separadamente,
até que possa ser compreendida e implementada.
v Cada unidade deve lidar com apenas um interesse.

16. Separação de interesses – Separation Of Concerns (SOC)
v Interesse - qualquer requisito ou consideração que
deve ser atendido para satisfazer o objetivo de um
sistema, mas que não pertencem ao domínio do
negócio, modelado por algumas metodologias. Ex.
OOP.
v Normalmente, Requisitos não funcionais.
v Um software é a realização de um conjunto de
interesses.

17. Separação de interesses – Separation Of Concerns (SOC)
v Exemplos de interesses
v O sistema deve permitir o cadastro de aluno.
v As operações devem ser atômicas.
v Todas as operações do sistema devem ser registradas.
v Deve permitir aos alunos matricularem nas matérias que
estiverem habilitados.
v Deve permitir o acesso as funcionalidades do sistema, de
acordo com o perfil do usuário.

18. Separação de interesses – Separation Of Concerns (SOC)
v Os interesses podem ser classificados em:
v Interesses principais – “core concerns” – capturam
as funcionalidades centrais de um módulo.
v Interesses ortogonais – “crosscutting concerns” –
capturam funcionalidades periféricas do sistema.
v Alguns, devido a sua natureza, não podem ser
componentizados.

19. Separação de interesses – Separation Of Concerns (SOC)
v Exemplo:
v Autenticação
v Logging
v Resource pooling
v Performance,
v Gerenciamento de dados
v Persistência
v Segurança
v Controle de transação
v Checagem de erros
v .....

20. Separação de interesses – Separation of Concerns (SOC)
v Separação de interesses promove:
v Código de melhor qualidade
v Maior modularidade
v Facilita atribuição de responsabilidades entre módulos
v Promove o reuso
v Facilita a evolução do software
v Viabiliza análise do problema dentro de domínios
específicos

21. Implementação dos interesses
Regra de negócio
Interesses
(concerns)
Persistência
Segurança
Implementações
Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 8]

22. Estratégicas de implementação
Persistência
Segurança
Persistência
Regra de negócio
Regra de negócio
N-dimensional One dimensional
Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 9,10]

23. Crosscutting concerns
v É um interesse em que a sua implementação interfere
no comportamentos, estrutura de muitas outras
classes, módulos de um sistema.

24. Entrelaçamento de código - Tangled code
v Linhas de códigos que são inseridas em um módulo que tratam de
interesses diferentes.
Logging
Regras de negócio
Persistência
Segurança
Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 16]

25. Entrelaçamento de código - Tangled code
public class AlunoBO extends ...{
public boolean salvar (Aluno aluno, ... ) throws ...{
if (hasAcess(usuario)){
// regras de negócios inerentes ao aluno
logger.logWritter();
try{
return alunoDAO.salvar(aluno);
}catch(PersistenciaException exception){
(...)
}
class AlunoDAO extends....{
public boolean salvar(...){
//... logging
//... Transação
//... Pooling
//... Persitência
//... Gerenciamento de Exceção

26. Code Scattering -
v É o processo de repetição de um determinado trecho de código nos
diversos módulos, classes do sistema.
public class ClasseNegocio{
private static Logger logger =
Logger.getLogger("Conta");
public void metodo1(....){
logger.log(Level.INFO, “metodo1(...):“);
}
public void negocio(...){
logger.log(Level.INFO, “negocio(...):“);
}
Code Scattering

27. Abordagens para Separação de interesses [3]
v Padrões de projeto (design patterns):
v Mixin: invocar interfaces e não classes.
v Comportamentais: Visitor, Observer, Template Method
v Inversão de Controle (IoC) = Injeção de Dependência
v Frameworks com suporte a interesses pré-definidos:
v Servidores de aplicação (J2EE, .NET)

28. Abordagens para Separação de interesses [3]
v Meta-programação
v Reflexividade, introspecção
v Higher-order programming
v Hyperspaces
v Subject-Oriented Programming (SOP)
v Intentional Programming
v Reflective programming
v Compositional Filtering
v Meta-programming
v Adaptive programming
v Orientação a Aspectos (OA)

29. Orientação a Aspectos (OA) – Aspect-Oriented Programming
v Paradigma de programação que propõe um novo tipo
de abstração – denominado aspecto – que permite a
descrição modular de propriedades que, em geral, se
encontram espalhadas e misturadas em vários pontos
de um sistema de software . [1,2]
v David Parnas, 1972 – modularização.
v Cristina Lopes, Gregor Kiczales – Palo Alto Research
Center (PARC) – utilização do termo AOP em 1996.
v Entretanto, JACOBSON, Ivar. Language Support for
Changeable Large Real Time Systems. Ericsson
Telecom. OOPSLA'86 Proceedings.

30. Orientação a Aspectos (AO)
v A idéia da orientação a aspectos é possibilitar ao desenvolvedor a
utilização de um novo mecanismo de abstração para separar os
componentes dos aspectos, os componentes entre si e os
aspectos entre si, utilizando mecanismos que permitam a
abstração e composição destas, produzindo o sistema desejado.
v Divide os interesses em dois grupos
v Componentes – propriedades do sistema que podem ser
encapsuladas em um procedimento generalizado (objeto,
método, procedimento, API). Os componentes tendem a ser
unidades da decomposição funcional.
v Aspectos – não são normalmente unidades de decomposição
funcional, entretanto, propriedades que envolvem diversas
unidades do sistema.

31. Orientação a Aspectos (AO)
v Separação avançada de interesses
v Modularização dos Interesses Transversais
v Nova abstração: aspecto
v Novas formas de composição e decomposição

32. Benefícios
v Modularização adequada de interesses transversais
v Melhora a compreensão
v Facilidade de manutenção
v Facilidade de reutilização

33. Mitos e verdades
v O fluxo de um sistema, baseado que utiliza AOP, é
difícil de ser seguido, observado.
v AOP não soluciona nenhum novo problema.
v AOP promove projeto (design) de baixa qualidade.
v AOP é legal, mas nada que, se consiga utilizando
abstratas interfaces com OOP.
v AOP quebra encapsulamento.
v AOP irá substituir OOP.

34. Mitos e verdades
v Aspectos são sempre infra-estruturas auxiliares de uma
aplicação.
v Se utilizar OOP adequadamente, não é necessário
utilizar AOP.
v AOP deveria ser utilizada somente quando se está
modificando uma aplicação existente, não na fase
inicial de projeto e implementação.
v “Think of AOP as complementing, not competing with, OOP.
AOP can supplement OOP where it is weak”. [JONHSON, Ralph.
J2EE Without EJB. John Wiley, 2004]

35. Mitos e verdades
v Código AOP é difícil compreensão.
v AOP é uma técnica de pré-processamento (ou AOP é
uma técnica compilada ou Load-time).
v AOP é somente mais um Framework/API/biblioteca.
v “Os problemas com as linguagens de programação
não é se elas são capazes de realizar uma tarefa.
Mas sim, quão fácil elas tornam as coisas fácil para
vocês”. [SOARES, Marcos. Tratamento de tarefas Crosscuting com POA. Developer’s Magazine, Ano 7, n. 73, setembro
2002, pp. 34,36]
[ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 16]
[KICZALES, Gregor. What is aspect-oriented programming? How is it used? The basics of AOP are worth repeating, as are the
realities that counter persistent AOP misconceptions. Software Development. pp. 56,57]

36. Linguagens AOPs
v AspectJ – http://eclipse.org/aspectj/
v HyperJ – http://www.alphaworks.ibm.com/tech/hyperj
v AspectC++ - http://www.aspectc.org
v AspectWerkz - http://aspectwerkz.codehaus.org
v JBoss AOP - http://www.jboss.org/products/aop
v AspectC# -
http://www.castleproject.org/index.php/AspectSharp
* Última visita em, 26 de outubro de 2005

37. Desenvolvimento de Software Orientado a Aspectos (DSOA)
v AOP – Aspect-Oriented Programming
v AOM – Aspect-Oriented Modeling
v AORE – Aspect-Oriented Requirements Engineering
v AORA – Aspect-Oriented Requirements Analysis
v Aspectos Arquiteturais

38. AspectJ
v Linguagem de programação orientada a aspectos.
v Extensão da linguagem Java.
v É a mais conhecida e que mais influencia as demais
linguagens de aspectos disponíveis atualmente.
v Versão estável 1.2.1 (Novembro, 2004)
v Consiste:
v Especificação – linguagem
v Implementação – ferramentas - IDE, compiladores,
debugging.

39. AspectJ
v Suporte a dois tipos de implementacão de requisitos
transversais:
v Transversalidade dinâmica - permite definir implementacão
adicional em pontos bem definidos do programa.
v Transversalidade estática – afeta a estrutura estática das
classes e interfaces de um programa Java.

40. AspectJ
v Integra-se com as principais ferramentas de
desenvolvimento.
v Eclipse – http://www.eclipse.org/ajdt
v JBuilder – http://aspectj4jbuildr.sourceforge.net
v Netbeans – http://aspectj4netbean.sourceforge.net
v Emacs – http://aspectj4emacs.sourceforge.net
v JDeveloper - https://jdeveloperaop.dev.java.net/
* Última visita em, 26 de outubro de 2005

41. Orientação a Aspectos (AO)
v Além dos conceitos relacionados a Orientação a Objetos
(método, classe, atributos,interfaces), outros preceitos como:
1. Aspectos - Aspect
2. Ponto de Junção - Join Point
3. Comportamento Tranversal | Adendo - Advice
4. Conjunto de pontos de junção - Pointcut
5. Declaração intertipos – Inter-type declaration “Introduction”
6. Combinação – Weaving
• Traduções definidas no WASP 2004. 1° Workshop Brasileiro de Desenvolvimento de Software Orientado a Aspectos.
Disponíveis em http://twiki.im.ufba.br/bin/view/AOSDbr/WebHome

42. Aspecto – Aspect
v Unidade modular de implementação de requisitos
transversais. Aspectos são definidos por declarações
de aspectos, que são similares a declarações de
classes em Java.
v Sintaxe
[access modified] aspect <AspectName>
[extends class-or-aspect-name]
[implements interface-list]
[association-especifier>(Perclause)] {
body
}
v Estático – estrutura
v Dinâmico – fluxo de execução

43. Aspecto – Aspect
v Aspectos podem:
v Herdar de classes
v Implementar interfaces (com exceção de java.io.Serializable e
java.lang.Cloneable)
v Estender outros aspectos
v Só pode herdar de aspectos abstratos
v Pode definir pointcuts e métodos abstratos
v Pode definir atributos, classes, e outros aspectos
v Pode utilizar os modificadores de acessos

44. Aspecto - Aspect
v SubAspectos:
v Herdam atributos, métodos, pointcuts e advices
v Podem redefinir seu modelo de instanciação
v Pode ser definidos dentro de classes, interfaces e
outros aspectos.
v São Singleton por padrão

45. Aspecto - Aspect
v Aspectos não é classe, pois:
v Pode ser definido utilizando o modificador
“privileged”
v Não pode ser instanciado
v Não pode herdar de aspecto concreto

46. Aspecto - Exemplo
class Classe{
public static aspect NestedAspect {}
}
privileged aspect AbstractLogging implements Logger {
public abstract pointcut logPoints();
public abstract Logger getLogger();
before(): logPoints() {
getLogger().log(Level.INFO, “Before: ” + thisJoinPoint);
}
public static aspect NestedAspect {};
public class MemberClass { (...) };
}

47. Aspecto – Comportamento

48. Ponto de junção - Join Point
v Qualquer ponto,local, do programa que possa ser
interceptado e onde o programa de aspectos deverá
ser inserido durante o processo de composição.
v Chamada e execução de métodos
v Chamada de construtores
v Leitura e modificação de atributos de classe
v Tratamento de exceção
v Inicialização de classes

49. Ponto de junção - Join Points
public class Conta{
private double saldo;
(...)
public Conta(int numero){
this.numero = numero;
}
protected void setSaldo(double valor){
this.saldo = valor;
}
}

50. Conjunto de pontos de junção - PointCuts
v Construção usada para identificar pontos de
junção que se deseja interceptar em um
programa
v Sintaxe:
[acess modifier] pointcut pointcut-name([args]): pointcut-definition
private pointcut callConstruct (): call ( Conta+.new(..) );
Modificador Nome do pointcut Tipo
de Assinatura
acesso Palavra reservada keyword

51. Conjunto de pontos de junção - PointCuts
v Podem ser:
v Anônimos
v Nomeados
v Definidos dentro de classes, interfaces e aspectos
v Utilizar os modificadores de acesso:
v Privado - private
v Protegido - protected
v Default - ausência de modificador – visibilidade de pacote
v Publico - public

52. Conjunto de pontos de junção - PointCuts
v Podem ser combinados, utilizando os operadores:
v && (e)
v || (ou)
v ! (não)
v Utilizar wildcards
v * - qualquer número de caracteres exceto período.
v + - Tipo e os seus subtipos.
v .. (dois pontos) - qualquer número de caracteres
incluindo períodos.

53. Conjunto de pontos de junção - PointCuts
Todos os tipos com exceção do tipo
! java.util.Vector
java.util.Vector
Os tipos java.util.Vector ou
Vector || Hastable
java.util.Hashtable
Todos os tipo do pacote javax, ou os
javax..*Model || seus subpacotes diretos e indiretos
javax.swing.text.Document que terminem com o nome Model ou
o tipo javax.swing.text.Document
java.util.RandomAccess+ && Todos os tipos que implementem as
java.util.List+ interfaces RandomAcess e List
Todos os métodos da classe, Conta,
* Conta+.*(..)
incluindo o(s) da(s) subclasses(s)

54. Conjunto de pontos de junção - exemplo
public aspect AspectConta {
pointcut callConstruct (): call(Conta+.new(..));
pointcut executionConstruct(): execution (Conta
+.new());
pointcut getSaldo():get(double Conta.saldo);
};

55. Comportamento Tranversal - Advice
v Instruções, ou conjunto de instruções, que são
executadas após a identificação de um conjunto de
junção - pointcuts.
before(): logPoints() {
getLogger().log(Level.INFO, “Before: ” + thisJoinPoint);
}

56. Comportamento Tranversal - Advice
v Before - executado antes que a ação associada ao ponto
de junção seja executada.
v After - executado depois que a ação associada ao ponto
de junção for executada
v after returning
v after throwing
v Around - quando o ponto de junção é atingido, o advice
toma o controle da execução e decide quando e se a ação
associada ao ponto de junção deve prosseguir

57. Comportamento Tranversal - Advice
v After returning – é utilizado para interceptar um método após a
sua completa execução, desde que, não ocorra nenhuma
exceção.
v Sintaxe:
v after() returning <ReturningType returnObject>
Exemplo
public aspect AspectConta {
pointcut sacar(): call (boolean Conta+.sacar(..));
after() returning (boolean valor) : sacar(){
System.out.println("Saldo efetuado!“ + valor);
}
}

58. Comportamento Tranversal - Advice
v After Throwable – utilizado para interceptar um
método que lançou uma exceção.
v Sintaxe
after() throwing : (<ExceptionType object>)
v Exemplo
after() throwing(SaldoInsuficienteException ex) : sacar(){
System.out.println("Saque não efetuado.");
}

59. Comportamento Tranversal - Advice
public aspect AspectConta {
private pointcut callConstruct(): call(Conta+.new(..));
public pointcut getSaldo():get(double Conta.saldo);
before() : callConstruct (){
System.out.println(“Exemplo de chamada de
constructor"); }
before() : getSaldo() {
System.out.println(“Exemplo de chamada de
método”);
}
};

60. Declaração intertipos – Inter-type declaration
v Construções que possibilitam alterar a estrutura
estática de uma unidade.
v Incluir atributos
v Incluir métodos e construtores
v Modicar a hieráquia dos tipos
v Interesse de garantia de regras e políticas da
arquitetura.

61. Combinação - Weaving
v Termo como é conhecido o processo de compilação
dos Aspectos.
v Combinador - Aspect Weaver – nome como é conhecido os
compiladores de aspecto.

62. Interesse de garantia de regras e políticas
v Objetiva garantir que políticas ou regras de projeto e
implementação são obedecidas pelo sistema.
v Verificação das políticas é feita em tempo de
compilação utilizando as construções:
v declare error
v declare warning
v Exemplo:
v Evitar o uso de System.out ou System.err dentro das classes
do sistema.
v Evitar chamada a impressão da pilha de exceção.
(java.lang.Throwable.printStackTrace())

63. Interesse de garantia de regras e políticas

64. DEMO

65. Abordagens de Desenvolvimento OA
v Abordagem Obliviousness
v Identifique os código base e interesses transversais do
sistema.
v Implemente inicialmente o código base e, em seguida, os
interesses transversais.
v Abordagem baseada em Refactoring
v Desenvolva o sistema usando técnicas OO
v Sempre que encontrar um Interesse Transversal, refatore-o
para um Aspecto.
FILMAN et. al. Aspect-oriented programming is quantification and obliviousness. In Aspect-Oriented Software Development,
pp. 21–35. Addison-Wesley, 2005.

66. Abordagens de Desenvolvimento OA
v Abordagem baseada em “Design Rules”
v Busca minimizar custos da abordagem Obliviousness”
v Impõe conjunto de regras de projeto entre código base e
interesses transversais na forma de interfaces.
v Interfaces determinam:
v Que comportamentos (join points) devem ser expostos
pelo código base.
v Restrições na implementação (ou projeto) do programa
que garantem que os comportamentos são expostos por
pontos de junção.
v Contratos comportamentais que devem ser obedecidos
pelas classes e aspectos.

67. Referências
v Literaturas recomendadas

68. Referências
[1]CLARKE, Siobhan. Aspect-Oriented Analysis and Design.
Addison Wesley, 2005.
[2]Chavez, C., Lucena, C. A Metamodel for Aspect-Oriented
Modeling. Workshop on Aspect-oriented Modeling with the UML,
1st International Conference on Aspect-Oriented Software
Development, Netherlands, 2002.
[3]Chavez, C., Lucena, C. A Theory of Aspects for Aspect-
Oriented Software Development. XVII Simpósio Brasileiro de
Engenharia de Software, pp.130-145, Manaus, 2003.
[4]Chavez, C. A Model-Driven Approach to Aspect-Oriented
Design. Doctoral Thesis, Computer Science Department, PUC-
Rio, April 2004, Rio de Janeiro, Brasil.
[5]HIGHLEY, T.J.; LACK, Michael; MYERS, Perry. Aspect
Oriented Programming: A Critical Analysis of a New
Programming Paradigm, 1999

69. Referências
[6]IRWIN, John; KICZALES, Gregor; LAMPING, John;
MENDHEKAR, Anurag; MAEDA, Chris, LOPES, Cristina Videira;
LOINGTIER, Jean-Marc. Aspect-Oriented Programming. In:
Proceeding of ECOOP’97, Filand: Springer-Verlag,1997.
[7]JACOBSON,I.; PAN-WEI, NG. Aspect-Oriented Software
Development with Use Case. Addison Wesley, 2005.
[8]JOHNSON, Rod; HOELLER, Juergen. J2EE Development
without EJB, Wrox Press, 2004.
[9]KISELEV, Ivan. Aspect-oriented Programming with AspectJ.
SAMS, 2003.
[10]LADDAD, Ramnivas. AspectJ in Action. Manning publications.
2003.

70. Referências
[11]LOPES, Cristina Isabel Videira, D: a language framework for
distributed programming. Ph. D. Thesis, Northeast University,
1997.
[12]RESENDE, Antônio Maria; SILVA, Claudiney Calixto.
Programação orientada a aspectos em Java. Rio de Janeiro:
Brasport, 2005.
[13]TIRELO, F.; BIGONHA, R.S; BIGONHA, M. A. A; VALENTE, M.
T. O.M. Desenvolvimento de Software orientado por
aspectos. In: Anais da Sociedade Brasileira de Computação,
Salvador-Bahia, 2004, p. 57-96.

71. Perguntas
Alessandro Ferreira Leite

72. Obrigado
Alessandro Ferreira Leite