Visões Arquiteturais - Sistema Integrado de Gestão de ...thais/MES20072/aulaVisoes.pdf– Reuso de módulos deve ser maximizado Arquitetura de Software – Thaís Batista Visão

1

Arquitetura de Software – Thaís Batista

Visões Arquiteturais

• Separar diferentes aspectos em visões separadas com o objetivo de gerenciar complexidade.

• Cada visão descreve diferentes conceitos da Engenharia.

• Visões permitem reduzir a quantidade de informação que o arquiteto trata em um dado momento

• Muitos arquitetos de software tem usado as diferentes visões sem reconhecê- las como visões arquiteturais separadas.



• Quatro visões:– Conceitual: descreve o sistema em termos dos

elementos de design e relacionamentos entre eles– Módulo: consiste na decomposição do sistema em

módulos– Execução: consiste no mapeamento dos componentes a

entidades de execução e de hardware. Este mapeamento deve ser definido na fase de projeto arquitetural e não apenas na fase de desenvolvimento.

– Código: consiste na organização do código fonte em bibliotecas, binários, arquivos, versões e diretórios



Visão Conceitual

Visão de Módulo

Visão de Código

Visãode

Execução

Código Fonte

Componentes,Conectores,Configuração

restriçõesdos módulos

Módulos,Subsistemas,Camadas

NovosParticionamentosdos Módulos

Har

dwar

e

ARQUITETURA DE SOFTWARE

restrições deexecução

módulos

entidades deexecução

NovosParticionamentosdos Módulos

Componentes,Conectores,Configuração

Mudanças em entidades deexecução


Visão Conceitual

• Mais próxima ao domínio da aplicação• A funcionalidade do sistema é mapeada em

elementos arquiteturais:– Componentes, conectores, configuração

• Desafio: – Isolar comunicação entre componentes em

conectores

2


Visão de Módulo

• Componentes e Conectores que formam a visão conceitual são mapeados em subsistemas e módulos– Dependências entre módulos devem ser

minimizadas– Reuso de módulos deve ser maximizado


Visão de Execução

• Descreve como os módulos são mapeados para elementos oferecidos pela plataforma de execução e como estes são mapeados para o hardware

• Define entidades de execução e seus atributos como uso de memória e de elementos de hardware


Visão de Código

• Determina:– como as entidades de execução da visão de

execução são mapeadas a componentes a nível de implementação (p.ex. executáveis)

– como módulos da visão de módulo são mapeados em componentes fonte

– como componentes a nível de implementação são mapeados a partir dos componentes fonte


Relacionamento entre as Visões

• Há necessidade de feedback e interação entre as visões

• As visões módulo, execução e código auxiliam a diminuir o gap entre o que uma ADL modela e o que uma plataforma de execução pode executar.– Componentes e conectores da visão conceitual não

podem ser diretamente mapeados para uma plataforma de execução

– As visões módulo e execução definem como componentes e conectores são mapeados para uma plataforma de execução

3


Visão Conceitual

• Definir componentes, conectores e configuração– Mapear comportamento funcional do sistema

em componentes– Mapear os aspectos de controle e comunicação

em conectores– Definir as instâncias dos componentes e

conectores e como elas são interconectadas

Estilos Arquiteturais podem ser utilizados nesta fase!


Visão Conceitual

• Componentes Conceituais– Contém PORTAS que são pontos de interação – PORTAS ≠ INTERFACE

• Serviços Oferecidos X Serviços Requisitados– Interface define serviços e operações que o componente

OFERECE não o que ele USA.– Portas definem tanto serviços que o componente oferece

quanto os que o componente usa.• Implementação

– Cada porta tem um protocolo associado que diz como as operações são encaminhadas


Visão ConceitualComponente Conceitual

CComponent

CPort

Protocol

CConnector* *

*

*

1

obedec e

0..10..10..1

Elementos UML


Elementos UML

• Caixas são classes na notação UML• Linhas são relações

– Linhas com o diamante sólido significa composição: as classes ligadas ao diamante é decomposta ou contém as classes da outra extremidade. A multiplicidade da relação é exibida pelo número (ou um asterisco para zero ou mais) próximo ao fim da relação

Voltar

4


Visão Conceitual

• Conectores Conceituais– Contém PAPÉIS (ROLES) que são pontos de

interação– Os Papéis obedecem a um protocolo associado – Podem ser decompostos em Componentes e

Conectores


Visão ConceitualConector Conceitual

CComponent

CRole

Protocol

CConnector

*

*

*

1

obedec e

0..10..10..1

*


Visão Conceitual

• Configuração Conceitual– Define relações entre componentes e conectores– Componentes e Conectores são interconectados

