UNIVERSIDADE FEDERAL FLUMINENSE CENTRO TECNOLÓGICO INSTITUTO DE COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL FLUMINENSE CENTRO TECNOLÓGICO INSTITUTO DE COMPUTAÇÃO HELIOMAR KANN DA ROCHA SANTOS PROGRAMAÇÃO ORIENTADA A ASPECTOS NITERÓI 2008

2 2 HELIOMAR KANN DA ROCHA SANTOS PROGRAMAÇÃO ORIENTADA A ASPECTOS Trabalho de Conclusão apresentado ao Curso de Graduação em Ciência da Computação da Universidade Federal Fluminense, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. ORIENTADOR: Prof. Ms. Carlos Alberto Ribeiro NITERÓI 2008

3 3 HELIOMAR KANN DA ROCHA SANTOS PROGRAMAÇÃO ORIENTADA A ASPECTOS Trabalho de Conclusão apresentado ao Curso de Graduação em Ciência da Computação da Universidade Federal Fluminense, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. BANCA EXAMINADORA Prof. Ms. Carlos Alberto Ribeiro - Orientador Universidade Federal Fuminence Prof. Dr. Esteban Walter Gonzalez Clua Universidade Federal Fuminence Prof. Dr. Luiz Carlos Castro Guedes Universidade Federal Fuminence

4 4 Seja em você a mudança que quer para o mundo Ghandi

5 5 AGRADECIMENTOS A Deus por toda sua criação, À minha família pela compreensão do meu comprometimento com a Universidade, Ao Professor Mestre Carlos Alberto Ribeiro, meu orientador, pela atenção, motivação e dedicação, À Anna Paula Freitas de Carvalho, minha namorada pela extrema paciência e amor, A todos os docentes dessa excelente academia que me construíram profissionalmente, Aos integrantes do APJAVA, apartamento onde moro, À Priscila Freitas de Carvalho e ao Samuel Bandeira Coelho pelo apoio e dicas.

6 6 ABSTRACT This work presents a detailed and exemplified study of the Aspect-Oriented Programming (AOP) paradigm. Aspectj offer us a more comprehensive toolkit and options for the development of systems in a "clear", scalable and maintenable way. It also will be shown applications and gains in choosing the Aspect-Oriented paradigm. Cases such as "Transaction Control", "Query Executer", "Audit and Event Log" and "Design Pattern" will be exemplified by a conventional approach and with an Aspectj approach. In purpose of this work is to summarize the major advantages of this paradigm, as well as difficulties, future works, pros and cons. Key-words: Aspect-Oriented Programming (AOP), cross-cutting concerns, AspectJ, transactional control, Annotation.

7 7 RESUMO O presente trabalho apresenta um estudo detalhado e exemplificado do paradigma da Programação Orientada a Aspectos (POA) que nos possibilitará mais um vasto conjunto de ferramentas e opções para o desenvolvimento de sistemas de forma clara, escalável e manutenível. Também serão mostrados aplicações e ganhos ao adotarmos o paradigma orientado a aspectos. Cases como Controle Transacional, Execução de Buscas, Auditoria e Log de Eventos e Padrões de Projeto serão exemplificados em uma abordagem convencional e uma com Aspectj. Na conclusão serão sintetizadas as grandes vantagens deste paradigma, assim como as dificuldades, trabalhos futuros, prós e contras. Palavras-chave: Programação Orientada a Aspectos (POA), Interesses Transversais ou Ortogonais, AspectJ, Controle Transacional, Anotação.

8 8 SUMÁRIO 1. Introdução Objetivo Motivação Estrutura do documento Estudo Bibliográfico Requisitos Ortogonais ou Transversais (cross-cutting concerns) Sistema Orientado a Aspectos Composição Fases Aspectos Equivalência Pontos de Junção (Join Points) Pontos de Atuação (Pointcuts) Estrutura do ponto de atuação Pointcuts de fluxo de controle Pointcuts genéricos Pointcuts nomeados Adendos (Advices) Tipos de adendos Advice do tipo before Advice do tipo after Advice do tipo around Modelagem na POA Benefícios Aplicação Controle de transação Transação Anotações Proxy Estrutura sem aspectos Estrutura com aspecto Benefícios Controle de interesses ortogonais em um DAO Modelagem padrão com Enhancer e fábrica de DAO Problemas encontrados Modelagem com aspectos Solução com AspectJ Explicação do código Benefícios Aspectos para implementação de padrões de projetos (design patterns) Padrão Singleton...56

