Temel Kimyasal Kompozisyon

Os recursos para defini¸c˜ao de pointcuts `a disposi¸c˜ao nas linguagens atuais atendem `a maioria das necessidades. Muitas vezes, entretanto, eles n˜ao permitem criar pointcuts de boa qualidade, tanto no que se refere `a resistˆencia a mudan¸cas quanto `a clareza.

O problema da resistˆencia a mudan¸cas ´e bem conhecido e estudado, e recebeu o nome de pro- blema do pointcut fr´agil (fragile pointcut problem [28]). A quest˜ao da clareza n˜ao recebeu um nome espec´ıfico, talvez por ter menos trabalhos a seu respeito.

Apresentamos nesta se¸c˜ao alguns exemplos de problemas que evidenciam a necessidade de melho- ramentos no modelo de pointcuts das linguagens orientadas a aspectos. Apresentamos tamb´em uma solu¸c˜ao poss´ıvel para cada um desses problemas na linguagem orientada a aspectos mais popular, o AspectJ.

3.1.1 Editor de figuras

Um dos exemplos mais utilizados em trabalhos sobre programa¸c˜ao orientada a aspectos [7, 13, 23, 26, 30] ´e o de uma hipot´etica aplica¸c˜ao gr´afica [2]. Nessa aplica¸c˜ao, existem diversos elementos gr´aficos, como linhas e retˆangulos, representados por classes. Quando ´e chamado um m´etodo que altera o estado de uma instˆancia de alguma dessas classes, o m´etodo redraw() deve ser chamado para atualizar a exibi¸c˜ao do elemento. Na figura 3.1, vemos o diagrama UML [32] desse editor de figuras.

14 CAP´ITULO 3. SELETORES DE PONTOS DE JUNC¸ ˜AO

Figura 3.1: Diagrama UML do editor de figuras

Embora seja usado como exemplo de aplica¸c˜ao da Programa¸c˜ao Orientada a Aspectos, este pro- blema ´e tamb´em um bom exemplo das limita¸c˜oes dessas linguagens. A listagem 3.1 mostra duas poss´ıveis solu¸c˜oes para o problema, em AspectJ.

Listagem 3.1 Solu¸c˜oes para o editor de figuras em AspectJ

aspect D i s p l a y U p d a t i n g { pointcut move ( ) : c a l l ( void L i n e . s e t P 1 ( P o i n t ) ) | | c a l l ( void L i n e . s e t P 2 ( P o i n t ) ) | | c a l l ( void P o i n t . setX ( i n t ) ) | | c a l l ( void P o i n t . setY ( i n t ) ) ; a f t e r ( ) returning : move ( ) { D i s p l a y . redraw ( ) ; } } aspect D i s p l a y U p d a t i n g { pointcut move ( ) : c a l l ( void F i g u r e E l e m e n t +. s e t ∗ ( . . ) ) ; a f t e r ( ) returning : move ( ) { D i s p l a y . redraw ( ) ; } }

Na primeira solu¸c˜ao, todos os m´etodos que afetam as figuras s˜ao enumerados no pointcut. Se um programador adicionar um novo m´etodo que altera o estado de uma figura e n˜ao alterar o pointcut, este deixar´a de ser completamente efetivo. O mesmo ocorre se for criada uma nova subclasse de FigureElement.

