MODELO CONCEITUAL

Uma das principais vantagens da utilização do Modelo Conceitual em nosso trabalho está no acoplamento direto entre os Modelos Base e de Aspectos causado pelo uso dessa

camada intermediária. Tal desacoplamento favorece a evolução do software, pois ambos os modelos (Aspectual e Base) podem evoluir independentemente um do outro. A Figura 18 mostra o relacionamento existente entre os três modelos utilizados neste trabalho. O Modelo de Aspectos referencia conceitos definidos no Modelo Conceitual enquanto que as instâncias do Modelo Base são classificadas ou instanciadas de acordo com os conceitos de padrões e arquiteturas definidos no Modelo Conceitual.

A idéia base é que um sistema pode ser totalmente construído seguindo padrões e arquiteturas definidas no Modelo Conceitual. Sendo assim, o Modelo de Aspectos não precisa saber das instâncias que implementam os conceitos especificados no Modelo Conceitual, os pontos de corte apenas precisam referenciar padrões que foram definidos na camada intermediária (Modelo Conceitual). O Modelo de Aspectos acessa o Modelo Base indiretamente através da classificação realizada no Modelo Base e que referencia diretamente conceitos e papéis do Modelo Conceitual.

Figura 18. Relacionamento entre os três modelos utilizados neste trabalho: Modelo Conceitual, Modelo de Aspectos e Modelo Base.

A utilização do Modelo Conceitual para classificar o Modelo Base funciona como informações de design que aumentam o poder semântico do Modelo Base ao estabelecer papéis e Regras de Design (SULLIVAN et al., 2005b) bem definidas para cada elemento do modelo alvo (Modelo Base). Trato com mais detalhes sobre os Modelos de Aspectos, Conceitual e Base na Seção 3.5, ao descrever o metamodelo AO-ADL.

O aumento da expressividade do Modelo Base permite aos pontos de corte referenciar elementos do Modelo Base pelas suas características semânticas (função que os elementos do Modelo Base desempenham no sistema) ao invés de propriedades estruturais como em outras abordagens. Tal técnica possibilita uma melhor evolução do software, porque simples

mudanças nas assinaturas de instâncias do Modelo Base não mudam os papéis que os elementos do sistema devem desempenhar.

A abordagem deste trabalho também prioriza o conceito de inconsciência, pois os aspectos não precisam ter conhecimento das instâncias que o Modelo Base irá criar para selecionar corretamente os elementos do modelo alvo. Desde que os conceitos do Modelo Base sejam corretamente classificados de acordo com os conceitos do Modelo Conceitual, a declaração de pontos de corte funcionará corretamente. Da mesma forma, o Modelo Base não precisa estar ciente dos aspectos que o selecionam, e pode evoluir sem tal preocupação, atentando apenas para o fato de ser corretamente classificado de acordo com os conceitos do Modelo Conceitual.

A utilização do Modelo Conceitual possibilita até mesmo uma melhor sincronização entre os modelos, pois os mapeamentos entre o Modelo Conceitual e os Modelos Base e de Aspectos são feitos de forma direta, o que permite que até as evoluções do Modelo Conceitual sejam mais bem administradas nos Modelos Base e de Aspectos.

O Modelo Conceitual deste trabalho foi subdividido em três níveis para que fosse possível separar de forma mais adequada os diversos conceitos utilizados para descrição dos padrões e arquiteturas no desenvolvimento de um software. Essa necessidade foi identificada a partir da constatação de que apenas com padrões e arquiteturas genéricos não seria possível descrever abstrações que guiassem o desenvolvimento de sistemas complexos. Existem conceitos que só fazem sentido em certos domínios de aplicação, e outros que só existem para sistemas específicos. Para atender tal necessidade, o Modelo Conceitual foi dividido em três camadas que satisfaziam o requisito de separar conceitos pelo nível de especificidade que cada um tem no desenvolvimento de software. As camadas são: Camada de Conceitos Arquiteturais de Sistema; Camada de Conceitos do Domínio de Aplicação; Camada de Conceitos Específicos do Sistema.

3.2.1 Camada de Conceitos Arquiteturais de Sistema

Na Camada de Conceitos Arquiteturais do Sistema são especificados os conceitos de arquitetura e padrões genéricos que o sistema fará uso durante as demais fases de desenvolvimento de software. Fazem parte dessa camada os padrões que independem da plataforma, tecnologia ou linguagem de programação utilizada para desenvolver a aplicação

alvo. Podemos dar como exemplo os padrões arquiteturais existentes na literatura (BUSCHMANN et al., 1996), ou os padrões de projeto (LARMAN, 2006).

Um exemplo de padrões descritos na Camada de Conceitos Arquiteturais de Sistema pode ser vistos na Figura 19. Nessa figura é descrito o padrão MVC e as associações entre conceitos desse padrão. Na Figura 19 nós expressamos três conceitos: Model, View e

Controller. O conceito View está ligado ao conceito Controller através da associação ShowCnn que une papéis nomeados como show. Controller está associado ao conceito Model

através de duas associações, ModifyCnnMC e ConsultCnnMC que ligam respectivamente papéis de nome set e get. Model está ligado a si mesmo por meio das associações

ModifyCnnMM e ConsultCnnMM.

Figura 19. Exemplo de descrição do padrão MVC na Camada de Conceitos Arquiteturais de Sistema.

3.2.2 Camada de Conceitos do Domínio de Aplicação

A Camada de Conceitos do Domínio da Aplicação define conceitos que representam padrões específicos para um determinado domínio de aplicação alvo. Podemos citar um exemplo no domínio de aplicações multimídia, onde geralmente utilizam-se algum gerenciador de fluxo de dados para processar informações de áudio ou vídeo. Tal conceito foi representado na Figura 20 com o nome de StreamManager. StreamManager possui dois papéis outputDataStream e um papel inputDataStream. O papel inputDataStream de

StreamManager está ligado ao papel outputDataStream também de StreamManager . Esse

tipo de associação indica que conceitos do tipo StreamManager podem se comunicar entre si. O conceito Player (executor de mídia) está ligado ao conceito StreamManager através da associação inoutStreamCnn que recebe um fluxo de informações do StreamManager.

Figura 20. Descrição do Padrão StreamManager na Camada de Conceitos do Domínio da Aplicação.

3.2.3 Camada de Conceitos Específicos de Sistema

Nem sempre é possível expressar conceitos que farão parte de um sistema em termos de arquiteturas e padrões. Às vezes há conceitos que são tão específicos para uma determinada aplicação que eles só fazem sentido no contexto de um sistema em específico. Tais conceitos fazem parte dos requisitos do sistema e precisam ser referenciados. No entanto,

eles não se encaixam nas outras duas camadas anteriores, pois não constituem um padrão genérico, porém precisam ser especificados, porque fazem parte dos requisitos do sistema.

Para sanar esse problema, a Camada de Conceitos Específicos de 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 especificar componentes para permitir acesso de componentes da camada Controller, em um sistema que obedece ao padrão MVC, às entidades que representam as entidades do domínio do sistema (Model). Tal conceito pode ser nomeado como ModelAccessor e é mostrado na Figura 21. As instâncias que tiverem o papel de ModelAccessor agora podem ser referenciadas.

Figura 21. Descrição do Conceito ModelAccessor na Camada de Conceitos Específicos do Sistema.