9 Singleton com aspectj Singleton com aspectj e anotação Auditoria, Log de Eventos Estudo de caso Sugestão com aspecto Outras aplicações Aspectos para tratamento de exceção Handler Declare soft After Throwing Aspectos para cumprimento de regras arquiteturais Declarando Erros Declarando Avisos (Warnings) Conclusão Referências...70 Apêndice I...73 Apêncide II

10 10 LISTA DE FIGURAS Figura 1: Interesses em comum entre camadas...17 Figura 2: Ortogonalidade dos interesses...17 Figura 3: Interesses espalhados nas classes...18 Figura 4: Componentes, Aspectos, Combinador de Aspectos...20 Figura 5: Decomposição, Implementação, Recomposição...21 Figura 6: Exemplo de aspecto...22 Figura 7: Exemplo de saída de um aspecto...22 Figura 8: Classe MessageCommunicator e Test...22 Figura 9: Aspect MessageCommunicator...23 Figura 10: Classe auxiliar para mostrar equivalência...23 Figura 11: Código equivalente ao aspecto da figura Figura 12: Diferença entre chamada e execução...25 Figura 13: Wildcards...26 Figura 14: Estrutura do ponto de atuação...27 Figura 15: Designadores de pointcuts...27 Figura 16: Pointcuts de fluxo de controle...28 Figura 17: Pointcuts genéricos...28 Figura 18: Exemplo 1 de pointcut genérico...28 Figura 19: Exemplo 2 de pointcut genérico...28 Figura 20: Pointcuts nomeados, equivalência...29 Figura 21: Exemplo de advice...30 Figura 22: Estrutura do advice...31 Figura 23: Exemplo 1 de advice around...32 Figura 24: Exemplo 2 de advice around...32 Figura 25: Diagrama de classes de uma classe e um aspecto...33 Figura 26:

11 11 Figura 27: Modelo de criação de classes de serviço com Proxy via Enhancer...37 Figura 28: Fabrica para específica para Servers...38 Figura 29: Interceptador de classes de serviço...40 Figura 30: Estrutura com aspecto...40 Figura 31: Introdução de variável em uma classe com aspectj...41 Figura 32: Controle Transacional com aspectj...43 Figura 33: Estrutura para controle de DAO com Proxy via Enhancer...46 Figura 34: Fabrica específica para DAOs...47 Figura 35: Interceptador de DAO...49 Figura 36: Estrutura de DAO com aspectj...50 Figura 37: Classe PessoaDAOImpl...51 Figura 38: Interface PessoaDAO...52 Figura 39: Exceção criada para melhorar a legibilidade de métodos interceptados...52 Figura 40: Controle de DAO para buscas em geral...55 Figura 41: Exemplo de implementação Singleton...57 Figura 42: Aspecto que define uma implementação singleton...58 Figura 43: Reusabilidade em aspectj, através de aspectos genéricos...58 Figura 44: Figura 45: Aspecto adaptado para contemplar a (figura 44)...59 Figura 46: Exemplo de utilização da Figura 47: Aspecto para auditoria e log de eventos...64 Figura 48: Exemplo de handler...64 Figura 49: Exemplo de um método lançando um RuntimeException...65 Figura 50: Exemplo da construção declare soft...65 Figura 51: Uso de Thread sem declaração de tratamento de InterruptedException...65 Figura 52: Encapsulamento de exceções...66 Figura 53: Exemplo de declaração de erro de compilação...66

12 Figura 54: Exemplo de declaração de warnings

13 13 LISTA DE ABREVIATURAS E SIGLAS JEE: Java Enterprise Edition JSF: Java Server Faces API: Application Programming Interface POA: Programação Orientada a Aspectos JPA: Java Persistence API DAO: Data Access Object POO: Programação Orientada a Objetos URL: Uniform Resource Locator. SGBD: Sistema de Gerenciamento de Banco de Dados JPAQL: SQL para JPA SQL: Structured Query Language XHTML: extensible Hypertext Markup Language IDE: Integrated Development Environment AJDE: AspectJ Development Environment IA: Inteligência Artificial

