Desenvolvimento de SoftwareOrientado a Aspectos – (DSOA)Alessandro Ferreira Leite – Sapiens IT Tecnologia
Apresentaçãov  Bacharelando em Ciência da Computaçãov  Analista de Sistemas e Projetista de software - Sapiens IT    Tec...
Objetivos1.  Introdução à Orientação a Aspectos (OA)     1.  Motivações     2.  Objetivos     3.  Histórico e evoluções   ...
Desenvolvimento de Software Orientado a Aspecto (DSOA)v Novo paradigma de desenvolvimento de software, que   provê avança...
Motivações/Necessidadesv As aplicações estão ampliando os limites das técnicas   de programação atuais, de modo que certa...
Estratégicasv Quebrar os problemas em partes menores – dividir   para conquistar.v Suporte das linguagens para represent...
Estratégica – Desenvolvimento software v  Os interesses são modularizados através de diferentes     abstrações providas p...
Programação Orientada a Objetos - OOPv Sem dúvida proporcionou avanços significativos ao   desenvolvimento de software.v...
Programação Orientada a Objetos - OOPv Possibilita modularizar, de forma satisfatória, alguns   tipos de interesses.   v...
Exemplo – Crosscutting concernsimport java.util.logging.Level;import java.util.logging.Logger;public class Conta{      pri...
Limitações da Orientação a Objetosv Interesse de Logging do Jakarta Tomcat                                     (c) Copyri...
Limitações da Orientação a Objetosv XML Parsing                                     (c) Copyright 1998-2002 Xerox Corpora...
Limitações da Orientação a Objetosv Espalhamento de código (Scattering)v Entrelaçamento (Tangling)v A implementação de ...
Limitações da Orientação a Objetosv Conseqüências   v Prejudica o reúso   v Dificulta o encapsulamento   v Compromete ...
Separação de interesses – Separation Of Concerns (SOC)v Teoria que investiga como separar as diversas   preocupações de u...
Separação de interesses – Separation Of Concerns (SOC)v Interesse - qualquer requisito ou consideração que   deve ser ate...
Separação de interesses – Separation Of Concerns (SOC)v  Exemplos de interesses   v O sistema deve permitir o cadastro d...
Separação de interesses – Separation Of Concerns (SOC)  v Os interesses podem ser classificados em:     v  Interesses pr...
Separação de interesses – Separation Of Concerns (SOC)v  Exemplo:   v  Autenticação   v  Logging   v  Resource pooling...
Separação de interesses – Separation of Concerns (SOC) v  Separação de interesses promove:    v Código de melhor qualida...
Implementação dos interesses                     Regra de negócioInteresses(concerns)      Persistência                   ...
Estratégicas de implementação     Persistência                                                        Segurança           ...
Crosscutting concernsv É um interesse em que a sua implementação interfere   no comportamentos, estrutura de muitas outra...
Entrelaçamento de código - Tangled codev Linhas de códigos que são inseridas em um módulo que tratam deinteresses diferen...
Entrelaçamento de código - Tangled codepublic class AlunoBO extends ...{  public boolean salvar (Aluno aluno, ... ) throws...
Code Scattering -v É o processo de repetição de um determinado trecho de código nosdiversos módulos, classes do sistema. ...
Abordagens para Separação de interesses [3]v  Padrões de projeto (design patterns):   v Mixin: invocar interfaces e não ...
Abordagens para Separação de interesses [3]v  Meta-programação     v Reflexividade, introspecçãov  Higher-order program...
Orientação a Aspectos (OA) – Aspect-Oriented Programmingv Paradigma de programação que propõe um novo tipo   de abstração...
Orientação a Aspectos (AO)v  A idéia da orientação a aspectos é possibilitar ao desenvolvedor a    utilização de um novo ...
Orientação a Aspectos (AO)v Separação avançada de interesses   v Modularização dos Interesses Transversais   v Nova abs...
Benefíciosv Modularização adequada de interesses transversais   v Melhora a compreensão   v Facilidade de manutenção   ...
Mitos e verdadesv O fluxo de um sistema, baseado que utiliza AOP, é   difícil de ser seguido, observado.v AOP não soluci...
Mitos e verdadesv Aspectos são sempre infra-estruturas auxiliares de uma   aplicação.v Se utilizar OOP adequadamente, nã...
Mitos e verdadesv Código AOP é difícil compreensão.v AOP é uma técnica de pré-processamento (ou AOP é   uma técnica comp...
Linguagens AOPsv AspectJ – http://eclipse.org/aspectj/v HyperJ – http://www.alphaworks.ibm.com/tech/hyperjv AspectC++ -...
Desenvolvimento de Software Orientado a Aspectos (DSOA)v AOP – Aspect-Oriented Programmingv AOM – Aspect-Oriented Modeli...
AspectJv Linguagem de programação orientada a aspectos.v Extensão da linguagem Java.v É a mais conhecida e que mais inf...
AspectJv Suporte a dois tipos de implementacão de requisitos   transversais:v  Transversalidade dinâmica - permite defin...
AspectJv Integra-se com as principais ferramentas de   desenvolvimento.v Eclipse – http://www.eclipse.org/ajdtv JBuilde...
Orientação a Aspectos (AO) v  Além dos conceitos relacionados a Orientação a Objetos     (método, classe, atributos,inter...
Aspecto – Aspectv Unidade modular de implementação de requisitos   transversais. Aspectos são definidos por declarações  ...
Aspecto – Aspectv Aspectos podem:   v Herdar de classes   v Implementar interfaces (com exceção de java.io.Serializable...
Aspecto - Aspectv SubAspectos:   v Herdam atributos, métodos, pointcuts e advices   v Podem redefinir seu modelo de ins...
Aspecto - Aspectv Aspectos não é classe, pois:   v  Pode ser definido utilizando o modificador     “privileged”   v Não...
Aspecto - Exemploclass Classe{   public static aspect NestedAspect {}}privileged aspect AbstractLogging implements Logger ...
Aspecto – Comportamento
Ponto de junção - Join Pointv Qualquer ponto,local, do programa que possa ser   interceptado e onde o programa de aspecto...
Ponto de junção - Join Pointspublic class Conta{  private double saldo;   (...)  public Conta(int numero){     this.numero...
Conjunto de pontos de junção - PointCutsv Construção usada para identificar pontos de   junção que se deseja interceptar ...
Conjunto de pontos de junção - PointCutsv Podem ser:    v  Anônimos   v  Nomeados   v Definidos dentro de classes, int...
Conjunto de pontos de junção - PointCutsv Podem ser combinados, utilizando os operadores:    v && (e)    v || (ou)    v...
Conjunto de pontos de junção - PointCuts                             Todos os tipos com exceção do tipo! java.util.Vector ...
Conjunto de pontos de junção - exemplopublic aspect AspectConta {     pointcut callConstruct (): call(Conta+.new(..));    ...
Comportamento Tranversal - Advicev Instruções, ou conjunto de instruções, que são   executadas após a identificação de um...
Comportamento Tranversal - Advicev Before - executado antes que a ação associada ao ponto  de junção seja executada.v Af...
Comportamento Tranversal - Advicev  After returning – é utilizado para interceptar um método após a    sua completa execu...
Comportamento Tranversal - Advicev After Throwable – utilizado para interceptar um   método que lançou uma exceção.v Sin...
Comportamento Tranversal - Advicepublic aspect AspectConta {   private pointcut callConstruct(): call(Conta+.new(..));   p...
Declaração intertipos – Inter-type declarationv Construções que possibilitam alterar a estrutura   estática de uma unidad...
Combinação - Weavingv Termo como é conhecido o processo de compilaçãodos Aspectos.v Combinador - Aspect Weaver – nome co...
Interesse de garantia de regras e políticasv Objetiva garantir que políticas ou regras de projeto e   implementação são o...
Interesse de garantia de regras e políticas
DEMO
Abordagens de Desenvolvimento OAv Abordagem Obliviousness      v Identifique os código base e interesses transversais do...
Abordagens de Desenvolvimento OAv Abordagem baseada em “Design Rules”  v Busca minimizar custos da abordagem Obliviousne...
Referênciasv Literaturas recomendadas
Referências[1]CLARKE, Siobhan. Aspect-Oriented Analysis and Design.   Addison Wesley, 2005.[2]Chavez, C., Lucena, C. A Met...
Referências[6]IRWIN, John; KICZALES, Gregor; LAMPING, John;   MENDHEKAR, Anurag; MAEDA, Chris, LOPES, Cristina Videira;   ...
Referências[11]LOPES, Cristina Isabel Videira, D: a language framework for   distributed programming. Ph. D. Thesis, North...
PerguntasAlessandro Ferreira Leite
ObrigadoAlessandro Ferreira Leite
Próximos SlideShares
Carregando em…5
×

Desenvolvimento de software orientado a aspectos

2.400 visualizações

Publicada em

Mini-curso Borcon Brasil 2005

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.400
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Desenvolvimento de software orientado a aspectos

  1. 1. Desenvolvimento de SoftwareOrientado a Aspectos – (DSOA)Alessandro Ferreira Leite – Sapiens IT Tecnologia
  2. 2. Apresentaçãov  Bacharelando em Ciência da Computaçãov  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. 3. Objetivos1.  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 AOPs2.  Desenvolvimento de software orientado a aspectos - (DSOA)3.  Aplicações4.  Referências5.  Espaço aberto a perguntas
  4. 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. 5. Motivações/Necessidadesv 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. 6. Estratégicasv 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. 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. 8. Programação Orientada a Objetos - OOPv 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çav Objetos capturam os dados, comportamentos, estados e as estruturas internas.v Suas estruturas são baseadas em apenas uma dimensão.
  9. 9. Programação Orientada a Objetos - OOPv 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. 10. Exemplo – Crosscutting concernsimport 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. 11. Limitações da Orientação a Objetosv Interesse de Logging do Jakarta Tomcat (c) Copyright 1998-2002 Xerox Corporation
  12. 12. Limitações da Orientação a Objetosv XML Parsing (c) Copyright 1998-2002 Xerox Corporation
  13. 13. Limitações da Orientação a Objetosv 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. 14. Limitações da Orientação a Objetosv 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. 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. 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. 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. 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. 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. 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. 21. Implementação dos interesses Regra de negócioInteresses(concerns) Persistência Segurança Implementações Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 8]
  22. 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. 23. Crosscutting concernsv É um interesse em que a sua implementação interfere no comportamentos, estrutura de muitas outras classes, módulos de um sistema.
  24. 24. Entrelaçamento de código - Tangled codev Linhas de códigos que são inseridas em um módulo que tratam deinteresses diferentes. Logging Regras de negócio Persistência Segurança Adaptado, [ADDAD, Ramnivas. AspectJ in Action. Mannning,2003. pp. 16]
  25. 25. Entrelaçamento de código - Tangled codepublic 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. 26. Code Scattering -v É o processo de repetição de um determinado trecho de código nosdiversos 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. 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ênciav  Frameworks com suporte a interesses pré-definidos: v  Servidores de aplicação (J2EE, .NET)
  28. 28. Abordagens para Separação de interesses [3]v  Meta-programação v Reflexividade, introspecçãov  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. 29. Orientação a Aspectos (OA) – Aspect-Oriented Programmingv 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. OOPSLA86 Proceedings.
  30. 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. 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. 32. Benefíciosv Modularização adequada de interesses transversais v Melhora a compreensão v Facilidade de manutenção v Facilidade de reutilização
  33. 33. Mitos e verdadesv 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. 34. Mitos e verdadesv 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. 35. Mitos e verdadesv 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. 36. Linguagens AOPsv AspectJ – http://eclipse.org/aspectj/v HyperJ – http://www.alphaworks.ibm.com/tech/hyperjv AspectC++ - http://www.aspectc.orgv AspectWerkz - http://aspectwerkz.codehaus.orgv JBoss AOP - http://www.jboss.org/products/aopv AspectC# - http://www.castleproject.org/index.php/AspectSharp * Última visita em, 26 de outubro de 2005
  37. 37. Desenvolvimento de Software Orientado a Aspectos (DSOA)v AOP – Aspect-Oriented Programmingv AOM – Aspect-Oriented Modelingv AORE – Aspect-Oriented Requirements Engineeringv AORA – Aspect-Oriented Requirements Analysisv Aspectos Arquiteturais
  38. 38. AspectJv 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. 39. AspectJv 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. 40. AspectJv Integra-se com as principais ferramentas de desenvolvimento.v Eclipse – http://www.eclipse.org/ajdtv JBuilder – http://aspectj4jbuildr.sourceforge.netv Netbeans – http://aspectj4netbean.sourceforge.netv Emacs – http://aspectj4emacs.sourceforge.netv JDeveloper - https://jdeveloperaop.dev.java.net/ * Última visita em, 26 de outubro de 2005
  41. 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. 42. Aspecto – Aspectv 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 – estruturav  Dinâmico – fluxo de execução
  43. 43. Aspecto – Aspectv Aspectos podem: v Herdar de classes v Implementar interfaces (com exceção de java.io.Serializable e java.lang.Cloneable) v Estender outros aspectosv Só pode herdar de aspectos abstratosv Pode definir pointcuts e métodos abstratosv Pode definir atributos, classes, e outros aspectosv Pode utilizar os modificadores de acessos
  44. 44. Aspecto - Aspectv SubAspectos: v Herdam atributos, métodos, pointcuts e advices v Podem redefinir seu modelo de instanciaçãov Pode ser definidos dentro de classes, interfaces e outros aspectos.v São Singleton por padrão
  45. 45. Aspecto - Aspectv 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. 46. Aspecto - Exemploclass 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. 47. Aspecto – Comportamento
  48. 48. Ponto de junção - Join Pointv 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. 49. Ponto de junção - Join Pointspublic class Conta{ private double saldo; (...) public Conta(int numero){ this.numero = numero; } protected void setSaldo(double valor){ this.saldo = valor; }}
  50. 50. Conjunto de pontos de junção - PointCutsv Construção usada para identificar pontos de junção que se deseja interceptar em um programav 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. 51. Conjunto de pontos de junção - PointCutsv Podem ser: v  Anônimos v  Nomeados v Definidos dentro de classes, interfaces e aspectosv Utilizar os modificadores de acesso: v Privado - private v Protegido - protected v Default - ausência de modificador – visibilidade de pacote v Publico - public
  52. 52. Conjunto de pontos de junção - PointCutsv 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. 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 ouVector || Hastable java.util.Hashtable Todos os tipo do pacote javax, ou osjavax..*Model || seus subpacotes diretos e indiretosjavax.swing.text.Document que terminem com o nome Model ou o tipo javax.swing.text.Documentjava.util.RandomAccess+ && Todos os tipos que implementem asjava.util.List+ interfaces RandomAcess e List Todos os métodos da classe, Conta,* Conta+.*(..) incluindo o(s) da(s) subclasses(s)
  54. 54. Conjunto de pontos de junção - exemplopublic aspect AspectConta { pointcut callConstruct (): call(Conta+.new(..)); pointcut executionConstruct(): execution (Conta +.new()); pointcut getSaldo():get(double Conta.saldo);};
  55. 55. Comportamento Tranversal - Advicev 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. 56. Comportamento Tranversal - Advicev 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 throwingv 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. 57. Comportamento Tranversal - Advicev  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. 58. Comportamento Tranversal - Advicev 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. 59. Comportamento Tranversal - Advicepublic 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. 60. Declaração intertipos – Inter-type declarationv Construções que possibilitam alterar a estrutura estática de uma unidade.v Incluir atributosv Incluir métodos e construtoresv Modicar a hieráquia dos tiposv Interesse de garantia de regras e políticas da arquitetura.
  61. 61. Combinação - Weavingv Termo como é conhecido o processo de compilaçãodos Aspectos.v Combinador - Aspect Weaver – nome como é conhecido oscompiladores de aspecto.
  62. 62. Interesse de garantia de regras e políticasv 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 warningv  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. 63. Interesse de garantia de regras e políticas
  64. 64. DEMO
  65. 65. Abordagens de Desenvolvimento OAv 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. 66. Abordagens de Desenvolvimento OAv 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. 67. Referênciasv Literaturas recomendadas
  68. 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. 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. 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. 71. PerguntasAlessandro Ferreira Leite
  72. 72. ObrigadoAlessandro Ferreira Leite

×