Teoria Informal sobre Aspectos

Segundo Masuhara e Kiczales [MK03], n˜ao existe um consenso em rela¸c˜ao ao que torna uma t´ecnica orientada por aspectos. Diante deste contexto, Masuhara e Kiczales a- presentam um arcabou¸co para modelar a semˆantica b´asica de quatro tecnologias de desenvolvimento de software orientado por aspectos e seus mecanismos. Na Tabela

2.1, essas tecnologias s˜ao relacionadas com suas respectivas implementa¸c˜oes.

Masuhara e Kiczales [MK03] tentam caracterizar quais propriedades de cada meca- nismo permite a modulariza¸c˜ao dos interesses transversais. Uma propriedade cr´ıtica de seu arcabou¸co ´e que ele modela os pontos de jun¸c˜ao como pontos existentes no resultado do processo de combina¸c˜ao em vez de em um dos programas de entrada. Ademais, o trabalho de Masuhara e Kiczales destaca-se por outras duas raz˜oes. Primeiro, ele trata componentes e aspectos uniformemente, assumindo que n˜ao h´a linguagem de compo-

2.3. Programac¸˜ao Orientada por Aspectos 17

Tecnologia Implementa¸c˜ao

Composi¸c˜ao de classes Hyper/J

Especifica¸c˜oes transversais DAJ, DemeterJ, DemeterC++ Classes abertas(open classes) AspectJ, MultiJava

Conjunto de Jun¸c˜ao e Adendo AspectJ, AspectC++, AspectWerz, Pythius

Tabela 2.1: Tecnologias do desenvolvimento de software orientado por aspectos

nentes prim´aria nem dicotomia baseada aspecto, ou seja, n˜ao existe uma distin¸c˜ao clara entre componentes e aspectos. Segundo, ele permite a descri¸c˜ao de aspectos que afetam outros aspectos naturalmente.

Chavez e Lucena [CL03] prop˜oem um arcabou¸co conceitual para a programa¸c˜ao ori- entada por aspectos que oferece uma terminologia consistente e uma semˆantica b´asica para pensar sobre um problema em termos dos conceitos e propriedades que caracteri- zam o estilo da POA como um paradigma emergente de desenvolvimento de software. Esse arcabou¸co ´e chamado de modelo de aspectos e subdivide-se entre quatro modelos conceituais inter-relacionados: (i) o modelo de componentes, (ii) o modelo de pon- tos de jun¸c˜ao, (iii) o modelo principal e (iv) o modelo de processo de combina¸c˜ao. A Figura2.7ilustra o modelo de aspectos. Assim, definiu-se que uma linguagem orientada por aspectos ´e uma linguagem que oferece suporte ao modelo de aspectos.

Linguagem de Aspecto Modelo de Componentes Modelo de Aspecto Modelo de Ponto de Junção Modelo de Processo de Combinação * especifica suporta adota adota refere−se a adota Regra do Aspecto Conceito Principal do Aspecto * * restrigem Transversalidade Aspecto 1..* define 1..* Modelo Principal

Figura 2.7: Modelo de Aspecto [CL03]

Nas pr´oximas se¸c˜oes, descrevem-se os modelos conceituais. Utilizaram-se diagramas de classes para representar cada modelo conceitual em termos dos principais conceitos

envolvidos.

2.3.3.1 O Modelo de Componentes

O modelo de componentes representa um arcabou¸co conceitual usado para pensar sobre um problema e decompˆo-lo em termos de um determinado tipo de componente [CL03]. Esse arcabou¸co consiste em categoria de conceitos principais (mecanismos de com- posi¸c˜ao e componentes), regras que restringem elementos dessas categorias e um con- junto de princ´ıpios gerais.

Por exemplo, no modelo de objetos, os principais conceitos s˜ao objetos, classes e heran¸ca. Java e C++ s˜ao linguagens de programa¸c˜ao orientadas por objetos uma vez que seu arcabou¸co conceitual ´e o modelo de objetos, ou seja, ambas oferecem suporte ao modelo de objetos.

Um modelo de componentes pode ter suporte a uma ou mais linguagens de compo- nentes. A Figura2.8 ilustra um diagrama de classes para o modelo de componentes.

Linguagem de Componentes Modelo de Componentes Componente Mecanismo de Composição Conceito Principal do Componente relaciona suporta 1..* * _especifica Regras do Componente restrigem 1..*

Figura 2.8: Modelo de componentes [CL03]

2.3.3.2 O Modelo de Pontos de Jun¸c˜ao