14 14 1. INTRODUÇÃO 1.1 Objetivo O trabalho objetiva realizar um estudo amplo da Programação Orientada a Aspectos (POA), utilizando especificamente AspectJ, uma extensão em Java para o desenvolvimento de tal paradigma. O estudo bibliográfico será composto de todos os conceitos fundamentais de POA com aplicações e vantagens. Também serão analisadas implementações em Java padrão e com AspectJ. Os casos estudados são muito comuns em grandes sistemas de banco de dados que utilizam padrões de projetos como AppService e DAO. Serão apresentados: Controle de transação para AppService Execução de buscas para DAO Padrões de projetos com Aspectj Controle de auditoria e log de eventos. Todos esses casos são de grande utilização no mercado atual e podem ser aprimorados. 1.2 Motivação A Programação Orientada a Objetos (POO) tem o propósito de modularizar e encapsular responsabilidades (métodos e atributos) afins dentro de um escopo bem definido (classes), em que as particularidades são os atributos que cada instância desse escopo (objetos) terão. Dessa forma podemos com relativa facilidade desenvolver, com códigos reutilizáveis, sistemas manuteníveis e escaláveis. Ao longo do tempo essa estrutura mostrou-se frágil em alguns aspectos. De acordo com [2] cerca de 80% da vida útil de um software é manutenção. É na manutenção que muitos requisitos ortogonais ou transversais (cross-cutting concerns) são tratados, o que na maioria das vezes são requisitos não funcionais. Com o passar do tempo, no desenvolvimento de software, foram observados vários casos em que não é possível a reutilização de código, ou seja, fazia-se necessária a duplicação

15 15 de código, tornando o sistema mais complexo, de difícil manutenção e possivelmente comprometendo seu tempo de vida. A Programação Orientada a Aspectos (POA) foi idealizada por pesquisadores da Xerox Parc [1] para tratar de forma elegante os cross-cutting concerns, encapsulando e isolando esses interesses em arquivos separados do código principal. A POA não veio para substituir a POO e sim complementar de forma organizada. POA é uma evolução da POO, ela não faz sentido sem POO. Utilizando o paradigma aspectual em muitos casos não há necessidade de substituição completa de sistemas já existentes e sim pequenos ajustes que farão com que o sistema tenha uma vida útil prolongada. Essa esperança torna o uso de aspectos muito atrativo para o mercado de trabalho atual. 1.3 Estrutura do documento Os três capítulos seguintes desta monografia estão estruturados da seguinte forma: O capítulo 2 terá uma abordagem com todos os conceitos fundamentais para o entendimento do paradigma orientado a aspectos com AspectJ, estruturação, particularidades da linguagem, semelhanças, equivalência de códigos, vantagens e aplicações. O capítulo 3 conterá as implementações de alguns estudos de caso em Java padrão e com AspectJ. O capítulo 4 apresenta os problemas encontrados, as conclusões obtidas e o que sugerimos como trabalhos futuros.

16 16 2. ESTUDO BIBLIOGRÁFICO Nesse capítulo são abordados os conceitos fundamentais para o entendimento da Programação Orientada a Aspecto. AspectJ foi escolhido por ser uma extensão de uma linguagem conhecia (java) e por ser bem aceita tanto na comunidade POA quanto nas demais comunidades de desenvolvimento de software. 2.1 Requisitos Ortogonais ou Transversais (cross-cutting concerns) O termo separação de interesses foi cunhado por Edsger Dijkstra em 1974 para denotar o princípio que guia a divisão em partes: todo sistema de software lida com diferentes interesses, sejam eles dados, operações, ou outros requisitos do sistema. O ideal seria que a parte do programa dedicada a satisfazer a um determinado interesse estivesse concentrada em uma única localidade física, separada de outros interesses, para que o interesse possa ser estudado e compreendido com facilidade [14]. Nos sistemas atuais ocorrem, com muita freqüência, casos em que interesses nem sempre podem ser tratados de forma separada em POO, como no caso clássico de implementação em camadas de interesses (Negócio, Persistência, figura 1), observa-se que a auditoria é um interesse que transpassa essa separação lógica, tendo que ser conhecida pelas diferentes camadas. A figura 1 mostra interesses (Negócio, Persistência, Logging) que métodos de classes de camadas diferentes possuem em comum, porém são de difícil modularização. Esses interesses são de extrema importância, mas não são de inteira responsabilidade das classes ou objetos alvos onde terrão que ser implementados caso uma abordagem convencional de POO seja utilizada.