através de suas portas e papéis – Podem ser decompostos em Componentes e

Conectores


Visão ConceitualConfiguração Conceitual

CPort CRole

** * *

**

cconection

cbinding cbinding

Elemento UML

{cconection pode conectar cport ecrole apenas quando o eles temprotocolos compatíveis}

{cconection pode conectar cporte crole apenas quando o respectivocomponente e conector são em-capsulados pelo mesmo elemento}

5


Elemento UML

• O elemento NOTE é usado para descrever restrições adicionais que é difícil expressar com a notação gráfica

Voltar


Visão ConceitualMeta-Modelo da Estrutura

ConfiguraçãoConceitual

1 1

CComponent CConnector

CPort

*

0..10..10..1

**

cbinding

Protocol

*

1

obedec e

*CRole*

* * *cconection

cbinding

1

0..10..10..1

*

*

* * **

obedec e

{cconection pode conectar cport ecrole apenas quando o eles temprotocolos compatíveis}

{cconection pode conectar cporte crole apenas quando o respectivocomponente e conector são em-capsulados pelo mesmo elemento}


Visão Conceitual

• Além de descrever a estrutura de componentes, conectores e da configuração, é necessário descrever os aspectos comportamentais– UML Statechart Diagram


Visão ConceitualResumo da Representação

Artefato Representação

Configuração Conceitual

Protocolo de Porta ou Papel

Comportamento do Componenteou do Conector

Interações entre Componentes

Diagrama de Classes UML

Diagrama de Statechart UMLou diagrama de Sequência

Diagrama de Statechart UMLou descrição em ling. natural

Diagrama de Sequência UML

6


Visão de Módulo

• Componentes e Conectores que formam a visão conceitual são mapeados em subsistemas e módulos

• Diferença da Visão Conceitual para a Visão de Módulo– Cada uma torna explícito diferentes aspectos

• Na visão conceitual os relacionamentos funcionais devem estar explícitos

• A visão de módulo torna explícito como a funcionalidade é mapeada para a implementação


Relacionamento Visão Conceitual x Visão de Módulo

• A Visão Conceitual e a Visão de Módulo são baseados em dois diferentes modelos:– Visão Conceitual: componentes implementam a

funcionalidade da aplicação e interagem via conectores.

– Visão de Módulo: toda a funcionalidade da aplicação e a comunicação devem ser mapeada em módulos


Relacionamento Visão Conceitual x Visão de Módulo

• Visão Conceitual– Dois componentes comunicam-se através de um

conector com semântica call/return

• Visão de Módulo– Representa em módulos os elementos da

implementação que poderá ter duas variações:• Os dois componentes na mesma máquina: o conector

implementa uma chamada de procedimento local• Os dois componentes em máquinas diferentes: o conector

implementa chamada remota de procedimento (RPC)


Visão de Módulo

• Definir módulos que possuem interface com os serviços oferecidos (provided) e requisitados (required)

• Módulos interagem invocando serviços declarados na sua interface required

• Módulos não possuem implementação associada

7


Visão de Módulo

• Não define uma configuração– Define os módulos e seus relacionamentos mas

não como eles são combinados em um produto particular (as visões conceitual e de execução define a configuração)

• Resultados da Visão de Módulo:– Módulos, Subsistemas e Camadas


Visão de MóduloSubsistema

• Usualmente corresponde ao componente conceitual de mais alto nível (aquele que é decomposto em outros componentes e conectores)

• Contém outros subsistemas e módulos


Visão de MóduloMódulo

• Pode corresponder a um único elemento conceitual (componente, porta, conector ou papéis) ou a um conjunto deles.

• Podem ser decompostos em outros módulos• Encapsula dados e operações para prover

um serviço


Visão de MóduloMódulo

• Serviços:– Os serviços oferecidos por um módulo são definidos

pelas interfaces que ele oferece (provided)– Os serviços que um módulo precisa de outro módulo

para realizar suas funções são os serviços requisitados e são definidos pelas interfaces que ele solicita (required)

• Interagem com outros apenas através das interfaces

8


Visão de MóduloMeta-modelo para Subsistemas e Módulos

Subsistema

Módulo

*

***

contém 0..10..1

0..1

contém

use*

Interfaceprovide

require*

*

**{Módulo A usa Módulo Bquando A requisita uma interface que B oferece}


Visão de MóduloCamadas

• Camadas organizam módulos em uma hierarquia • Quando um módulo é associado a uma camada,

ele pode usar outros módulos desta camada• Quando um módulo necessita usar serviços de um

módulo de outra camada, a interface solicita e requisitada pelos módulos devem ser também requisitas e solicitadas pelas camadas.

