A DAOP-ADL (PINTO; FUENTES; TROYA, 2003) é uma linguagem de descrição arquitetural, baseada em XML, para descrever a arquitetura de uma aplicação em termos de um conjunto de componentes, um conjunto de aspectos e a interconexão entre eles. As interconexões são estruturadas em dois tipos diferentes de restrições de composição:
1. regrasDeComposiçãoDeComponentes: descreve as regras para direcionar a composição de componentes.
2. regrasDeAvaliaçãoDeAspectos: é o equivalente aos conjuntos de pontos de junção nas LPs orientada a aspectos, e descreve as regras de combinação entre componentes e aspectos.
O processo para o design de arquitetura baseado na DAOP-ADL é o seguinte: todos os componentes e aspectos que podem ser instanciados em uma aplicação são descritos usando a seção de descrição de componentes e aspectos da linguagem DAOP-ADL.
A ferramenta Component and Aspect Repository, usada para registrar aspectos e componentes COTS, gera automaticamente a descrição de aspectos e componentes carregados usando-se a sintaxe da linguagem DAOP-ADL. Na seqüência, é empregada a ferramenta Aspect Specification and Validation, a qual possui a linguagem DAOP-ADL em seu back-end e oferece suporte à descrição e validação da arquitetura de software da aplicação.
A DAOP-ADL é usada em conjunto com o CAM/DAOP. O CAM (Componet-Aspect Model) é um modelo de design usado para projetar aplicações baseadas em componentes e aspectos em UML. A DAOP, por outro lado, é uma plataforma baseada em componentes e aspectos que carrega a descrição da arquitetura fornecida via especificação DAOP-ADL para obter as informações necessárias à instanciação dos componentes e dos aspectos e para executar a composição dinâmica de componentes em tempo de execução.
5.3.2 Abordagens para o Processo de Design Arquitetural Aspect-Oriented Generative Approaches (AOGA)
Trata-se de uma abordagem centrada na arquitetura, inicialmente esboçada em (GARCIA, 2001) e posteriormente estendida em (KULESZA; GARCIA; LUCENA, 2004-a), com o propósito de dar suporte a desenvolvedores de sistemas multi-agentes (MAS - Multi Agent Systems) com linguagens específicas de domínio, notações de modelagem, e ferramentas de geração de código. A AOGA tem extensões definidas para modelos de características (features) e uma nova linguagem específica de domínio Agent-DSL, além da notação baseada na UML para expressar aspectos arquiteturais.
Esta abordagem cobre as seguintes fases do ciclo de vida: Análise e Especificação de Domínio, Design e Implementação da Arquitetura, conforme ilustrado na Figura 5.1.
Análise e Especificação do Domínio
Especificação de aspectos do domínio
Especificação de propriedades dos agentes
Modelos de Características Estendido Agent-DSL
Design da Arquitetura
Arquitetura Orientada
Aspectos Notação UML
Implementação
Frameworks + Componentes
Templates de
Código Gerador de
Código
Implementação Classes e Aspectos
da Aplicação
Arquitetura Agente OA Gerada
Figura 5.1 – Fases do desenvolvimento apoiadas na AOGA – Fonte: (KULESZA; GARCIA; LUCENA, 2004-a).
A AOGA tem uma linguagem baseada em UML para especificação e comunicação de arquiteturas de software orientadas a aspectos (Figura 5.2). Conforme mostra a Figura 5.2, cada componente arquitetural tem uma ou mais interfaces; diferentes componentes podem conceber a mesma interface. As interfaces são anexadas aos componentes arquiteturais e são categorizados em dois grupos: interfaces normais (NI) e interfaces transversais (CI) (CHAVEZ et al., 2005).
Figura 5.2 – Aspectos arquiteturais em interfaces transversais. Fonte: (KULESZA; GARCIA; LUCENA, 2004a).
Uma interface normal apenas fornece serviços para outros componentes enquanto que uma interface transversal em um modelo arquitetural especifica quais componentes arquiteturais um componente aspectual afeta. Um componente aspectual está em
conformidade com um conjunto de interfaces transversais. Uma interface de um aspecto entrecorta os elementos internos de componentes arquiteturais ou entrecorta outras interfaces.
O primeiro caso significa que o aspecto arquitetural afeta, diretamente, a estrutura interna ou o comportamento dinâmico do componente alvo. O segundo caso significa que o aspecto afeta o comportamento definido pela interface transversal.
TranSAT
O TranSAT (BARAIS et al., 2004) é um framework para a especificação da evolução do software que enfatiza a facilitação da evolução da arquitetura através dos princípios de DSOA em um contexto arquitetural. Ele propõe a definição incremental da arquitetura do software através da combinação (weaving) de um novo plano arquitetural dentro da arquitetura de software. A especificação da arquitetura é transformada por meio da integração de interesses dentro da arquitetura.
5.3.3 Abordagens para Avaliação Arquitetural Aspectual Software Architecture Analysis Method (ASAAM)
O ASAAM (TEKINERDOGAN, 2004) tem como objetivo identificar e especificar, explicitamente, aspectos arquiteturais nos estágios iniciais do ciclo de vida do software. Essa abordagem, construída com base em métodos de análise arquitetural baseada em cenários (KAZMAN et al., 1994), é considerada como uma abordagem complementar a tais métodos.
Os dois artefatos chave no ASAAM são cenários e componentes arquiteturais. Existem três tipos de cenários: direto (pode ser executado diretamente), indireto (exigem uma mudança de um componente) e aspectual (pode ser direto ou indireto e está disperso entre múltiplos componentes). Em (TEKINERDOGAN, 2004) são classificados quatro tipos de componentes:
• Componente coeso, um componente que está bem definido e executa cenários semanticamente fechados.
• Componente mal definido, um componente que consiste de vários sub-componentes, sendo que cada um deles executa um conjunto de cenários semanticamente fechados.
• Componente entrelaçado, um componente que executa um cenário aspectual o qual é direta ou indiretamente executado pelo componente.
• Componente composto, um componente que inclui cenários semanticamente distintos, mas que não podem ser decompostos ou não incluem um cenário aspectual.
Os aspectos arquiteturais são os artefatos de saída, que podem ser usados para refatorar a arquitetura. Conforme ilustrado na Figura 5.3, o processo ASAAM consiste de cinco atividades (TEKINERDOGAN, 2004):
Figura 5.3 – As atividades para o ASAAM – Fonte: (TEKINERDOGAN, 2004).
1. Desenvolvimento da arquitetura candidata: um design de arquitetura (candidata) fornecido será analisado levando em conta os fatores de qualidade e potenciais aspectos requeridos.
2. Desenvolvimento de cenários: cenários provenientes de vários stakeholders são coletados, os quais representam usos importantes e usos antecipados da arquitetura de software.
3. Avaliação de cenário individual e identificação de aspectos: a avaliação de cenários também busca por potenciais aspectos. A aplicação de regras heurísticas resulta em uma classificação posterior dos cenários em: cenário diretos, cenários indiretos, cenários aspectuais e aspectos arquiteturais. Cenários aspectuais são derivados de cenários diretos ou indiretos e representam potenciais aspectos.
4. Avaliação da interação do cenário e identificação de componentes entrelaçados: A meta desta atividade é avaliar se a arquitetura suporta uma separação apropriada de interesses.
Inclui-se os interesses não-transversais e os aspectos arquiteturais. Para cada componente, os componentes diretos e indiretos são analisados e categorizados em componentes coesos, componentes entrelaçados, componentes compostos, ou componentes mal definidos.
5. Refatoração da arquitetura: A refatoração da arquitetura é proposta baseando-se na avaliação da interação dos cenários e nas classificações dos componentes. Os aspectos arquiteturais e os componentes entrelaçados são descritos explicitamente na arquitetura. A ASAAM define um conjunto de regras heurísticas para categorizar cenários em cenários diretos, cenários indiretos e cenários arquiteturais e aspectos arquiteturais (Quadro 5.1). O ASAAM também define regras heurísticas para categorizar os componentes arquiteturais.
Desenvolvimento de uma Arquitetura Candidata
Avaliação de Cenário Individual e Identificação de
Aspectos
Avaliação da Interação de Cenários e Identificação de Componentes Entrelaçados
Refatoração da Arquitetura
Refatoração Aspectual da Arquitetura Desenvolvimento
de Cenários
Quadro 5.1 – Regras heurísticas para avaliação de cenários – Fonte: (TEKINERDOGAN, 2004).
R0:
Desenvolver artefatos CENÁRIOS baseados na DESCRIÇÃO DO PROBLEMA R1:
SE CENÁRIO não requer quaisquer alterações na descrição arquitetural ENTÃO CENÁRIO torna-se CENÁRIO DIRETO
R2:
SE CENÁRIO requer alterações a um ou mais COMPONENTES ARQUITETURAIS ENTÃO CENÁRIO torna-se CENÁRIO INDIRETO
R3:
SE CENÁRIO INDIRETO pode ser resolvido após a refatoração ENTÃO CENÁRIO INDIRETO é CENÁRIO DIRETO
R4:
SE CENÁRIO DIRETO estiver espalhado e não pode ser localizado em um componente ENTÃO CENÁRIO DIRETO é CENÁRIO ASPECTUAL
R5:
SE CENÁRIO INDIRETO estiver espalhado e não pode ser localizado em um componente ENTÃO CENÁRIO INDIRETO é CENÁRIO ASPECTUAL
R6:
Derivar a ASPECTO ARQUITETURAL do CENÁRIO ASPECTUAL
O ASAAM tem sido implementado como um plug-in Eclipse no ambiente da ferramenta ASAAM-T (TEKINERDOGAN; SCHOLTEN, 2005).