17 17 Figura 1: Interesses em comum entre camadas Um dos motivos para se chamar requisito ortogonal é evidenciado na figura 2 que mostra uma formação de um gráfico 3D como sendo a melhor representação visual para esse tipo de interesse, esses interesses são projetados de forma ortogonal. Interesses Figura 2: Ortogonalidade dos interesses Em POO mesmo se esforçando para obtermos um software nos padrões, ou seja, pouca redundância, alta coesão, fraco acoplamento, fácil manutenção, reusável e escalável, vão ocorrer ocasiões em que será necessária a criação desses interesses não modularizáveis que ficarão espalhados entre as classes. Um bom exemplo ocorre em registros de auditoria e eventos de um software. Em POO convencional precisaremos espalhar por entre métodos de

18 18 classes o código que fará o registro de quem está usando determinado método com determinados parâmetros em uma determinada hora. Esse tipo de abordagem é comum em sistemas de alta segurança, sistemas de telefonia, call-center, aplicações web, distribuídas, etc. Exemplo, na figura 3 os quadrados internos às classes poderão representar o serviço de logging do sistema. Não esquecendo que sistemas possuem centenas de classes com várias dezenas de métodos cada classe. Figura 3: Interesses espalhados nas classes Nessas condições uma série de fatores desfavoráveis pode facilmente ser analisada: Fraca coesão: Classes terão que tratar de interesses diversos que não são de inteira responsabilidade semântica da mesma, terão que conhecer interesses que não estão diretamente relacionados aos que implementam. Forte acoplamento As classes passam a ter uma maior dependência externa. Dificuldade de manutenção: Haverá vários trechos de código em comum espalhados. Uma mudança a ser implementada, em um desses trechos, pode ser desastrosa, além disso, vários trechos de códigos diferentes podem estar fazendo a mesma coisa. A grande quantidade de classes também é um fator dificultante. Comprometimento da escalabilidade: Na medida em que o software cresce torna-se sacrificante a implementação de códigos que sejam compatíveis com a realidade de módulos antigos, sendo assim é necessário um grande desprendimento de força de trabalho com refatoração a cada necessidade de crescimento do software.

19 19 Aumento de redundância: É fácil ver que códigos estarão redundantes não só entre classes como entre métodos de uma mesma classe, pois em POO não há formas simples de se tratar interesses entrecortantes sem redundância. Diminuição de reutilização de código: Como dito no item acima, o código será duplicado e não reutilizado. 2.2 Sistema Orientado a Aspectos Composição Um sistema orientado a aspectos é composto pelos seguintes componentes principais: Linguagem de componentes: A linguagem de componentes é a utilizada para implementar as funções normais do sistema. Exemplos desse tipo de linguagem, JAVA, C, C++, RUBY, PYTHON, DELPHI etc.. Linguagem de aspectos: A linguagem de aspectos deve oferecer as vantagens básicas que uma linguagem de programação disponibiliza. AspectJ é uma linguagem de aspecto que por ser uma extensão de JAVA possui boa parte de suas características. É nessa linguagem que os interesses ortogonais de um sistema são implementados. Combinador de aspectos: O combinador de aspectos (weaver) é responsável pela junção do código implementado em uma linguagem de aspectos com um código implementado por uma linguagem de componentes, resultando no código executável final. Programas escritos em linguagem de componentes: Componentes são as partes funcionais de um sistema, partes responsáveis por tratar de algum interesse específico. As entidades do sistema representadas por classes são exemplos. Classes como Pessoa, Funcionário e Filme podem ser consideradas componentes em um sistema de controle de uma locadora. A figura 4 apresenta o Weaver combinando os componentes com os aspectos para formar o programa operacional.