• Camadas podem ter subcamadas


Visão de MóduloMeta-modelo para Camadas

Interface

CamadaMódulo

*

*

*

cont

ém

0..1

0..1

*assigned to

*

*use

*

*

require

provide {Camada A usa camada Bquando A requisita uma interface que B oferece}



• Utilidade– Reduzir complexidade – Permitir reuso atribuindo serviços comuns a

camadas de serviços da aplicação– Oferecer independência entre partes do sistema

evitando que a mudança em uma parte afete o sistema inteiro

9



• Como definir Camadas– Top-down: determine as camadas baseadas na

experiência. Atribua os módulos às camadas. (As camadas servem de guia para definição dos módulos)

– Bottom-up: determine os módulos, suas responsabilidades e dependências. Em seguida determine as camadas.

Estratégia Top-Down + Bottom-Up: divida em camadas genéricas(aplicação, interface com usuário, serviços do sistema).Quando definir os módulos refine o modelo em camadas adicionandocamadas que tratem da funcionalidade específica da aplicação


Visão de MóduloMeta-Modelo

Subsistema*

*

**

contém 0..10..1

0..1

contém

use*

Interfaceprovide

require*

*

**CamadaMódulo

*

*

*

cont

ém

0..1

0..1

*

assigned to

*

*use

**

require

provide

{Camada A usa camada Bquando A requisita uma interface que B oferece}


Visão de MóduloTarefas

• Mapear os elementos da visão conceitual em CAMADAS, SUBSISTEMAS e MÓDULOS

• Atribuir aos módulos uma responsabilidade e determinar sua composição e seus relacionamentos

• Pode ser necessário adicionar módulos de suporte que não tem correspondente na visão conceitual

• Descrever as interfaces para cada um dos módulos e camadas


Visão de MóduloResumo da Representação


Correspondência Conceitual-Módulo

Subsistemas e Módulos

Dependências dos Módulos

Dependências de Camadas, Atribuição de Módulos a Camadas

Tabela




Resumo das relações entre Módulos Tabela

10



• Descreve a estrutura do sistema em termos de elementos da plataforma de execução (p.ex. tarefas do SO, processos, threads).

• Recebe como entrada o Modelo Conceitual e o Modelo de Módulos

• É necessário conhecer a plataforma de hardware (todos os componentes de hardware disponíveis) e a plataforma de software (os softwares que estão entre o hardware e o sistema projetado – SO, software de rede, middleware)



• Define:– Entidades de execução– Caminhos de Comunicação entre as entidades– Configuração de execução



• Atividades Iniciais:– Liste os componentes de hardware do ambiente

de execução– Liste a plataforma de software – Liste os elementos da plataforma que serão

usados na visão de execução


Visão de ExecuçãoMeta-Modelo dos Elementos da Plataforma

Elemento daPlataforma

1*

Plataformade Software

Recurso daPlataforma

Recurso deHardware assigned to

Thread

Processo

Task

Socket

Queue

consome

Memória

Espaço Ender

Timer ......

**

* *

contém

11


Visão de ExecuçãoEntidades de Execução

• Após identificar os elementos da plataforma de software deve- se decidir como mapear os componentes conceituais e módulos para os elementos da plataforma– Um ou mais módulos são representados por uma

entidade de execução e um módulo pode ser atribuído a mais de uma entidade de execução

– Podem existir entidades de execução como processos servidores que não tenham correspondência direta com módulos mas são necessários para dar suporte a outras entidades de execução.


Visão de ExecuçãoMeta-modelo para Entidades de Execução


Entidade deExecução

Móduloassigned to*

* *

Is a

1


Visão de ExecuçãoCaminho de Comunicação

• Identificar os caminhos de comunicação entre as entidades de execução (mecanismos e recursos usados para comunicação)


Visão de ExecuçãoMeta-modelo para Comunicação

Mecanismo deComunicação



Is a

1

*COM IPC... RPCCaminho de

Comunicação

*

*

1

Use mecanismo

Comunica-se através

** consome

2..*

12


Visão de ExecuçãoConfiguração de Execução

• Descreve a topologia de execução do sistema caracterizando as instâncias das entidades de execução e como elas são interconectadas.

• Há distinção entre uma entidade de execução e suas correspondentes instâncias (exceto quando só há uma instância)


Visão de ExecuçãoConfiguração de Execução

• Deve-se determinar e descrever como a configuração muda ao longo do tempo e como estas mudanças são controladas.


Visão de ExecuçãoResumo da Representação


Configuração de ExecuçãoConfiguração de Execução mapeadasa dispositivos de hardware

