ABORDAGEM POA UTILIZANDO REGRAS DE DESIGN

Em (GRISWOLD et al., 2006) é utilizada uma abordagem baseada em contrato (BALDWIN e CLARK, 2000), onde se utilizam construções em AspectJ para criar invariantes em forma de interfaces que fazem restrições às estruturas e comportamentos de suas implementações. Uma vez que a interface é definida, os implementadores do código base e do aspecto são restritos à implementá-las. Essa interface abstrata com código de restrições é chamada de XPI (crosscut programming interfaces).

Cada XPI tem quatro elementos base: o nome, o escopo, um ou mais conjuntos de abstrações de pontos de junção, e uma implementação parcial. Cada conjunto de abstrações de pontos de junção expressa uma precondição que precisa ser satisfeita em cada ponto onde o adendo pode atuar. Há também pós-condições que precisam ser satisfeitas depois do adendo atuar.

A abordagem XPI separa aspectos dos detalhes do código que ele seleciona e restringe o código a expor o seu comportamento de uma forma específica. XPIs desacoplam código de aspectos de detalhes do código de adendo sem perder a expressividade das linguagens

Orientadas a Aspectos existentes e sem a necessidade da adição de novas abstrações à linguagem.

No entanto, tentar especificar regras de design utilizando AspectJ resulta num complexo mecanismo de verificação difícil de descrever e entender devido à complexidade das construções necessárias para verificação (checagem) de tais regras.

Em (DÓSEA et al., 2007) há a proposta da definição de regras de design a partir de uma descrição arquitetural em AspectualACME6 (BATISTA et al., 2006) para tentar guiar o correto desenvolvimento de requisitos do sistema desacoplando conceitos base de conceitos aspectuais. Tal abordagem, além de diminuir a distância semântica existente entre as abstrações utilizadas para representar conceitos arquiteturais e código orientado a objeto (GOULO e ABREU, 2003). As regras de design são baseadas em contrato e especificam a interface básica que cada um dos conceitos (bases e aspectuais) deve implementar, fazendo com que tais conceitos possam ser implementados independentemente um do outro nas fases subseqüentes do desenvolvimento de software. Tais regras além de guiarem o desenvolvimento, diminuem a distância semântica existente entre a descrição arquitetural e o código de implementação. A Figura 108 ilustra a estratégia baseada em contrato que utiliza regras de design para promover uma melhor evolução de software. A Figura 108 mostra a classe GUI e o aspecto Distribution, que já conhecem as interfaces básicas que precisam ser implementadas pelo sistema.

Figura 108. Imagem ilustrativa da abordagem de regras de design no DSOA.

Além das regras de design estruturais geradas a partir de especificações arquiteturais em AspectualACME, DÓSEA et al. (2007) propõem o uso se regras comportamentais para restringir o código. A Tabela 31 mostra regras comportamentais providas pela linguagem proposta em (DÓSEA et al., 2007). O escopo dessas regras inclui métodos de classes, 

6 _{AspectualACME é uma extensão da linguagem ACME para representação de conceitos aspectuais no nível de}

aspectos e adendos. Todas as regras iniciadas com “x” garantem que métodos serão chamados exclusivamente no escopo definido.

Tabela 31. Tabela com as regras comportamentais suportadas atualmente pela linguagem de Regras de

Design proposta em DÓSEA et al. (2007).

Regra Descrição

call(método) Deve existir uma chamada ao método passado como parâmetro dentro do escopo definido.

xcall(método) Deve existir uma chamada ao método passado como parâmetro exclusivamente dentro do escopo definido.

set(atributo) Deve existir uma mudança de estado do atributo passado como parâmetro dentro do escopo definido.

xset(atributo) Deve existir uma mudança de estado do atributo passado como parâmetro exclusivamente dentro do escopo definido.

get(atributo) Deve existir uma leitura do atributo passado como parâmetro dentro do escopo definido.

xget(atributo) Deve existir uma leitura do atributo passado como parâmetro exclusivamente dentro do escopo definido

A Figura 109 mostra um exemplo de tradução de uma especificação em AspectualACME (lado esquerdo) e sua respectiva tradução para regras de Design (lado direito). O lado esquerdo da Figura 109 apresenta a especificação de dois componentes, um Cliente (Client) e um servidor (Server) e o relacionamento existente entre eles através das portas sendRequest e receiveRequest. Ao lado direito da Figura 109, System foi traduzido para dr (design rule). Componentes foram traduzidos para classes (class) e as portas

sendRequest e receiveRequest em métodos. A conexão entre componentes através das portas sendRequest e receiveRequest existentes entre os componentes Client e Server foi

transformado em uma chamada exclusiva (declaração xcall) do método sendRequest ao método receive.

Figura 109. Exemplo de tradução de uma descrição arquitetural para regras de design.

6.2.1 Comparação com a abordagem de DSOA acrescido do Modelo Conceitual

Assim como a abordagem de regras de design em (GRISWOLD et al., 2006), a presente proposta funciona como regras de design para o desenvolvimento de sistemas. No entanto a abordagem de XPI dada em (GRISWOLD et al., 2006) cria regras de design em nível de código, utilizando declarações difíceis de especificar, entender e validar, enquanto que o presente trabalho trata o problema de evolução em um nível de abstração mais alto (Nível de Arquitetura) mais fácil de tratar, especificar, entender, validar e os conceitos do Modelo Conceitual ainda são propagados para os níveis inferiores.

A solução proposta em (DÓSEA et al., 2007) define regras de design, assim como o trabalho aqui proposto, no entanto há algumas diferenças. Em (DÓSEA et al., 2007) definem- se regras de transformação a partir de uma descrição arquitetural em AspectualACME, enquanto que aqui é proposto um Modelo Conceitual que baseado em padrões arquiteturais, guiam a descrição arquitetural de sistemas e a sua posterior propagação para as demais fases de desenvolvimento. DÓSEA et al., (2007) propõem uma estratégia que restringe a expressividade da linguagem de pontos de corte enquanto que o Modelo Conceitual aqui proposto enriquece o Modelo Base e permite prover um maior significado semântico para as construções do Modelo Base.