Linguagens de Descrição Arquitetural: Motivação e ACME. Jair C Leite

(1)

Linguagens de Descrição Arquitetural:

Motivação e ACME

Jair C Leite

Motivação

• A visão emergente da arquitetura de software, a partir de meados de 90, possui requisitos que não são atendidos por linguagens de modelagem tradicionais • Problemas

– Elas oferecem apenas um única forma de conexão: • Chamada de função, procedimento ou método

– Não permitem a descrição hierárquica de sistemas em diferentes níveis de abstração

– Não permitem definição de famílias de sistemas

– Não oferecem para a análise de propriedades não funcionais (desempenho, segurança, disponibilidade)

(2)

Arquitetura de Software, © Jair C Leite e Thais V Batista

Linguagens de Descrição Arquitetural

• Linguagens de Descrição Arquitetural são aquelas projetadas para descrever a arquitetura na visão de componentes, conectores e configurações

• Existem varias linguagens para descrição de arquiteturas

• ACME é uma linguagem de referência para ADLs • A UML 1.x não oferece recursos para ser considerada

uma ADL

• A UML 2.0 oferece alternativas para alguns aspectos de ADL

Exemplos de ADLs

• Em geral cada ADL oferece capacidades específicas – AESOP: permite o uso de estilos arquiteturais

– ADAGE: permite a descrição de frameworks arquiteturais para sistemas de aviação

– C2: permite a descrição de sistemas de interface com usuário usando um estilo baseado em mensagem

– Wright: suporta a especificação e análise de interações entre componentes arquiteturais

– Rapide: permite a simulação e análise de diferentes soluções arquiteturais

– UniCon: possui um compilador alto-nível com suporte a diferentes tipos de componentes e conectores

(3)

ACME

• Motivação:

– Proliferação de ADLs

– Necessidade de um formato “padrão”

• Metas

– Permitir a integração de diferentes

ferramentas oferecendo uma forma comum

de intercâmbio arquitetural

– Permitir o desenvolvimento de arquitetura

compatível com múltiplas ADLs

– Esclarecer o relacionamento entre diferentes

ADLs

http://www.cs.cmu.edu/~acme

ACME – Linguagens e ferramentas

• Possuem 3 capacidades fundamentais

– Descrição arquitetural

• Oferecer os recursos necessários para satisfazer todos os requisitos de uma descrição arquitetural

– Intercâmbio arquitetural

• Formato de intercâmbio genérico para arquiteturas produzidas por diferentes ferramentas

– Fundamentos extensíveis para ferramentas

de design e análise arquitetural

(4)

ACME - Objetivos Secundários

• Oferecer um esquema para representação de

arquiteturas que irá permitir o desenvolvimento

de novas ferramentas para análise e

visualização de estruturas arquiteturais

• Oferecer uma fundamentação para o

desenvolvimento de ADLs

• Servir como veículo para criar convenções e

padrões para informação arquitetural

• Oferecer descrições expressivas que são fáceis

de ler e escrever

ACME - Exemplo

System simple_client_server = {

Component client = { Port send-request } Component server = { Port receive-request } Connector rpc = { Roles {caller, callee} } Attachments: {

client.send-request to rpc.caller ; server.receive-request to rpc.callee } }

(5)

ACME - Características

• Ontologia arquitetural

– Sete elementos para design arquitetural

• Mecanismo de Anotação

– Suporte a associação de informação não

estrutural usando sub-linguagens definidas

externamente

• Mecanismo de Tipos

– Para definir estilos e padrões reutilizáveis

• Framework de semântica aberta

– Para analisar as descrições arquiteturais

ACME - Elementos

• Sete tipos de entidades para representação arquitetural: – Componentes – Conectores – Sistemas – Portas – Papéis – Representações – Rep-Maps

(6)

ACME - Componentes

• Componentes

– Elementos primários de computação e

armazenagem de dados

• Exemplos típicos:

– Clientes

– Servidores

– Filtros

– Objetos

– Repositórios (blackboard)

– Banco de dados

Client _Server

ACME - Conectores

• Representam interações entre componentes

• Intermediários na comunicação e coordenação

entre componentes

• Exemplos:

– Chamadas de função, procedimento ou método – Eventos

– RPC (chamada de procedimento remota) – Tubos (entre filtros)

– Protocolos de comunicação

(7)

ACME - Sistemas

• Representam configurações de componentes e

conectores

• A topologia de um componentes é descrita por

