Modelagem de Arquitetura com UML
CIn-UFPE
1
Arquitetura de software

“Uma arquitetura de software deve conter: a
definição dos elementos de projeto que compõem o
software; a descrição das interações entre estes
elementos; os padrões de composição dos
elementos; e um conjunto de restrições sobre
estes padrões.” [Shaw 96]
CIn-UFPE
2
Arquitetura de software

Modelo de Shaw, 1996

componentes

conectores

configuração
CIn-UFPE
3
Arquitetura de software

Componente

modela a computação e/ou armazenamento de informações

desenvolvido independentemente

exemplos de componentes
cliente
servidor
banco de dados
aplicação inteira
CIn-UFPE
4
Arquitetura de software

Conector

modela as interações entre os componentes

desenvolvido independentemente

exemplos de conectores
protocolos de comunicação
Middleware (ex: CORBA, RMI)
CIn-UFPE
5
Arquitetura de software

Configuração

topologia

conjunto de componentes combinados usando-se os
conectores

grafo de componentes e conectores ligados, descrevendo
uma estrutura arquitetural
CIn-UFPE
6
Arquitetura de software

Principais motivações para definição de uma
Arquitetura de Software:

reuso de elementos de projeto permitindo maior rapidez na
construção do software;

facilita a comunicação entre os stakeholders do sistema.
CIn-UFPE
7
Uso de UML como uma
“ADL” (Architecture Description Language)

Mesmo havendo uma “perda” em capturar todos os aspectos de
uma arquitetura, o uso de UML tem sido crescente

Vantagens:

Uso de uma notação amplamente conhecida em “oposição”
às ADLs

Notação acessível para arquitetos, desenvolvedores e
gerentes

Permite ilustrar múltiplas visões
CIn-UFPE
8
Múltiplas Visões

Vários stakeholders têm diferentes conceitos e
interesses em aspectos distintos da arquitetura.

Assim como na construção civil, diferentes tipos de
“plantas” são usadas para representar diferentes
aspectos da arquitetura.
CIn-UFPE
9
Múltiplas Visões

De forma similar, na arquitetura de software pode-se
usar várias “plantas” para diversos propósitos:

Para organizar a funcionalidade do sistema em termos de
elementos do domínio;

Para tratar da decomposição lógica do sistema;

Para tratar aspectos de concorrência (em tempo de
execução);

Para tratar do mapeamento de módulos e interfaces para
arquivos fontes.
CIn-UFPE
10
Múltiplas Visões

Diferentes visões tratam de aspectos distintos
durante o desenvolvimento de um sistema. Exemplo
de abordagens:

Kructhen - O Modelo 4 + 1: Lógica, Processo, Física,
Implantação e Casos de Uso.
CIn-UFPE
11
Arquitetura de software
O modelo de “4+1 Visões”
Estrutura
Analista de
Sistemas
Estrutura,
componentes
Programadores
Visão
Lógica
Visão de
Implementação
Visão de Casos
de Uso
Arquiteto
Visão de
Processos
Arquiteto
CIn-UFPE
Escalabilidade
Visão de
Distribuição
Arquiteto
Topologia,
implantação,
comunicação
12
Múltiplas Visões

Soni, Nord e Hofmeister: Consideram a representação da
arquitetura de software em 4 visões:
visão conceitual
visão de módulo
visão de execução
visão de código
CIn-UFPE
13
Visão Conceitual

Captura aspectos funcionais do sistema

Stakeholder interessado: Usuário final

Descrição da arquitetura em termos de elementos
arquiteturais:

componentes, portas e conectores
CIn-UFPE
14
Visão Conceitual - Continuação

Componentes, portas e conectores são modelados
através do diagrama de classes de UML
(“stereotyped class”)

Interação entre componentes através de Diagrama
de Seqüência
CIn-UFPE
15
Visão Conceitual - Exemplo

O sistema de captura de imagem capta um conjunto de imagens
digitalizadas. O usuário controla a captura pela seleção de um
procedimento a partir de um conjunto de procedimentos prédefinidos. Então, inicia tal procedimento e provavelmente ajusta-o
durante a captura. O dado bruto para as imagens é capturado por um
dispositivo de hardware, uma “câmera”, sendo então enviado para o
processador de imagem (image pipeline) onde é convertido para
imagens. O image pipeline faz esta conversão, primeiro compondo o
dado bruto em imagens discretas, e então executa um ou mais
padrões de transformações de imagem para melhorar a resolução
das imagens resultantes.
CIn-UFPE
16
Visão Conceitual – O modelo informal
Componentes, Conectores e Portas ( Visão Tradicional )
ImagePipeline
PipelineMgr
acqControl
acqControl
pipeline
Control
client/server
client/server
Framer
Imager
stageControl
stageControl
framed
Out
imageOut
packetIn
packetIn
imageOut
imagePipe
imageIn
CIn-UFPE
17
Visão Conceitual - Diagrama de Classes UML
Modelo Preliminar
<<Componente>>
ImagePipeline
<<Componente>>
PipelineMgr
<<Conector>>
Client/Server
CIn-UFPE
<<Componente>>
Framer
<<Componente>>
Imager
<<Conector>>
imagePipe
18
Visão Conceitual - Diagrama de Classes UML
<<Componente>>
ImagePipeline
packetIn
framedOut
acqControl
acqControl
<<Componente>>
PipelineMgr
pipelineControl
<<Conector>>
Client/Server
sender
receiver
<<Conector>>
Client/Server
stageControl
packetIn
receiver
sender
<<Componente>>
Framer
imageOut
stageControl
source
CIn-UFPE
<<Conector>>
imagePipe
dest
imageIn
<<Componente>>
Imager
ImageOut
19
Visão Conceitual - Diagrama de Classes UML
<<Componente>>
ImagePipeline
<<Porta>>
packetIn
<<Porta>>
framedOut
<<Componente>>
PipelineMgr
<<Porta>>
acqControl
<<Porta>>
acqControl
<<Conector>>
Client/Server
<<Papel>>
receiver
<<Conector>>
Client/Server
<<Papel>>
sender
<<Papel>>
receiver
<<Papel>>
sender
<<Componente>>
Framer
<<Porta>>
packetIn
CIn-UFPE
<<Componente>>
Imager
<<Porta>>
stageControl
<<Porta>>
imageOut
<<Porta>>
pipelineControl
<<Conector>>
imagePipe
<<Papel>>
source
<<Porta>>
stageControl
<<Papel>>
dest
<<Porta>>
ImageOut
<<Porta>>
imageIn
20
Visão de Módulo

