Novo Linguagens de Definição de Arquitetura de softwareMental

1. Alguns Requisitos Mínimos de uma ADL

1.1. Comunicação – A ADL deve descrever adequadamente as estruturas estáticas e dinâmicas da arquitetura, permitindo a comunicação entre os participantes.

1.2. Estilo – A ADL deve ser capaz de representar a maioria dos estilos de arquitetura em diferentes níveis de abstração

1.3. Formalidade e precisão – Uma notação formal que permite a descrição precisa e a análise das propriedades externamente visíveis de uma arquitetura de sistema de software

1.4. Granularidade – Uma linguagem voltada para especificar a estrutura de alto nível de uma aplicação (ou seja, a arquitetura conceitual), ao invés de se preocupar com detalhes de implementação de um módulo de código específico.

1.5. Processo – A ADL deve suportar as atividades de criação, refinamento e validação da arquitetura.

1.6. Abstração – A ADL deve ser capaz de representar estruturas do sistema que expressem informação arquitetural, omitindo informações de implementação ou que não se referiram à arquitetura.

1.7. Continuidade – A ADL deve ser a base para promover a implementação

1.8. Verificação – A ADL deve ser capaz de gerar rapidamente um protótipo de implementação para análise das informações no nível arquitetural (capacidade analítica), por exemplo: consistência, ambigüidade, performance.

1.9. niversalidade – Deve ser uma linguagem de leitura acessível a humanos e computadores.

1.10. Automação – Deve possibilitar a geração automática do código a partir do esqueleto arquitetural.

2. Elementos da ADL

2.1. Componentes São unidades de computação ou armazenamento de dados, geralmente com um estado associado. Dependendo do nível de abstração, componentes podem ser uma simples procedure ou uma aplicação inteira (SOARES NETO, 2003). A interface de um componente é o conjunto de pontos de interação entre o componente e o mundo externo. Tal interface especifica os serviços (mensagens, operações e variáveis) que um componente fornece e também os serviços requisitados de outros componentes, e são comumente chamadas de portas

2.2. Conectores São elementos usados para modelar interações entre componentes e as regras que as governam. Eles não realizam computação específica na aplicação, mas sua interface exporta os serviços que esperam dos componentes que se ligam a eles. A interface de um conector é um conjunto de pontos de interação (papéis ou roles), que se dão entre ele e componentes ou entre ele e outros conectores. Isso fundamenta as configurações arquiteturais, permitindo a conectividade apropriada dos componentes e sua interação na arquitetura (SOARES NETO, 2003). Na linguagem Wright, aparece um outro elemento do conector, chamado glue (a cola, o adesivo). Enquanto a role especifica o que um participante deve fazer, a glue descreve como os participantes trabalham juntos para criar uma composição. Por isso, a glue representa a especificação comportamental do conector

3. Exemplos de Uso de ADL

3.1. ACME Exemplo 1 – É uma simples representação formal de um sistema do tipo cliente-servidor, com chamada remota de procedimento (Figura 7.2). Foram definidas apenas as configurações mínimas: o componente cliente (aquele que envia requisições, send-request); o componente servidor (o que recebe requisições, receive-request); o conector rpc, com os papéis caller (entrada do conector) e callee (saída do conector); os attachments, que definem a interação entre os elementos citados – o cliente faz uma requisição, que é enviada pela porta de entrada do conector; essa mesma requisição chega até a porta de saída do conector, quando é, então, repassada ao servidor.

4. Algumas ADLs Atuais

4.1. UML – Até mesmo esta linguagem de modelagem pode ser empregada como ADL, pela existência dos diagramas classes, pacotes, colaboração e máquina de estados, entre outros.

4.2. Aesop – Suporta o uso de estilos arquiteturais

4.3. Darwin – Oferece suporte para análise na troca de mensagens em sistemas distribuídos.

4.4. MetaH – Possui heurísticas para projetistas de controles de software de tempo real para aviação e controle de vôos.

4.5. AO-ADL – Às facilidades de uma ADL clássica, acrescenta mecanismos para a modelagem dos aspectos ou interesses transversais.

4.5.1. Wright – Modelagem e análise (especificamente análise de deadlocks) do comportamento dinâmico de sistemas concorrentes.

4.6. C2 SADL – Oferece suporte à descrição de interfaces baseadas em eventos.

4.7. Rapide – Permite simular e analisar projetos de arquitetura

4.8. Unicon – Usada para modelar arquiteturas em alguns estilos. A versão atual suporta pipe-filtro, chamada de procedimento com dados compartilhados, sistemas distribuídos com chamadas RPC, processamento real-time e acesso a banco de dados com SQ

4.9. Weaves: – Suporta a contínua observação e o rearranjo dinâmico de sistemas de estilo fluxo de dados para facilitar a construção e análise: partes do sistema podem ser snipped e spliced, sem corromper o fluxo.

4.10. Wright – Modelagem e análise (especificamente análise de deadlocks) do comportamento dinâmico de sistemas concorrentes.

5. ADL x Outras Linguagens

5.1. ADLs X linguagens para descrição de requisitos – Estas descrevem espaço de problemas, enquanto aquelas buscam o espaço de solução

5.2. ADLs X linguagens de programação – Estas fazem amarração das abstrações arquiteturais para pontos de solução específicos, enquanto as ADLs omitem ou variam tais amarrações.

5.3. ADLs X linguagens de modelagem – Estas se preocupam mais com o comportamento do todo do que das partes, mas as ADLs concentram-se na representação de componentes e suas interconexões. No entanto, pode haver ADLs de domínio específico.