20 20 Figura 4: Componentes, Aspectos, Combinador de Aspectos Fases A Programação Orientada Aspectos envolve três fases distintas: Decomposição: os vários interesses do sistema são identificados e classificados como comuns ou transversais. Implementação: os interesses são implementados separadamente em classes (para os interesses comuns) e aspectos (para os interesses transversais). São estabelecidas regras de corte, cada regra de corte define onde deve ocorrer a interferência de algum interesse transversal. Recomposição: É nessa fase que ocorre a costura de código (weaving). Os interesses gerados em uma linguagem orientada por aspectos são entrelaçados com o código do programa principal para formar o código completo operacional. Em POA ocorre apenas a costura estática que é realizada no passo de compilação ou carregamento, modificando o código executável do programa base. Existem outros sistemas que permitem a costura dinâmica, nesse caso, em tempo de execução, é alterado o comportamento do código carregado pela JVM sem que haja alteração do código executável original. Não entraremos em detalhes sobre costura dinâmica, pois foge do foco dessa monografia. A figura 5 mostra um exemplo das fases para uma classe A. A primeira parte da figura mostra as fases de decomposição e implementação, a terceira mostra a recomposição, nesse caso, a classe A resultante da combinação feita pelo Weaver.

21 21 Figura 5: Decomposição, Implementação, Recomposição 2.3 Aspectos Assim como uma classe é definida pela palavra "class" em JAVA o aspecto é definido como aspect para AspectJ. O aspecto é a abstração que AspectJ criou para implementar os interesses ortogonais, separando-os do código principal e possibilitando uma boa modularização. Basicamente um aspecto possui pointcuts e advices. Os pointcuts são definidos por um conjunto de join points e os advices representam a implementação dos interesses ortogonais. Os advices utilizam-se de pointcuts para definir onde o interesse será aplicado. Nas próximas seções veremos com mais detalhes pointcuts, join points e advices. A figura 6 mostra um aspecto completo que apresenta, de forma simplificada, o controle de transação de uma aplicação. public aspect ControleTransacao{ pointcut transacao() : call(@transacional * service..*.*(..)); before() : transacao(){ JPAUtil.beginTransaction(); after() : transacao() { JPAUtil.commitTransaction(); JPAUtil.closeEntityManager();

22 22 after() throwing : transacao() { JPAUtil.rollbackTransaction(); Figura 6: Exemplo de aspecto 2.4 Equivalência O aspecto da figura 9 é aplicado na classe MessageCommunicator (figura 8). A execução do método main contida na classe Test (figura 8) com esse aspecto, gera a seguinte saída: OI! Quer Aprender AspectJ? OI! João está gostando? Figura 7: Exemplo de saída de um aspecto As figuras 10 e 11 mostram um código equivalente à solução com aspecto. public class MessageCommunicator{ public static void deliver(string msg){ System.out.println(msg); public static void deliver(string person, String msg){ System.out.println(person + ", " + msg); public class Test{ public static void main(string[] args) { MessageCommunicator.deliver("Quer aprender AspectJ?"); MessageCommunicator.deliver("João", "está gostando?"); Figura 8: Classe MessageCommunicator e Test public aspect MessageCommunicator{

23 23 pointcut delivermessage() : call (* MessageCommunicator.deliver(..)); before () : delivermessage(){ System.out.print( OI! ); Figura 9: Aspect MessageCommunicator public class MannerAspect { public static MannerAspect aspectinstance; static { aspectinstance = new MannerAspect(); public static final void before0$ajc(){ System.out.print( OI! "); Figura 10: Classe auxiliar para mostrar equivalência class MessageCommunicator{ public static void deliver(string msg){ MannerAspect.aspectInstance.before0$ajc(); System.out.println(msg); public static void deliver(string person, String msg){ MannerAspect.aspectInstance.before0$ajc(); System.out.println(person + ", " + msg); class Test{ public static void main(string[] args) { MessageCommunicator.deliver("Quer aprender AspectJ?"); MessageCommunicator.deliver("João", "está gostando?");

24 24 Figura 11: Código equivalente ao aspecto da figura Pontos de Junção (Join Points) Pontos de junção nada mais são do que pontos bem definido na execução de um código. O conceito clássico para join points é citado por [9], que descreve como pontos de execução de um programa de componentes onde os aspectos serão aplicados. O AspectJ pode detectar e operar sobre os seguintes tipos de join points: Chamada de Métodos Execução de Métodos Chamada de Construtores Execução de Inicialização Execução de Construtores Execução de Inicialização Estática Pré-Inicialização de Objetos Inicialização de Objetos Referência a Campos Execução e Tratamento de Exceções A diferença entre os join points execução e chamada pode ser resumida como: Para um ponto de junção do tipo chamada, um aspecto será aplicado na classe ou lugar onde ocorreu a chamada. Já na execução, um aspecto será aplicado interno ao método interceptado propriamente dito. O exemplo abaixo deixa claro essa sutil diferença. //Classe Principal Public class Principal{ public static void main(string[] args) {

25 25 PessoaService pessoaservice = new PessoaService(); String login = "joao"; //*1 pessoaservice.getpessoabylogin(login); //*2 //Classe PessoaService Public class PessoaService { private PessoaDAO pessoadao = new PessoaDAOImpl(); public Pessoa getpessoabylogin (String login) { //**1 return pessoadao.getbylogin(login); //**2 Figura 12: Diferença entre chamada e execução Um aspecto será aplicado em *1 ou *2 caso for utilizado um join point do tipo de chamada, ou seja, será injetado um aspecto antes, depois ou envolta do ponto delimitado entre *1 e *2. Analogamente em um join point do tipo execução teremos um interesse injetado em **1 e **2. Motivos para existir a join point de chamada e execução: Como em linguagens orientadas a objetos existe polimorfismo, é possível chamarmos um método de uma classe e executarmos um método de uma de suas subclasses. Assim, é útil fazer a distinção em se tratando de aspectos, pois AspectJ oferece meios para recuperarmos o objeto no qual se encontra o método interceptado ou onde o join point foi marcado. Com polimorfismo esse objeto muda em tempo de execução. Além disso, como a chamada e execução podem estar em arquivos

26 fisicamente diferentes, pode-se gerar pontos de corte compostos onde a diferença entre chamada e execução torna-se mais importante [14] Pontos de Atuação (Pointcuts) Um pointcut tem como objetivo criar regras, genéricas ou específicas, se necessário. Ele é formado a partir da combinação de um ou mais join points, através de operadores lógicos (ou), &&(e),!(não). Com um pointcut podemos obter várias informações de um ponto de junção específico. Por exemplo, ao definimos que um ponto de ação será a chamada um método X, podemos obter os parâmetros passados para esse método, onde fisicamente o método está implementado (classe de origem), quem o chamou, exceções, tipo de retorno entre outras informações. Assim como membros de uma classe, pointcuts podem ser declarados como públicos, privados ou finais (final), mas não podem ser sobrecarregados. Dentro de um aspecto abstrato eles também podem ser declarados abstratos. Podemos ter pointcuts nomeados ou anônimos, a vantagem de se ter um pointcut nomeado é que suas regras podem ser usadas em outras partes do código aspecto. Para declaração de pointcuts o AspectJ oferece caracteres coringas (wildcards), tornando desnecessária a declaração explicita de alguns pontos de junção. A figura 13 mostra esses caracteres. Caractere Descrição * Qualquer seqüência de caracteres não contendo pontos.. Qualquer seqüência de caracteres, inclusive contendo pontos + Qualquer subclasse da classe em questão Figura 13: Wildcards Estrutura do ponto de atuação <pointcut> ::= <tipo de acesso> <nome do pointcut> ({lista de parâmetros) : { designador [ && ] Sendo: <tipo de acesso> ::= public private <nome do pointcut> ::= { <identificador> <parâmetros> ::= { <identificador> <tipo>

27 27 <designador> ::= [!]Call execution target args cflow cflowbelow within if <identificador> ::= letter {letter digit <tipo> ::= tipos válidos do Java Figura 14: Estrutura do ponto de atuação Para definir pointcuts utilizamos construtores de AspectJ chamados designadores de pointcut (pointcut designators), como os apresentados na figura 15. Em que Padrão Tipo é uma construção que pode definir um conjunto de tipos podendo utilizar wildcards. Designador Significado call(assinatura) Chamada de método ou construtor execution(assinatura) Execução de método ou construtor get(assinatura) Leitura de dado de Classe set(assinatura) Escrita de dado de Classe this(padrão Tipo) Compreende todos os pontos de junção de um objeto ou classe definida em Padrão Tipo ou de qualquer subclasse da mesma. A diferença para within é basicamente que within é calculado em tempo de compilação e this em tempo de execução, e within não inclui subclasses. args(padrão Tipo) Define o tipo de argumento descrito por Padrão Tipo handler (Padrão Tipo) Tratamento de exceção, Padrão Tipo define o tipo de exceção within(padrão Tipo) Todos os join points que ocorrem dentro da classe descrita por Padrão Tipo withincode(assinatura) Todos os join points que ocorrem dentro dos métodos contidos na declaração de Assinatura Figura 15: Designadores de pointcuts Pointcuts de fluxo de controle Para fluxo de controle existem dois tipos de pointcuts específicos. Um fluxo de controle consiste de todos os comandos que são executados entre a entrada em um método e a saída deste, inclusive considerando os comandos em métodos chamados pelo primeiro. Caractere cflow(pointcut) cflowbelow(pointcut) Descrição Todos os pontos de junção que ocorrem durante o pointcut especificado, incluindo a própria chamada. Todos os pontos de junção que ocorrem durante o pointcut especificado, não incluindo a própria execução.

28 28 Figura 16: Pointcuts de fluxo de controle A lista completa de wildcards e pointcut designators pode ser encontrada no guia de programação de AspectJ [10] Pointcuts genéricos Utilizando wildcards podemos criar designadores genéricos, dessa forma delimitamos uma maior quantidade de pontos junção a serem interceptados. Designador call (* set*(..)) execution(public * Pessoa.*(..)) call(*.new(int, int)) call(* dao..*(..)) call(pessoadao+.new(..)) set(* Pessoa.*) Figura 17: Pointcuts genéricos Significado Chamada a qualquer método que inicie com set e possua quaisquer parâmetros Execução de qualquer método público da classe Pessoa Chamada a qualquer construtor que possua somente dois inteiros como parâmetros Chamada a qualquer método dentro do diretório e subdiretórios de dao Todos os construtores da classe de PessoaDAO e suas subclasses. Se PessoaDAO for uma interface, somente os construtores de quem a implementa. Qualquer alteração de um atributo da classe Pessoa A figura 18 mostra um exemplo de pointcut completo. Nesse exemplo podemos claramente observar as vantagens dos wildcards, nesse caso temos um pointcut nomeado ( buscalista ) que atuará na chamada ( call ) de qualquer Método (* *.*) com quaisquer argumentos ( (..) ) que esteja anotado com a interface MetodoRecuperaLista. Pointcut buscalista() : call(@metodorecuperalista * *.*(..)) ; Figura 18: Exemplo 1 de pointcut genérico Na figura 19 temos um pointcut nomeado ( transacao ) que atuará na chamada de qualquer método que esteja localizado em qualquer classe dentro do diretório (package) ou subdiretório de service. Pointcut transacao() : call(@transacional * service..*.*(..)); Figura 19: Exemplo 2 de pointcut genérico

29 Pointcuts nomeados Pointcuts podem ser nomeados ou não, com pointcuts nomeados aumentamos a clareza e o reaproveitamento de regras de corte, podemos sem restrições fazer a seguinte estrutura: pointcut pointcut1() : call(* service.identificacao.*(..)) call(* service.aluno.*(..)); pointcut pointcuta() : call(* service.identificacao.*(..)) ; poitcut pointcutb() : call(* service.aluno.*(..)); pointcut pointcut2() : pointcuta() pointcutb(); Figura 20: Pointcuts nomeados, equivalência A figura 20 mostra a equivalência entre pointcut2() e pointcut1(). Esse tipo de associação é interessante quando utilizamos um pointcut ou parte dele em lugares diferentes do código em AspectJ. 2.7 Adendos (Advices) Enfim chegamos ao advice. Ele é o elemento mais importante da POA, similar a um método de uma classe, o adendo é para aspecto. Possui parâmetros e um conjunto de instruções a ser executado. Diferente de um método comum o advice utiliza-se de pointcuts para que ocorra sua execução nos locais designados pelos join points desses pointcuts. Nos adendos são definidos os interesses ortogonais propriamente ditos. Uma forma fácil de montar um raciocínio para se chegar a um adendo completo é baseada em três pequenos passos: o primeiro passo é descrever os pontos de atuação em que são definidas as regras de captura dos pontos de junção; segundo é escolher o tipo de adendo para o qual se deseja que ocorra no fluxo de execução (antes, durante, depois); em terceiro é implementar o interesse (fazer o código) que será inserido conforme o segundo passo no local especificado pelo primeiro passo. Vejamos um conjunto de advice completos para uma simples implementação de controle de transação.