Programação orientada a aspectos

Este artigo foi escrito com base num projecto desenvolvido no ISCTE, em 2009, com o nome “Aplicação de auxílio à depuração e rastreabilidade com Programação Orientada por Aspectos (AspectJ)” sob orientação do professor Manuel Menezes de Sequeira. Os co-autores são David Jardim e Jairo Avelar.


Introdução

Um dos paradigmas de programação mais populares actualmente é a de orientação por objectos.

Este paradigma ausa e interliga estruturas de dados (os “objectos”) constituídos por variáveis e métodos para desenhar e desenvolver aplicações informáticas cada vez mais complexas e distribuídas. Tal paradigma, possibilita a utilização de metodologias de auxílio à programação tais como a herança, o polimorfismo e as interfaces.

Durante os ciclos de desenvolvimento e de manutenção de aplicações (parte que se pode denominar por Engenharia do Software) , existe um conjunto de normas e regras que devem ser respeitados para assegurar a fiabilidade e qualidade do produto1 (correcção).

Sintaxe e semântica

Por exemplo, um dos conceitos mais importantes diz respeito à diferença entre a sintaxe e a semântica do código fonte presente nos vários módulos aplicacionais.

É bastante importante saber diferenciar estes dois conceitos.

Enquanto que a sintaxe diz respeito ao formato usado pelas linguagem de programação, a semântica indica-nos como as aplicações se comportam quando executadas num determinado ambiente.

Apesar da sintaxe influenciar a forma como codificamos um programa (uma vez que os comandos disponíveis numa linguagem tendem a variar  – ainda que ligeiramente – de uma linguagem para outra), a semântica reflecte, na prática, o significado dos conceitos e como estes devem ser entendidos pelos membros da equipa de desenvolvimento.

Compiladores

Usamos compiladores, integrados em ambientes de desenvolvimento, para garantir uma sintaxe correcta. Já no que diz respeito à semântica, usamos muitas vezes depuradores  (debuggers) para evitar comportamentos incorrectos (i.e., diferentes da especificação) cujos efeitos podem ser imprevisíveis.

Contudo, os depuradores convencionais têm bastante limitações funcionais, uma vez que  apenas permitem inspeccionar o estado de execução de um determinado programa em pontos específicos – pontos de interrupção (breakpoints) e são praticamente inúteis em ambientes distribuídos2.

Registo de dados (Logging)

Desta forma, foi necessário desenvolver um conjunto de outras técnicas que permitissem compreender o comportamento dos programas para que assim seja possível alinhar a especificação de requisitos com a sua execução.

O registo de dados (logging) ao permitir conhecer o comportamento de um sistema, tipicamente através de ficheiros de dados com registos de eventos, é muito usada em sistemas de Auditoria Informática.

De uma forma simplista, este método regista num determinado suporte (e.g. ficheiros de texto), mensagens com descrições das operações realizadas por um determinado programa. Estas mensagens são registadas com o instante temporal onde ocorreram e armazenadas por ordem cronológica.

Ao inspeccionar o registo (log) produzido pelo sistema, é possível ter uma percepção clara da forma de funcionamento do programa e, detectar eventuais não conformidades com a sua especificação, i.e., defeitos de implementação.

Tal análise é possível mesmo depois da execução do programa ter terminado ou mesmo depois de vários dias de execução contínua (no caso de sistemas distribuídos, por exemplo).

História da Programação Orientada a Aspectos

A programação orientada por aspectos surgiu de um projecto de investigação levado a cabo no Xerox PARC (Palo Alto Research Center, Califórnia, EUA) e iniciado nos anos 803.

A programação orientada por aspectos não pretende substituir a programação orientada por objectos; pelo contrário, surge como um paradigma complementar à POO.

Em Março de 1998, surgia a primeira implementação da POA, o AspectJ, que desde então têm evoluído significativamente, sendo hoje em dia considerada uma versão bastante mais robusta e madura.

Existem dezenas de implementações de extensões de linguagens com programação orientada por aspectos. Contudo, o AspectJ continua a ser, sem dúvida, a mais popular.

