1

- um paradigma de programao de computadores que permite aos

desenvolvedores de software separar e organizar o cdigo de acordo com a sua
importncia para a aplicao (separation of concerns).
-Foi desenvolvida nos laboratrios da Xerox, por uma diviso de pesquisa
denominada Xerox PARC, em 1997.
-A idealizao da linguagem se deve a Gregor Kiczales, professor da University
of British Columbia no Canad.
-Atualmente mantida pela Fundao Eclipse, detentora de alguns projetos de
cdigo aberto, sendo integrado na ferramenta de desenvolvimento Eclipse(IDE).

-Para se fazer um sistema, visando resolver um problema, uma abordagem

comum dividir em partes menores e tratar cada parte separadamente. Esta
tcnica chama-se separao de interesses.
-Ao projetar um sistema, trabalhamos com diversos interesses (ou concerns).
Na programao orientada a objetos o modelo de abstrao trabalha com
classes como unidades. No projeto procura-se separar cada interesse em uma
classe distinta, porm nem sempre isso possvel. Linguagens de
programao procedurais e as orientadas a objetos no possuem tcnicas
suficientemente claras para implementar algumas decises de projetos, sem que
alguns de seus conceitos e regras sejam transgredidos. O que fora a
implementao destas decises de projeto a serem espalhadas atravs do
cdigo, gerando um cdigo confuso e difcil de desenvolver e manter. Estas
decises de projeto so difceis de serem tratadas porque elas vo alm das
funcionalidades bsicas do sistema, ou seja, no possvel separ-la em um
componente ou uma classe, pois ela pertence a todo sistema.
-Quando os interesses aparecem misturados numa mesma classe chama-se
entrelaamento;
-E quando um nico interesse aparece espalhado em diversas classes chamase espalhamento.

-Para aqueles interesses que no podem ser modularizados em classes d-se

o nome de interesses transversais.
A programao orientada a aspectos foi criada para resolver a
implementao destes interesses transversais para os sistemas modelados
com orientao a objetos. Usando AOP possvel separar estes interesses em
unidades chamadas aspectos.

-ROJAS (2011), vide Figura, afirma que a programao orientada a aspectos

permite facilitar a compreenso do cdigo-fonte do software, devido reduo
na parte onde so programadas as regras de negcio.
-SOMMERVILLE (2007, p.516), a programao orientada a aspectos tem o
conceito de assuntos, aonde estes vm de requisitos de sistema, que deve ser
adotada em todos os estgios do desenvolvimento do sistema. A identificao e
a modelagem de assuntos devem ser parte dos processos de engenharia de
requisitos e de projeto. A programao orientada a aspectos permite uma
melhor separao de assuntos que tratam o software, como partes de algo
maior.

Diferena na Organizao, em relao a POO e POA

-O que diferencia AspectJ das demais linguagens de programao o fato de

no ser possvel construir programas usando somente o AspectJ, sendo
necessrio tambm utilizar outra linguagem.
-Isso vem da prpria ideia do paradigma da orientao Aspectos, que
customizar programas e solucionar problemas.
-De certa forma podemos dizer que AspectJ uma extenso da linguagem Java,
pois usa todos os recursos da linguagem e acrescenta recursos de POA.

O AspectJ possui classes como na linguagem Java, porm com mais recursos
ao desenvolvedor, essas classes so chamados de Aspects. Os aspectos tem
entidades especiais que no existem nas classes Java comuns, so elas:
Join points
Pointcuts
Advice
Os principais conceitos na programao de aspectos so:
-> joinpoints - representam eventos de interesse do fluxo de execuo. Quando
a execuo passa por um joinpoint o aspecto pode agir naquele ponto. Exemplo
de joinpoints: invocao de mtodos, alterao de atributos e excees.
-> pointcuts - usados para representar um conjunto de joinpoints, pois podem
acontecer muitas ocorrncias de joinpoints de um mesmo tipo. O AspectJ
[ASPECTJ] utiliza expresses regulares na definio de pointcuts.
-> advices - so os procedimentos realizados quando os pointcuts so ativados.
Os advices podem ser executados antes (before), depois (after) ou em
substituio ao joinpoint. Advices so a implementao dos interesses
transversais.

Talvez o leitor entenda melhor estes conceitos se pensar que aspectos so

estruturas semelhantes a classes, advices so semelhantes a mtodos,
joinpoints seriam atributos e os pointcuts algo como triggers (gatilhos) sobre os
joinpoints.

Com o intuito de manter o histrico do cliente as operaes de crdito e dbito

devem ser auditadas. Esta auditoria deve ser realizada em dois momentos:
antes da execuo da ao e aps a execuo da ao.

10

Fonte: BERTAGNOLLI, 2004 p51

11

12

13

Caso a aplicao sofra uma redefinio, por exemplo a auditoria deve ser
aplicada somente antes da execuo do mtodo, no modelo orientado a objetos,
necessrio percorrer toas as classes e alterar o cdiogo.
Isto pode gerar inconsistncias, por exemplo, a eliminao de cdigo no ser
completa.
Por outro lado, com o suso de aspectos, basta alterar o aspecto para tger
certeza de que a alterao ser refletida nas diversas classes com ele
relacionadas

14

15

16

17