visões arquiteturais - sistema integrado de gestão de ...thais/mes20072/aulavisoes.pdf– reuso de...
Post on 27-Aug-2020
3 Views
Preview:
TRANSCRIPT
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.
Arquitetura de Software – Thaís Batista
Visões Arquiteturais
• 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
Arquitetura de Software – Thaís Batista
Visões Arquiteturais
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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!
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Visão ConceitualComponente Conceitual
CComponent
CPort
Protocol
CConnector* *
*
*
1
obedec e
0..10..10..1
Elementos UML
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Visão ConceitualConector Conceitual
CComponent
CRole
Protocol
CConnector
*
*
*
1
obedec e
0..10..10..1
*
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Elemento UML
• O elemento NOTE é usado para descrever restrições adicionais que é difícil expressar com a notação gráfica
Voltar
Arquitetura de Software – Thaís Batista
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}
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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)
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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}
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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}
Arquitetura de Software – Thaís Batista
Visão de MóduloCamadas
• 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
Arquitetura de Software – Thaís Batista
Visão de MóduloCamadas
• 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
Arquitetura de Software – Thaís Batista
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}
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Visão de MóduloResumo da Representação
Artefato 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
Diagrama de Classes UML
Diagrama de Classes UML
Diagrama de Classes UML
Resumo das relações entre Módulos Tabela
10
Arquitetura de Software – Thaís Batista
Visão de Execução
• 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)
Arquitetura de Software – Thaís Batista
Visão de Execução
• Define:– Entidades de execução– Caminhos de Comunicação entre as entidades– Configuração de execução
Arquitetura de Software – Thaís Batista
Visã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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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.
Arquitetura de Software – Thaís Batista
Visão de ExecuçãoMeta-modelo para Entidades de Execução
Elemento daPlataforma
Entidade deExecução
Móduloassigned to*
* *
Is a
1
Arquitetura de Software – Thaís Batista
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)
Arquitetura de Software – Thaís Batista
Visão de ExecuçãoMeta-modelo para Comunicação
Mecanismo deComunicação
Elemento daPlataforma
Entidade deExecução
Is a
1
*COM IPC... RPCCaminho de
Comunicação
*
*
1
Use mecanismo
Comunica-se através
** consome
2..*
12
Arquitetura de Software – Thaís Batista
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)
Arquitetura de Software – Thaís Batista
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.
Arquitetura de Software – Thaís Batista
Visão de ExecuçãoResumo da Representação
Artefato 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
Diagrama de Classes UML
Protocolo de Comunicação Diagrama de Sequência ou Statechart
Arquitetura de Software – Thaís Batista
Visão de ExecuçãoMeta-modelo da Visão de Execução
Elemento daPlataforma
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Visão de CódigoComponentes Fonte
• 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.
Arquitetura de Software – Thaís Batista
Visão de CódigoComponentes 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
Arquitetura de Software – Thaís Batista
Visão de CódigoComponentes Fonte
• 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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
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
Arquitetura de Software – Thaís Batista
Visão de CódigoResumo da Representação
Artefato 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
Arquitetura de Software – Thaís Batista
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
Entidade deExecução
Módulo
Interface
*
*
1
* Instancia
0..1 segue
segue 0..1
0..1
0..1
top related