Desenvolvimento de Software Orientado a Aspectos

O paradigma orientado a objetos permite a construção de sistemas considerando abstrações do mundo real de forma modularizada, por meio de classes e seus relacionamentos, promovendo a reusabilidade e constituindo o paradigma dominante no cenário atual de desenvolvimento de software (Laddad, 2003).

Apesar dessa ampla utilização, o desenvolvimento orientado a objetos possui certas dificuldades quanto à implementação de interesses que naturalmente afetam múltiplas classes, os denominados interesses transversais (crosscuting concerns), como: segurança, logging, persistência e auditoria, entre outros. Essas limitações

refletem em módulos espalhados e entrelaçados na arquitetura final das aplicações que dificultam a manutenção e evolução.

Segundo Laddad (2003) o entrelaçamento de código, também denominado emaranhamento, é ocasionado quando um módulo em um sistema de software é implementado para lidar simultaneamente com múltiplos interesses do sistema. A Figura 7 representa vários módulos de implementação de um sistema, contendo trechos de código referente a diversos interesses, como: lógica de negócios, persistência e logging.

Figura 7: Entrelaçamento de código (Laddad, 2003)

Para Laddad (2003); Winck e Junior (2006), o espalhamento ocorre quando uma única funcionalidade é implementada em vários módulos, ou seja, o código necessário para cumprir um interesse específico propaga-se em classes que tratam de outros interesses. A Figura 8 representa um sistema bancário em que foi implementado o interesse de logging, utilizando técnicas orientadas a objetos.

Observa-se que o código referente ao interesse de logging está espalhado em outros módulos, ou seja, existem várias invocações aos métodos pertencentes ao módulo logging, partindo de módulos que implementam interesses distintos, tais como: banco de dados, caixa eletrônico (ATM - Automated Teller Machine) e contabilidade.

Capítulo 3 - Desenvolvimento Orientado a Aspectos e Desenvolvimento Dirigido a Modelos 42

Figura 8: Espalhamento de código (adaptado de Laddad 2003)

A ocorrência de códigos entrelaçados e espalhados reflete diretamente no desenvolvimento de software, causando dificuldades como: (a) alto acoplamento, pois os métodos das classes necessitam admitir métodos das classes que implementam as funcionalidades espalhadas; (b) baixa coesão, uma vez que métodos das classes afetadas possuem instruções que não estão diretamente relacionadas à funcionalidades que implementam; (c) redundância, pois muitos fragmentos de código semelhantes ocorrem em diversos pontos do código fonte e (d) compreensibilidade prejudicada, uma vez que a implementação de interesses transversais deve ser dependente do código espalhado para facilitar o reúso e a manutenção. Por exemplo, o código responsável para implementação de um interesse como o tratamento de exceções, utilizando orientação a objetos, é inseparável do código onde a exceção poderá ser gerada, impedindo que esse interesse seja agrupado em apenas uma unidade.

Considerando essas dificuldades, o princípio da separação de interesses introduzido por Dijkstra (1976), que consiste em decompor o domínio do sistema em partes isoladas para facilitar o entendimento, pode ser aplicado a esse cenário de desenvolvimento de software, visto que cada interesse representa uma parte do domínio do sistema que pode ser considerada como um requisito funcional ou não funcional.

De acordo com Laddad (2003), os interesses de um sistema de software podem ser classificados em dois grupos: interesses de negócio e interesses em nível de sistema, ou interesses transversais. O primeiro compreende interesses funcionais que são relacionados com lógica de negócios, enquanto que o segundo refere-se

aos requisitos que atravessam vários módulos, como chamadas a métodos relacionados com requisitos não funcionais.

Contudo, existem abordagens que visam a separação desses interesses, como a Programação Orientada a Aspectos (POA) proposta por (Kiczales et al.,1997) que contribui para melhorar a modularização dos interesses transversais. Segundo (Kiczales et al., 1997), uma implementação de POA consiste em três elementos principais: linguagem de componentes, linguagem de aspectos e o combinador de aspectos. A linguagem de componentes é responsável por implementar interesses de negócio do sistema de software, por exemplo a linguagem Java. A linguagem de aspectos deve favorecer uma implementação clara de interesses transversais por meio de aspectos. O combinador de aspectos (aspect weaver) realiza o “weaving”, ou seja, a combinação entre os programas escritos na linguagem de componentes com o código em linguagem de aspectos, por meio de um pré-processamento em tempo de compilação.

As linguagens de aspectos podem ser classificadas em propósito específico ou propósito geral. As linguagens de propósito específico tratam somente de determinados aspectos, possuindo restrições quanto ao uso das linguagens de componentes, enquanto que as linguagens de propósito geral permitem a implementação de qualquer tipo de interesse e podem compartilhar o mesmo ambiente utilizado pela linguagem de componentes, como é o caso da linguagem AspectJ6, criada pela Xerox Palo Alto Research Center em 1997 (Kiczales et al., 2001).

AspectJ complementa a linguagem Java na separação de interesses transversais, acrescentando outros conceitos, como: aspectos (aspects), pontos de junção (join points), conjuntos de junção (point cuts), adendos (advices) e declaração intertipo (inter-type declaration). As definições para esses elementos são apresentadas na Seção 3.1.1.

6

Capítulo 3 - Desenvolvimento Orientado a Aspectos e Desenvolvimento Dirigido a Modelos 44

3.1.1 Abstrações da Programação Orientada a Aspectos

Os aspectos são elementos básicos que permitem isolar interesses transversais, modificando a estrutura estática ou dinâmica de programas orientados a objetos preservando seu comportamento (Laddad, 2003).

A estrutura estática desses programas pode ser alterada por meio de declarações intertipo que permitem a adição de atributos, métodos ou construtores a uma classe, enquanto que, a estrutura dinâmica pode ser modificada em tempo de execução por meio dos conjuntos de junção, os quais são definidos pontos de junção correspondentes aos pontos de execução de um programa que podem ser adicionados comportamentos (adendos). Dessa forma, os trechos de código recorrentes de interesses transversais que ficariam entrelaçados ou espalhados são encapsulados em aspectos.

Os pontos de junção são pontos na execução de um programa de componentes que devem ser definidos para que os aspectos sejam aplicados, ou seja, esses pontos possibilitam o relacionamento entre classes e aspectos, como: chamada e execução de métodos, leitura e alteração de atributos, etc. Os pontos de junção auxiliam o combinador de aspectos na composição dos aspectos com o código orientado a objetos.

Um conjunto de junção é responsável por selecionar pontos de junção, tornando possível a detecção dos pontos do programa em que os aspectos devem atuar, adicionando novos comportamentos e/ou alterando os existentes.

Os adendos são comportamentos que devem ser executados em um ponto de junção referenciado pelo conjunto de junção. Os adendos podem ser classificados em três tipos: anterior, “de contorno” ou posterior (before, around ou after). O primeiro refere-se ao comportamento que deve ser executado antes do ponto de junção. O segundo executa “em volta” do ponto de junção e pode ser utilizado para substituição de trechos de código de um método referenciado pelo ponto de junção e o tipo posterior, por sua vez, executa depois do ponto de junção.

As declarações intertipo possuem a capacidade de modificar a estrutura estática dos módulos de uma aplicação, ou seja, em tempo de compilação as declarações intertipos podem especificar novos atributos, construtores ou métodos nas classes, além de possibilitar a alteração de interfaces e aspectos.