1

-É um paradigma de programação de computadores que permite aos desenvolvedores de software separar e organizar o código de acordo com a sua importância para a aplicação (separation of concerns).

-Foi desenvolvida nos laboratórios da Xerox, por uma divisão de pesquisadenominada Xerox PARC, em 1997.

-A idealização da linguagem se deve a Gregor Kiczales, professor da Universityof British Columbia no Canadá.

-Atualmente é mantida pela Fundação Eclipse, detentora de alguns projetos decódigo aberto, sendo integrado na ferramenta de desenvolvimento Eclipse(IDE).

2

-Para se fazer um sistema, visando resolver um problema , uma abordagem comum é dividir em partes menores e tratar cada parte separadamente . Esta técnica chama-se separação de interesses .

-Ao projetar um sistema, trabalhamos com diversos interesses (ou concerns). Na programação orientada a objetos o modelo de abstração trabalha com classes como unidades. No projeto procura-se separar cada interesse em uma classe distinta, porém nem sempre isso é possível . Linguagens de programação procedurais e as orientadas a objetos não possuem técnicas suficientemente claras para implementar algumas decisões de projetos, sem que alguns de seus conceitos e regras sejam transgredidos. O que força a implementação destas decisões de projeto a serem espalhadas através do código, gerando um código confuso e difícil de desenvolver e manter. Estas decisões de projeto são difíceis de serem tratadas porque elas vão além das funcionalidades básicas do sistema, ou seja, não é possível separá-la em um componente ou uma classe, pois ela “pertence” a todo sistema.

-Quando os interesses aparecem misturados numa mesma classe chama-se entrelaçamento ;

-E quando um único interesse aparece espalhado em diversas classes chama-se espalhamento .

3

-Para aqueles interesses que não podem ser modularizados em classes dá-se o nome de interesses transversais .

A programação orientada a aspectos foi criada para resolver a implementação destes interesses transversais para os sistemas modelados com orientação a objetos. Usando AOP é possível separar estes interesses em unidades chamadas aspectos.

4

-ROJAS (2011), vide Figura, afirma que a programação orientada a aspectos permite facilitar a compreensão do código-fonte do software, devido à redução na parte onde são programadas as regras de negócio.

-SOMMERVILLE (2007, p.516), a programação orientada a aspectos tem o conceito de assuntos , aonde estes vêm de requisitos de sistema, que deve ser adotada em todos os estágios do desenvolvimento do sistema. A identificação e a modelagem de assuntos devem ser parte dos processos de engenharia de requisitos e de projeto. A programação orientada a aspectos permite uma melhor separação de assuntos que tratam o software, como partes de algo maior.

5

Diferença na Organização, em relação a POO e POA

6

-O que diferencia AspectJ das demais linguagens de programação é o fato denão ser possível construir programas usando somente o AspectJ, sendonecessário também utilizar outra linguagem.

-Isso vem da própria ideia do paradigma da orientação à Aspectos, que écustomizar programas e solucionar problemas.

-De certa forma podemos dizer que AspectJ é uma extensão da linguagem Java,pois usa todos os recursos da linguagem e acrescenta recursos de POA.

7

O AspectJ possui “classes” como na linguagem Java, porém com mais recursosao desenvolvedor, essas “classes” são chamados de Aspects. Os aspectos tementidades especiais que não existem nas classes Java comuns, são elas:

Join points

Pointcuts

Advice

Os principais conceitos na programação de aspectos são:

-> joinpoints - representam eventos de interesse do fluxo de execução. Quando a execução passa por um joinpoint o aspecto pode agir naquele ponto. Exemplo de joinpoints: invocação de métodos, alteração de atributos e exceções.

-> pointcuts - usados para representar um conjunto de joinpoints, pois podem acontecer muitas ocorrências de joinpoints de um mesmo tipo. O AspectJ [ASPECTJ] utiliza expressões regulares na definição de pointcuts.

-> advices - são os procedimentos realizados quando os pointcuts são ativados. Os advices podem ser executados antes (before), depois (after) ou em substituição ao joinpoint. Advices são a implementação dos interesses transversais.

8

Talvez o leitor entenda melhor estes conceitos se pensar que aspectos são estruturas semelhantes a classes, advices são semelhantes a métodos, joinpoints seriam atributos e os pointcuts algo como triggers (gatilhos) sobre os joinpoints.

9

Com o intuito de manter o histórico do cliente as operações de crédito e débito devem ser auditadas. Esta auditoria deve ser realizada em dois momentos: antes da execução da ação e após a execução da ação.

10

Fonte: BERTAGNOLLI, 2004 – p51

11

12

13

Caso a aplicação sofra uma redefinição, por exemplo a auditoria deve ser aplicada somente antes da execução do método, no modelo orientado a objetos, é necessário percorrer toas as classes e alterar o códiogo.

Isto pode gerar inconsistências, por exemplo, a eliminação de código não ser completa.

Por outro lado, com o suso de aspectos, basta alterar o aspecto para tgercerteza de que a alteração será refletida nas diversas classes com ele relacionadas

14

15

16

17