É um projecto opensource suportado pela Fundação Eclipse (http://www.eclipse.org/aspectj/) e liderado por Adrian Colyer. Peso embora este texto não tenha como objectivo realizar uma descrição extensiva do AspectJ, parece-nos apropriado evidenciar as suas principais características como forma de introdução aos capítulos seguintes.

À medida que os sistemas se foram tornando cada vez mais complexos, surgiu a necessidade de desenvolver mecanismos que ajudassem a identificar e a separar as várias preocupações4 (concerns) presentes num sistema.

David Parnas, um cientista americano, propôs em 19725 a modularização como um processo de criação de módulos que permitia uma maior flexibilização e compreensão dos sistemas, onde cada módulo se torna “independente” dos outros.

Isto foi uma das bases para o paradigma da orientação por objectos, que hoje em dia providencia uma forma robusta de modularização. Contudo, esta visão tem algumas limitações práticas, no que diz respeito à forma como são implementadas funcionalidades que são transversais a todos os módulos. Para tentar minimizar os impactos desta medida, têm sido desenvolvidas um conjunto de metodologias, entre as quais está Programação Orientada por Aspectos.

Vantagens da Programação Orientada a Aspectos

A programação orientada por aspectos tem como principal objectivo resolver as limitação dos métodos de programação actuais, como o espalhamento de código (scattering) ou o emaranhamento (tangling) ou ambos, que tornam o código cada vez mais confuso e de difícil evolução e manutenção.

Estes problemas derivam de uma fraca modularização das aplicações pois existem várias preocupações (concerns) que estão distribuídas por muitos módulos da aplicação.

São exemplo disso, funcionalidades como o logging, profilling, tracing, gestão de sessões, sessões remotas ou mecanismos de segurança. Estas preocupações são chamadas de crosscutting concerns.

Infelizmente, dadas as suas características distribuídas, é impossível, com os métodos tradicionais, centralizar todos elas num único módulo do sistema ou programa.

Vista de Sistema como composição de várias preocupações. (adaptado de Laddad, 2003)

Vista de Sistema como composição de várias preocupações. (adaptado de Laddad, 2003)

 

Na figura anterior, é possível observar um esquema onde cada módulo de um sistema necessita de implementar várias preocupações, como a persistência (i.e, base de dados), registo de dados (logging) e regras de negócio. Já na figura 2 podemos ver um resumo do processo desenvolvimento com o Aspect J, onde as preocupações presentes são encapsuladas em unidades modulares perfeitamente separadas e independentes.

Assim, o código está perfeitamente modularizado. Antes da compilação, através de um processo que gera código intermédio, é efectuada a combinação dos módulos/componentes  (ou “tecelagem”) com os elementos escritos em linguagem de aspectos e, por sua vez, este é compilado.

É de salientar que o produto final do compilador6 são ficheiros .class  (Java bytecode) comuns, perfeitamente executáveis em qualquer sistema com a JVM instalada.

É ainda de salientar que  o código correspondente ao negócio não sofre qualquer alteração para suportar a programação orientada a aspectos. Isso é feito no momento da combinação entre os módulos/componentes e os aspectos.

Esse processo também pode ser definido como recompilação aspectual.7.

Resumo do Processo de Programação com AspectJ.

Resumo do Processo de Programação com AspectJ.

O Livro

AspectJ in Action, Second Edition

Avaliação: 4/5
Sítio do livro na Amazon

Um livro muito completo de Ramnivas Laddad que apresenta o Aspect J com vários exemplos práticos.

 

Notas

  1. Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes[]
  2. Laddad, Ramnivas. AspectJ in Action – Practical Aspect-Oriented Programming. Greenwich : Manning Publications Co., 2003. ISBN 1-930110-93-6, p.146[]
  3. Gamma, Erich; Nackman, Lee; Wiegand, Johm; Eclipse AspectJ, Addison Wesley, 2005, ISBN 0- 321 – 24587 -3. p.xv[]
  4. Em alguma literatura, tipicamente, em Português do Brasil, a tradução de concern é feia por “interesse”.[]
  5. D. L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, Volume 15, Issue 12, Pages: 1053-1058, Year: 1972[]
  6. Uma diferença que existe entre o compilador de AspectJ (ajc) e o compilador Java (javac) é que enquanto o compilador Java pode compilar ficheiros separados, o ajc tem que receber todos os ficheiros do sistema (que tenham ligações entre si) de uma única vez.[]
  7. Winck, Diogo Vinícius; Júnior, Diogo Vinícius, AspectJ – Programação orientada a aspectos com Java, Novatec, 2006, ISBN: 85-7522-087-X[]

, , , , , ,

Nenhum comentário (ainda!)

Deixe uma resposta

Escreva apenas comentários relacionados com este artigo.
Isto ajudará a manter os artigos organizados. Obrigado!