METAMODELO AO-ADL

Inicialmente tínhamos um metamodelo para o AO-ADL fornecido pelos idealizadores da linguagem AO-ADL, que, no entanto, não compreendia o objetivo de descrever a AO- ADL sob os princípios e boas práticas da metamodelagem. Assim, refizemos o metamodelo AO-ADL objetivando representar em nível de metamodelagem os requisitos da linguagem AO-ADL para descrição da arquitetura de sistemas.

Com a finalidade de promover o princípio de reuso de elementos arquiteturais de sistemas, definido na linguagem AO-ADL, nosso metamodelo foi construído com um conjunto de quatro agrupamentos (repository) que comportam:

x InterfaceRepository: agrupa descrições de interfaces (Interfaces) que podem ser utilizadas por componentes ou conectores;

x ConnectorRepository: agrupa descrições de conectores (Connectors) e elementos que fazem parte dos conectores

x ComponentRepository: agrupa descrições de componentes (Components) e suas interfaces

x ArchitectureRepository: agrupa elementos da arquitetura do sistema através da composição de instâncias de componentes e conectores que são interligados por ligadores (Attachment).

A Figura 27 mostra os quatro repositórios citados anteriormente: InterfaceRepository;

ConnectorRepository; ComponentRepository e ArchitectureRepository;

Figura 27. Repositórios que guarda os elementos da AO-ADL. Metamodelos: InterfaceRepository, ConnectorRepository, ComponentRepository, ArchitectureRepository.

A Figura 28 mostra as metaclasses que fazem parte do repositório InterfaceRepository.

InterfaceRepository é composto de interfaces (Interfaces), as interfaces de operações

(Operations), e as operações de parâmetros (Parameters). A cardinalidade entre as metaclasses está informada na Figura 28. A propriedade adicionada ao metamodelo Base da

AO-ADL é o elementos classifier. Seguindo nossa abordagem, a propriedade classifier permite classificar interfaces e operações a partir dos padrões descritos no Modelo Conceitual.

Figura 28. Detalhamento do repositório de Interfaces.

A Figura 29 ilustra o repositório ComponentRepository que é composto de

componentes (Components). Um componente é composto de interfaces

(InterfaceCompositeComponent) que podem prover (ProvidedInterface) ou requerer (RequiredInterface) alguma funcionalidade. Cada interface de componente se relaciona com as interfaces do repositório de interfaces.

Figura 29. Detalhamento do repositório de componentes.

A Figura 30 mostra as metaclasses que compõem o repositório ConnectorRepository. Nela são descritos o conector (Connector) e os papéis que um conector pode ter:

ProvidedBoundedRole, RequeridedBoundedRole e AspectualRole. ProvidedBoundedRole e RequeridedBoundedRole podem ser relacionados através da classe ComponentBinding que

permite a ligação entre papéis no conector.

Para a definição de características aspectuais, a classe AspectualBinding define Advice e PointcutSpecification a fim de permitir a utilização do conector como um conector aspectual. Em PointcutSpecification descrevem-se os pontos de junção que se deseja capturar e a classe Advice insere o comportamento desejado no ponto de junção descrito no

PointcutSpecification. A definição da funcionalidade a ser executada pelo Advice se dá pela

escolha da operação (atributo Operator da classe Advice) da interface ao qual AspectualRole esteja associado.

A classe PointcutSpecificationClassifier é uma especialização de PointcutSpecification que foi adicionada ao modelo AO-ADL original e foi criada para servir

ao propósito da implementação deste trabalho. PointcutSpecificationClassifier permite fazer referência a pontos de junção de padrões do Modelo Conceitual. A definição dessa metaclasse foi necessária para diferenciar os pontos de corte que faziam referência a instâncias do Modelo Conceitual e instâncias que faziam referências diretas a pontos de junção da

arquitetura. PointcutSpecification tem dois atributos, name e pointcutSpecification. O atributo

name define um nome que identifica o ponto de corte, enquanto que o atributo pointcutSpecification permite descrever pontos de corte em XPath. As associações às classes Parameter, Component, Interface e Operation descritas no PointcutSpecificationClassifier

foram criadas para facilitar a definição de pontos de corte. Assim, o usuário tem outra opção para definir pontos de corte com base no Modelo Conceitual de forma mais simplificada, sem usar a notação em XPath. O usuário pode simplesmente selecionar os componentes, interfaces, operações e parâmetros do Modelo Conceitual que irão compor a especificação do ponto de corte. Para expressões mais complexas, recomendamos a utilização de expressões em XPath no atributo PointcutSpecification.