Comportamento dinâmico da configu-ração, ou transição entre configurações

Descrição das entidades de execu-ção (tipos de host, replicação, etc)

Diagrama de DesenvolvimentoUML

Diagrama de Classes UMLou Tabela

Diagrama de Sequência UML


Protocolo de Comunicação Diagrama de Sequência ou Statechart


Visão de ExecuçãoMeta-modelo da Visão de Execução


1*

Plataformade Software

Recurso daPlataforma

Recurso deHardware assigned to

consome

**

* *

contém

Mecanismo deComunicação

*

consome

Caminho de Comunicação

Entidade de Execução

Módulo**assigned to

*

1

Mecanismo use

* Comunica-se através 2..*

*Is a

1

13


Visão de Código

• Descreve como o software que implementa o sistema é organizado

• O objetivo principal desta visão é facilitar a construção, integração, instalação e teste do sistema respeitando a integridade das outras três visões arquiteturais


Visão de Código

• Descreve como um módulo, suas interfaces e suas dependências são mapeadas a componentes e dependências específicas da linguagem. Estes mapeamentos e convenções podem variar de acordo com a linguagem de programação

• As visões de módulo e de execução são independentes de linguagem de programação


Visão de Código

• Com um executável– Visão de código reflete a estrutura da visão de

módulo• Com múltiplos executáveis

– Visão de código torna- se mais complexa e em geral diverge da visão de módulo e da visão de execução


Visão de Código

• Tarefas:– Mapear os elementos da visão de módulo e da

visão de execução para componentes de código:• Componentes Fonte• Componentes Intermediários (componentes binários,• Componentes de Desenvolvimento (executáveis,

bibliotecas dinâmicas e descrição da configuração)

14


Visão de CódigoMeta-modelo dos elementos básicos

ComponenteFonte

ComponenteBinário

Biblioteca Executável Descrição daConfiguração

compile

compile

linklink Usa na execução

link

**

gera* * * * * * * * * *1

1*

*importa


Visão de CódigoComponentes Fonte

• Tipicamente componentes fontes representam as interfaces e módulos específicos da linguagem– Exemplo: em C/C++ interfaces específicas da

linguagem são arquivos com nomes como *.h e módulos tem nome com *.c e *.CPP



• São relacionados com outros por dois tipos de dependências específicas da linguagem:– Importação: um componente precisa importar

outro. Esta relação é uma dependência de compilação. Por exemplo: a dependência de inclusão entre um componente fonte e um arquivo de cabeçalho

– Geração: quando um componente fonte é gerado a partir de outro componente fonte.



• Para identificar componentes fonte:– Identificar componentes fonte e mapear os

elementos e dependências da visão de módulo para componentes fonte e dependências

– Organizar os componentes fonte usando estruturas de armazenamentos como diretórios e arquivos

• É necessário definir um critério de organização dos arquivos: similaridade de funcionalidade, pessoa responsável pelo desenvolvimento, etc...

15



• Elementos da visão de módulo são mapeados em componentes fonte específicos de linguagem que implementa- os. Por exemplo: Mapeando para C++, a interface de um módulo é mapeada em um arquivo .h e o código é mapeado em um arquivo .CPP

• Para módulos complexos pode ser necessário distribuir a implementação em vários arquivos


Visão de CódigoComponentes Intermediários

• São específicos da linguagem de programação e do ambiente de desenvolvimento. – Exemplo: Em C++, para cada arquivo .CPP tem

um componente binário correspondente ou arquivo .obj

• Binários e Bibliotecas Estáticas são componentes intermediários


Visão de CódigoComponentes de Desenvolvimento

• São componentes necessários para formar um sistema executável– Executáveis, bibliotecas dinâmicas e

descrições de configuração• A descrição da configuração pode descrever

processos e/ou recursos


Visão de CódigoResumo da Representação


Correspondência Módulo-Comp.Fonte

Correspondência Executável –entidade de execução

Descrição dos componentes da Visão de código e suas dependências

Tabela

Tabelas

Diagrama de Componentes UML

16


Visão de CódigoMeta-modelo

ComponenteFonte

ComponenteBinário

Biblioteca Executável Descrição daConfiguração

compile

compile

linklink Usa na execução

link

**

gera* * * * * * * * * *1

1*

*importa

Grupo de CódigoSubsistema

Camada


Módulo

Interface

*

*

1

* Instancia

0..1 segue

segue 0..1

0..1

0..1

Documents

Visões Arquiteturais - Sistema Integrado de Gestão de ...thais/MES20072/aulaVisoes.pdf– Reuso de módulos deve ser maximizado Arquitetura de Software – Thaís Batista Visão