3.1. MOTIVAC¸ ˜AO 15 A segunda solu¸c˜ao ´e mais gen´erica, pois inclui qualquer subtipo de FigureElement, e seleciona todos os m´etodos cujo nome se inicia por “set”. Neste caso, a adi¸c˜ao de um novo m´etodo j´a n˜ao quebra o pointcut, desde que o programador siga a conven¸c˜ao de iniciar o m´etodo por “set”. Se o m´etodo, no entanto, for chamado, por exemplo, de change(), ele n˜ao ser´a inclu´ıdo no pointcut. Em nenhum dos casos, o pointcut transmite ou implementa diretamente a inten¸c˜ao do programador, que era capturar todas as mudan¸cas de estado das figuras.Este problema, embora pare¸ca espec´ıfico, na verdade representa uma classe ampla de situa¸c˜oes `as quais a programa¸c˜ao orientada a aspectos pode ser aplicada. Genericamente, podemos descrever essa classe como aquela dos problemas em que ´e necess´ario tomar ou n˜ao uma a¸c˜ao com base nas a¸c˜oes efetuadas em certo fluxo de controle.

Isso pode incluir a persistˆencia de um objeto se o seu estado foi alterado, o fechamento de uma conex˜ao de rede caso ela tenha sido aberta, ou a nega¸c˜ao de acesso a um m´etodo que poderia fazer uma altera¸c˜ao n˜ao autorizada no sistema. Este ´ultimo caso difere um pouco pelo fato de se basear em atos no futuro, ou seja, o adendo tem que agir antes que as altera¸c˜oes em quest˜ao efetivamente ocorram. A se¸c˜ao 3.1.2 ilustra essa situa¸c˜ao.

3.1.2 Seguran¸ca

O exemplo da listagem 3.2, extra´ıdo (com modifica¸c˜oes) de [28], ilustra um aspecto de controle de acesso a uma lista de compras. A inten¸c˜ao do programador ´e impedir que um cliente altere a lista de outro.

Suponha agora que foi adicionado um novo recurso `a aplica¸c˜ao de compras, o qual permite a um cliente compartilhar a sua cesta de compras com seus amigos, como uma “lista de desejos”. Esta funcionalidade ´e implementada por um novo m´etodo na classe ShoppingCart, chamado showItems(), que permite listar o seu conte´udo. Da forma como est´a implementado o aspecto de autoriza¸c˜ao, a nova funcionalidade n˜ao vai funcionar corretamente, pois ele vai impedir o acesso do amigo `a cesta, devido ao nome do m´etodo.

Para resolver o problema, seria necess´ario alterar o pointcut, passando a enumerar todos os m´etodos que alteram a cesta. Nesse caso, entretanto, se fosse criado um novo m´etodo de altera¸c˜ao da cesta que n˜ao estivesse listado no pointcut, a cesta estaria desprotegida. No caso do pointcut com defini¸c˜ao via coringa (“*”), esse risco tamb´em existe, mas ´e menor se as conven¸c˜oes forem seguidas.

16 CAP´ITULO 3. SELETORES DE PONTOS DE JUNC¸ ˜AO

Listagem 3.2 Um aspecto de controle de acesso a uma lista de compras

public c l a s s ShoppingCart { private S e t i t e m s ;

private double t o t a l ; public Customer c u sto m e r ;

ShoppingCart ( Customer c u s to m e r ) { t h i s . c u st o m e r = c u s to m e r ; i t e m s = new HashSet ( ) ; t o t a l = 0 . 0 ;

}

public void addItem ( I n t e g e r itemNr ) { i t e m s . add ( itemNr ) ;

t o t a l += Database . l o a d P r i c e ( itemNr ) ; }

public void removeItem ( I n t e g e r itemNr ) { i t e m s . remove ( itemNr ) ;

t o t a l −= Database . l o a d P r i c e ( itemNr ) ; }

}

public abstract aspect ItemChanges {

pointcut itemChanges ( Customer c , ShoppingCart s ) :

t h i s ( c ) && target ( s ) && c a l l ( ∗ ShoppingCart . ∗ Item ( . . ) ) ; }

p u b l i c aspect A u t h o r i z a t i o n extends ItemChanges {

before ( Customer c , ShoppingCart s ) : itemChanges ( c , s ) { i f ( ! mayAccess ( c , s ) ) {

throw new A c c e s s E x c e p t i o n ( ” I l l e g a l A c c e s s − d e n i e d . ” ) ; }

}

private boolean mayAccess ( Customer c , ShoppingCart s ) { return c . e q u a l s ( s . c u s to m e r ) ;

} }

3.1. MOTIVAC¸ ˜AO 17

3.1.3 Aspectos para Web Services

Aqui mostramos um exemplo de como um modelo de pointcuts mais rico pode ser ben´efico, mesmo em problemas cuja solu¸c˜ao seria poss´ıvel nas linguagens orientadas a aspectos convencionais.

Em [33], os autores prop˜oem uma linguagem orientada a aspectos espec´ıfica (uma DSL, “do-

main specific language”) para o processamento de XML em Web Services. Essa linguagem, deno-

minada Doxpects, permite a defini¸c˜ao de pointcuts que especifiquem elementos de XML trocados em opera¸c˜oes remotas com Web Services, para facilitar opera¸c˜oes sobre esses elementos atrav´es de adendos. Essencialmente, a linguagem define dois novos tipos de pointcuts primitivos: header e body, correspondendo ao cabe¸calho e ao conte´udo de uma mensagem SOAP. Estes pointcuts podem receber como parˆametro uma consulta XPath [8], que seleciona um conjunto de elementos em um documento XML.

Al´em destes dois pointcuts, a linguagem Doxpects define dois qualificadores para os adendos:

request e response. Embora os autores fa¸cam analogia entre esses qualificadores e os modificadores before e after do AspectJ, podemos considerar um qualificador request ou response como parte da

defini¸c˜ao do pointcut, pois a linguagem define que o adendo ser´a executado sempre antes do envio da requisi¸c˜ao ou recebimento de resposta. Esse qualificador, po rtanto, na verdade determina se ser´a em um caso ou no outro.

Na listagem 3.3, vemos um exemplo de um pointcut na linguagem Doxpects. Listagem 3.3 Um pointcut na linguagem Doxpects

r e q u e s t each ( Address anAddress ) : body ( / / Address , anAddr ess )

Esse pointcut seleciona todos os elementos XML do tipo “Address” presentes em mensagens enviadas como requisi¸c˜ao (isso ´e feito pela da consulta XPath “//Address”). A seguir, cria objetos do tipo Address com as informa¸c˜oes desses elementos e torna esses objetos dispon´ıveis atrav´es da vari´avel anAddress.

A implementa¸c˜ao desse tipo de aspecto em uma linguagem orientada a aspectos tradicional seria mais complicada. Ela poderia depender de especificidades do arcabou¸co utilizado para a imple- menta¸c˜ao dos Web Services, pois as linguagens de pointcuts tradicionais lidam com n´ıveis mais baixos de abstra¸c˜ao. Talvez mais importante do que isso ´e a eleva¸c˜ao do n´ıvel de abstra¸c˜ao que essa abordagem traz: o programador n˜ao precisa mais pensar nos m´etodos que implementam o protocolo

18 CAP´ITULO 3. SELETORES DE PONTOS DE JUNC¸ ˜AO

Figura 3.2: O funcionamento de um seletor

em um determinado arcabou¸co, mas sim nas mensagens que comp˜oem esse protocolo.