Subsistemas são decompostos em módulos os quais
são organizados em camadas

Stakeholders interessados: Analistas e
Programadores

Elementos: módulos, subsistemas e camadas

Elementos conceituais são mapeados em módulos
CIn-UFPE
21
Visão de Módulo

Componentes são “implementados” por módulos e
subsistemas

Portas, conectores e componentes podem ser
combinados em um único módulo

Dependências de uso entre módulos são derivadas
das associações entre os elementos conceituais
CIn-UFPE
22
Visão de Módulo

Módulos são representados por classes
estereotipadas

Subsistemas e camadas são representados por
pacotes estereotipados

Dependências de uso são representadas por
dependências UML
CIn-UFPE
23
Visão de Módulo
<<subsystem>>
SPipeline
<<module>>
<<module>>
<<module>>
MPipelineAPI
MPipelineControl
MFramer
<<module>>
<<module>>
<<module>>
MImageMgrAPI
MImageBUffer
MImager
Elemento Conceitual
Subsistema ou Módulo
ImagePipeline (cp)
SPipeline
acqControl(pt),pipelineControl(pt)
MpipelineAPI
pipelineMgr(cp), ImagePipe(cn),Client/Server (cn)
MpipelineControl, MImageBuffer
stageControl(pt), imageIn(pt), imageOut(pt)
MImageMgrAPI
Framer (cp)
MFramer
Imager(cp)
MImager
CIn-UFPE
24
Visão de Módulo - Dependências de Uso
<<layer>>
ApplicationService
<<module>>
MClient
<<module>>
MImager
<<module>>
MFramer
<<layer>>
ImageProcessing
interface
<<module>>
MPipelineAPI
<<module>>
MPipelineControl
CIn-UFPE
<<module>>
MImageMgrAPI
<<module>>
MImageBuffer
<<module>>
MDataMgrAPI
25
Visão de Execução

Visão do sistema em tempo de execução (TE)

Stakeholder interessado: Integradores do sistema

Define o mapeamento dos módulos em elementos de
TE (processos, threads, etc)

Define a comunicação entre os elementos de TE, e
os atribui a recursos físicos
CIn-UFPE
26
Visão de Execução

Elementos: cenário de tempo de execução e caminho
de execução

Conceitos principais: Uso de recursos e performance

Classes UML estereotipadas são usadas para
representar elementos de TE

Estereótipos de acordo com o nome do elementos da
plataforma: <<process>> <<shared data>>
CIn-UFPE
27
Visão de Execução
<< process >>
EpipelineMgr
<< process >>
Eclient
<< module >>
Mclient
<< module >>
MPipeLineAPI
<< module >>
MpipelineControl
<< process >>
EFramer
<< module >>
MDataMgrAPI
<< module >>
MFramer
CIn-UFPE
<< process >>
EImager
<< module >>
MImageMgrAPI
<< module >>
MImageMgrAPI
<< shared Data >>
EImageBUffer
<< module >>
MImager
<< module >>
MImageBuffer
28
Visão de Código

Contém arquivos e diretórios

Stakeholder interessado: Engenheiros de Sistema
(topologia, entrega, instalação, etc.)

Mapeamento dos módulos e interfaces da visão de
módulo em arquivos fonte

Elementos de TE da visão de execução são
mapeados em arquivos executáveis
CIn-UFPE
29
Visão de Código

Elementos: código fonte, código intermediário,
código executável, diretório

Arquivos são representados por componentes UML
estereotipados

Diretórios são representados por pacotes UML
estereotipados
CIn-UFPE
30
Visão de Código
Dependência entre arquivos fonte
<<directory>>
PipelineControl
<<Source>>
CPipelineControl.CPP
<<Source>>
CPipelineControlPvt.H
<<Source>>
CPipelineControl.H
<<Source>>
CstageControl.H
<<directory>>
PipelineAPI
<<Source>>
CPipelineAPI.CPP
<<Source>>
CPipeline.H
CIn-UFPE
<<Source>>
CPipelinePvt.H
<<directory>>
ImageMgrAPI
<<Source>>
CImageMgrAPI.CPP
<<Source>>
CImageMgr.H
<<Source>>
CImageMgrPvt.H
31
Múltiplas Visões: Relação entre as visões
elementos arquiteturais
conceitual
código
arquivos
CIn-UFPE
módulos
módulos
execução
elementos de execução (processos)
32
Conclusão



Arquitetura de Software promove o reuso em alta
escala
A UML pode ser usada como uma “ADL” (apresenta
algumas deficiências). Existem propostas para sua
extensão.
A grande motivação do uso da UML é que ela é um
padrão largamente aceito e difundido
CIn-UFPE
33