uma lista de attachments

Client RPC Server System

ACME - Attachments

• Um attachment define como conectores e

componentes estão ligados numa configuração

• As ligações são feitas conectando-se portas do

componentes a papeis dos conectores

Portas

(8)

Exemplo (novamente)

Client _Server Portas Papéis System System simple_client_server = {

Component client = { Port send-request } Component server = { Port receive-request } Connector rpc = { Roles {caller, callee} } Attachments: {

client.send-request to rpc.caller ; server.receive-request to rpc.callee } }

ACME - Portas

• Interfaces dos componentes são definidas

por portas

– Cada porta identifica um ponto de interação

entre o componente e seu ambiente

– Um componente pode prover múltiplas

interfaces usando diferentes tipos de portas

• Exemplos

– Assinaturas de Métodos

– Coleção de chamadas de procedimentos que

devem ser invocadas

(9)

ACME - Papéis

• Interfaces dos Conectores são definidas por papéis • Cada papel de um conector define um participante da

interação representada pelo conector • Conectores Binários têm dois papéis:

– Em RPC: Caller (chamador) e Callee (chamado) – Em um Pipe: Leitor e Escritor

• Outros tipos de conectores podem ter mais que dois papéis.

– Exemplo: Broadcast de eventos pode ter um papel de um

announcer e um número arbitrário de papeis de receiver.

Connector EventBus = { Role Pusblisher; Role Listener1; Role Listener2; } Connector req = { Role requestor; Role requestee; }

ACME – Exemplo (revisão)

System ClientServerSystem = { Component server = { Port requests; }; Component client1 = { Port makeRequest; }; Connector req = { Role requestor; Role requestee; }; Attachments { server.requests to req.requestor; client.makeRequest to req.requestee; } }

(10)

ACME - Representação

• Usado para descrição da representação hierárquica de arquiteturas

• O uso de múltiplas representações permite expressar múltiplas visões das entidades arquiteturais

Component server = { Port receiveRequest; Representation serverDetails = { Component connectionManager = { Port {securityCheck} … } } }

ACME – Representação - exemplo

• O exemplo abaixo mostra um componentes que é detalhado em dois componentes. Component theComponent = { Port easyRequests; Port hardRequests; Representation { System details = {

Component fastButDumbComponent = {Port p; }; Component slowButSmartComponent = { Port p;}; }; Bindings { easyRequests to fastButDumbComponent.p; hardRequests to slowButSmartComponent.p }; }; }; theComponent fastButDumbComponent easyRequests

(11)

Visualização das representações

Client _Server Portas Papéis System Representação com pouca memória Representação de alto desempenho

ACME - Propriedades

• Para acomodar a ampla variedade de informações auxiliares, ACME suporta anotação de estruturas arquiteturais com listas de propriedades

• Cada propriedade tem: nome, tipo opcional e valor • Qualquer um dos sete tipos de entidades arquiteturais

ACME podem ser anotadas