A POA oferece mecanismos para que os aspectos possam ser constru´ıdos em m´odulos separados e provˆe meios para a defini¸c˜ao de pontos do programa onde esses aspectos possam definir algum comportamento. A partir da´ı, o sistema final pode ser obtido, combinando os m´odulos b´asicos com os aspectos. Dessa forma, a POA pretende dar suporte aos interesses transversais assim como a POO tem dado suporte aos obje- tos [KHH+

2.3. Programac¸˜ao Orientada por Aspectos 19

O modelo de ponto de jun¸c˜ao (MPJ) representa um arcabou¸co conceitual usado para descrever os tipos de pontos de jun¸c˜ao de interesse e as restri¸c˜oes associadas a seu uso. Esse arcabou¸co ´e altamente dependente do modelo de componentes adotado. A Figura 2.9 apresenta um diagrama de classes para o modelo de pontos de jun¸c˜ao.

Aspecto Componentes Ponto de Junção Dinâmico Ponto de Junção Estático Ponto de Junção * * afeta Programa de Componente localizado em Especificação do Ponto de Junção 1..* * * denota

Figura 2.9: Modelo de Pontos de Jun¸c˜ao, adaptado de [CL03]

De acordo com Masuhara et al. [MKD03] a capacidade de uma linguagem de as- pectos suportar a modulariza¸c˜ao de interesses transversais ´e determinada pelo MPJ. Um MPJ consiste, basicamente, em trˆes elementos: (i) pontos de jun¸c˜ao, (ii) meios que identifiquem um ponto de jun¸c˜ao e (iii) meios que especifiquem semˆantica em um ponto de jun¸c˜ao.

Pontos de Jun¸c˜ao (Join Point) s˜ao posi¸c˜oes bem definidas na execu¸c˜ao de um programa, como, chamadas e execu¸c˜oes de m´etodos ou leitura e escrita de campos. Os pontos de jun¸c˜ao podem tamb´em possuir contexto associado. Por exemplo, o contexto de um ponto de jun¸c˜ao de chamada de m´etodo cont´em o objeto alvo da chamada e a lista de argumentos. Masuhara et al. destacam que pontos de jun¸c˜ao n˜ao s˜ao necessariamente constru¸c˜oes expl´ıcitas da linguagem de componentes, s˜ao elementos claros, mas talvez impl´ıcitos, da semˆantica do programa de componentes. Desta forma, um ponto de jun¸c˜ao pode denotar um elemento relacionado `a estrutura est´atica ou dinˆamica de um programa de componente. Como o exemplo do manipulador de figuras, Se¸c˜ao2.2, em que o ponto de jun¸c˜ao seria o fluxo de dados do programa de componente. Um ponto de jun¸c˜ao est´atico (static join point) ´e um local na estrutura est´atica de um componente, enquanto que um ponto de jun¸c˜ao dinˆamico (dynamic join point) ´e um local no comportamento dinˆamico de um programa de componente. Um ponto de jun¸c˜ao dinˆamico possui uma sombra est´atica (static shadow ) correspondente na parte estrutural do componente. Um sombra est´atica [HH04] ´e uma regi˜ao no componente que representa um ponto de combina¸c˜ao dinˆamico relacionado a tal componente.

Meios que identifiquem um Ponto de Jun¸c˜ao: um conjunto de jun¸c˜ao (point- cut) seleciona pontos de jun¸c˜ao e exp˜oe dados do contexto de execu¸c˜ao desses pontos. Eles podem ser compostos por opera¸c˜oes de conjunto (uni˜ao, interse¸c˜ao e diferen¸ca) a fim de criar outros conjuntos de jun¸c˜ao [WKD04]. Um designador de conjunto de jun¸c˜ao ´e uma f´ormula que especifica um conjunto de pontos de jun¸c˜ao ao qual um adendo (advice) pode ser aplicado.

H´a muitos locais na estrutura ou comportamento de componentes que podem ser usados como conjunto de jun¸c˜ao, mas, na pr´atica, somente um subconjunto ´e conside- rado ´util [OT98]. As linguagens orientadas por aspectos devem definir seu conjunto de jun¸c˜ao levando em considera¸c˜ao sua linguagem de componentes correspondente.

Meios que especifiquem semˆantica em um Ponto de Jun¸c˜ao: um adendo compreende o comportamento de aspectos que deve ser executado em cada ponto de jun¸c˜ao. Um adendo ´e composto de um conjunto de jun¸c˜ao e um bloco de c´odigo. Quando o ponto de jun¸c˜ao ´e capturado pelo conjunto de jun¸c˜ao o bloco de c´odigo ´e executado.

2.3.3.3 O Modelo Principal

Segundo Chavez e Lucena [CL03], o modelo principal representa um arcabou¸co con- ceitual usado para descrever aspectos, como um mecanismo de abstra¸c˜ao, e transver- salidade, como um mecanismo de composi¸c˜ao.

Aspectos, em [KLM+

97], s˜ao definidos como “propriedades de um sistema, no qual a implementa¸c˜ao n˜ao pode ser encapsulada em um procedimento generalizado”. Assim, podem-se definir os aspectos como propriedades sistˆemicas que afetam os componentes causando espalhamento e entrela¸camento de interesses. Utiliza-se, tamb´em, o termo aspecto para denotar uma entidade de primeira classe que oferece uma representa¸c˜ao modular para um interesse transversal.

Transversalidade ´e definida como um fenˆomeno observado sempre que duas pro- priedades programadas devem compor de forma diferente e, mesmo assim, serem co- ordenadas. Al´em disso, a transversalidade ´e restrita a um conjunto pr´e-definido de pontos especificados por um MPJ e, desta forma, pode ser subdivida em transversali- dade dinˆamica e est´atica.

A transversalidade dinˆamica consiste em introduzir novos comportamentos na e- xecu¸c˜ao dos componentes, ou seja, ´e um tipo de transversalidade que utiliza pontos de jun¸c˜ao dinˆamicos e afeta o comportamento dinˆamico dos componentes. A trans- versalidade est´atica consiste em introduzir modifica¸c˜oes nas estruturas est´aticas dos componentes, sendo assim, um tipo de transversalidade que utiliza pontos de jun¸c˜ao est´aticos e, portanto, afeta a estrutura est´atica dos componentes.