Figura 30. Detalhamento do repositório de conexões.

Depois de descrever os elementos arquiteturais do sistema, a instanciação desses elementos se dá no repositório ArchitectureRepository, onde componentes

(ComponentInstance) e conectores (ConnectorInstance) são instanciados a partir de Componentes e Conectores dos repositórios de componentes e conectores, respectivamente, e ligados através do ligador (Attachment) na definição de uma arquitetura (Architecture). Tais elementos são ilustrados na Figura 31. O relacionamento componenteInstance entre

ComponentInstance e Component permite referenciar que componente ComponentInstance

instancia. A associação connectorInstance permite referenciar que conector

As associações nomeadas como classifier foram adicionadas ao metamodelo inicial AO-ADL para servir ao propósito deste trabalho. Tais associações permitem que componentes possam ser classificados de acordo com padrões descritos no Modelo Conceitual. Components podem ser associados a mais de um conceito ComponentInstance, enquanto que um Connector pode estar associado a apenas um ConnectorInstance. Essa associação permite que um Componente possa estar associado a vários ComponentInstances que representam os padrões do Modelo Conceitual. Associação classifier de Connector dá a possibilidade de um Connector ser classificado apenas com uma ConnectorInstance que também representa um padrão do Modelo Conceitual.

Figura 31. Detalhamento do repositório de arquiteturas.

3.5.1 Camada de Conceitos Arquiteturais de Sistema na AO-ADL

A Figura 32 ilustra um exemplo de um padrão arquitetural, o padrão MVC (Model-

View-Controller) descrito na forma de Modelo Conceitual. Model, View e Controller foram

abstraídos como conceitos e interligados através de seus papéis de interface pelos conectores

ModifyCnnMM, ConsultCnnMM, ModifyCnnMC, ConsultCnnMC, ShowCnn. Os conectores ModifyCnnMM e ConsultCnnMM interligam papéis de interfaces set e get do conceito Model

a ele mesmo, enquanto que os conectores ModifyCnnMC, ConsultCnnMC interligam os conceitos Model a Controller e o conectores ShowCnn os conceitos Controller a View.

A ligação de papéis de interface a um mesmo conceito no Modelo Conceitual permite que instâncias de um mesmo conceito possam se comunicar entre si. Dessa forma,

componentes que exercem o papel de Model podem se comunicar através de conexões entre interfaces de papel set ou get que são ligados por instância de ModifyCnnMM e

ConsultCnnMM.

Figura 32. Descrição do Padrão MVC na Camada de Conceitos Arquiteturais de Sistema na AO-ADL.

3.5.2 Camada de Conceitos do Domínio de Aplicação na AO-ADL

A Camada de Conceitos do Domínio de Aplicação define conceitos que representam padrões específicos para um determinado domínio de aplicação alvo. Pode-se citar um exemplo no domínio de aplicações multimídia, onde geralmente utiliza-se algum gerenciador de fluxo de dados (Data Stream Manager) para executar informações de dados. Tal conceito foi representado na Figura 33 com o nome de StreamManager. StreamManager possui um papel de interface provido outputDataStream e um papel de interface requerido

inputDataStream. Também há a definição do conector inOutStreamCnn que interliga o papel

de interface provido outputDataStream ao papel de interface requerido inputDataStream. StreamManager também é interligado ao conceito Player através do conector

Tais definições funcionam como regras de design que restringem as conexões que podem ocorrer em instâncias do Modelo Conceitual. Por exemplo, conectores instanciados a partir do conector inOutStreamCnn apenas podem interligar interfaces que façam o papel de

outputDataStream à interfaces do tipo inputDataStream.

Figura 33. Descrição do Padrão StreamManager na Camada de Conceitos do Domínio de Aplicação na AO-ADL.

3.5.3 Camada de Conceitos Específicos do Sistema na AO-ADL

A Camada de Conceitos Específicos do Sistema é destinada a especificar conceitos que o sistema precisa representar, porém eles são tão específicos a uma aplicação que não faz sentido defini-los nas duas camadas anteriores. Por exemplo, deseja-se definir componentes para permitir acesso de componentes da camada Controller, em um sistema que obedece ao padrão MVC, aos elementos que representam as entidades do domínio do sistema (Model). Tal conceito pode ser nomeado como ModelAccessor e é mostrado na Figura 34. As instâncias que tiverem o papel de ModelAccessor agora podem ser referenciadas por pontos de corte do Nível Conceitual.

Figura 34. Descrição do Conceito ModelAccessor na Camada de Conceitos Específicos do Sistema na AO- ADL.