Component server = { Port receiveRequest;

Properties { idempotent : boolean = true; maxConcurrentClients : integer = 1; Component Server = {

Port requests;

Properties {responsetime : Float = 15.00 << units="ms">>;} }

(12)

ACME - Exemplo com Propriedades

System simple_cs = { Component client = { Port send-request;

Properties { Aesop-style: style-id = client-server; Unicon-style: style-id = cs;

source-code: external = “CODE-LIB/client.c” }} Component server = {

Port receive-request

Properties { idempotence: boolean = true;

max_concurrent_clients : integer = 1;

source-code: external = “CODE-LIB/server.c” }} Connector rpc = { Roles {caller, callee} }

Properties { synchronous : boolean = true; max_roles : integer = 2;

protocol = Wright = “...” }} Attachments: {

client.send-request to rpc.caller ; server.receive-request to rpc.callee } }

ACME – Modelando Tubos e Filtros

System TwoFiltersOnePipe = { Component Filter1 = { Port out;

Property implementation : String = "while (!eof) {

compute; out.write}"; }

Component Filter2 = { Port in;

Property implementation : String = "while (!in.eof) { compute; in.read}"; } Conector Pipe = { Role from; Role to;

Property buffersize: int = 10; Attachments { Filter1.out to Pipe.from; Filter2.in to Pipe.to; Filter 1 Filter 2 Pipe out in to from

(13)

ACME – Definindo famílias e tipos

Family PipeFilterFam = { Component Type FilterT = { Ports (in; out;}

Property throughput: int; ; }

Conector Type PipeT = { Roles {source; target; }; Property buffersize : int; }

}

System simplePF : PipeFilterFam = {

Component Filter1 : FilterT = new FilterT; Component Filter2 : FilterT = new FilterT; Component Filter3 : FilterT = new FilterT; Conector first : PipeT = new PipeT; Conector second : PipeT = new PipeT; Attachments { Filter1.out to first.source; Filter2.in to first.target; Filter2.out to second.source; Filter3.in to second.target;

Armani

• Armani

– Uma extensão de ACME

– Composta por:

• Uma Linguagem para descrever a arquitetura de software (ADL) - ACME

• Uma Linguagem de Restriçoes (Constraint

language) que é uma linguagem baseada em

lógica de predicados de primeira ordem • O ambiente Armani (Armani environment)

(14)

Armani

• Linguagem Declarativa

– Estrutura Arquitetural e restrições (constraints) sobre a estrutura

• Constraints

– Permite determinar INVARIANTES associados a elementos arquiteturais – Exemplos: • Topologia • Properties • Tipos de Elementos • Comportamento do Sistema

• Possiveis configurações durante a execução

Exemplo de Constraints…

System simpleCS = { …

// simple rule requiring a primary server

Invariant exists s : server in self.components |

s.isPrimaryServer == true; // simple performance heuristic

Heuristic forall s : server in self.components |

s.transactionRate >= 100; // do not allow client-client connections

Function no-peer-connections(sys : System) =

forall c1, c2 in sys.components | connected(c1, c2) ->

!(declaresType(c1,clientT) and declaresType(c2, clientT)); … };

(15)

Tipos

• Armani tem um sistema de tipos:

– permite verificar as restrições para um dado

tipo (útil para evolução)

– suporta duas categorias de tipos de

expressões:

• Tipos de Elementos: component, connector, port and role types

• Tipos de Propriedades: primitive, compound

• O sistema de tipos de Armani system é

chamado de Estilo Arquitetural

Exemplo de Types…

• Component Type

Component Type Client = {

Port request = {Property protocol: string =

“sun-rpc”};

// all ports must support the sun-rpc protocol

Invariant forall p in self.Ports p.protocol =

“sun-rpc”; … }

• Criando uma Instância

(16)

Estilo Arquitetural

• Um “pacote” de elementos Armani e

constraints

• Um estilo é um tipo de um sistema

– Exemplo: client-server style,

publish-subscribe style

• Tipos determinam o “vocabulário” do estilo

Exemplo de Styles…

Style client-server-style = {

// declare vocabulary

Component Type client = {...};

Component Type server = {...};

...

Function no-peer-connections(sys : System)

= { ... };

...

Invariant no-peer-connections(self);

Heuristic forall s : server in self.components|

s.transactionRate >= 100;

...

(17)

Tipos v/s Styles

• Tipos

– Define uma coleção de elementos arquiteturais relacionados

– Exemplos: filter component, pipe-connector, client-server connector, dataflow-input-port

• Styles

(chamados de “Familias”)

– Uma coleção de tipos e um conjunto de restrições – Tipos determinam o “vocabulario” do estilo

– Constraints determinam como o vocabulario pode ser usado

– Exemplos: pipe-filter family, client-server family

Extend with clausula

• É possível estender uma instância de um

tipo

• Útil para subtipagem

Component Type Specialclient extends Client with {

Port Request = {Property protocol…}; Invariant timeout < 60.0;

}

Component c = { … };

extended with {Representation r1 = {…};

(18)

Predicados

• Funções definidas pelo usuário que

podem ser invocadas por Invariantes e

Heurísticas

Function no-peer-connections(sys : System) = forall c1, c2 in sys.components | connected(c1, c2) ->

!(declaresType(c1,clientT) and declaresType(c2, clientT)); … };

Exemplo Geral

System simple_cs = { Component client = { Port send-request;

Properties { Aesop-style: style-id = client-server; Unicon-style: style-id = cs;

source-code: external = “CODE-LIB/client.c” }}

Component server = {

Port receive-request

Properties { idempotence: boolean = true;

max_concurrent_clients : integer = 1; source-code: external =

“CODE-LIB/server.c” }}

Connector rpc = { Roles {caller, callee} }

Properties { synchronous : boolean = true; max_roles : integer = 2; protocol = Wright = “...” }} Attachments: {