CIn-UFPE1 Modelagem de Arquitetura com UML. CIn-UFPE2 Arquitetura de software n “Uma arquitetura de software deve conter: a definição dos elementos de

CIn-UFPECIn-UFPE 11

Modelagem de Arquitetura com UMLModelagem de Arquitetura com UML

CIn-UFPECIn-UFPE 22

Arquitetura de Arquitetura de softwaresoftware

“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-UFPECIn-UFPE 33


Modelo de Shaw, 1996 componentes conectores configuração

CIn-UFPECIn-UFPE 44


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-UFPECIn-UFPE 55


Conector modela as interações entre os componentes

desenvolvido independentemente

exemplos de conectores

protocolos de comunicação

Middleware (ex: CORBA, RMI)

CIn-UFPECIn-UFPE 66


Configuração topologia conjunto de componentes combinados usando-se os

conectores grafo de componentes e conectores ligados, descrevendo

uma estrutura arquitetural

CIn-UFPECIn-UFPE 77


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-UFPECIn-UFPE 88

Uso de UML como uma Uso de UML como uma “ADL” (Architecture Description Language)“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-UFPECIn-UFPE 99

Múltiplas VisõesMú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-UFPECIn-UFPE 1010


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.



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.


Arquitetura de softwareArquitetura de softwareO modelo de “4+1 Visões”O modelo de “4+1 Visões”

Visão de Implementação

VisãoLógica

Visão de Distribuição

Visão de Processos

Visão de Casos de Uso

Analista de Sistemas

Arquiteto

EstruturaProgramadores

Arquiteto Escalabilidade Topologia, implantação, comunicação

Arquiteto

Estrutura, componentes



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


Visão ConceitualVisã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


Visão Conceitual - ContinuaçãoVisã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


Visão Conceitual - ExemploVisã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.


Visão Conceitual – O modelo informalVisão Conceitual – O modelo informal

stageControlFramer

acqControl

packetInpacketIn

imageOut

stageControlImager

imageIn

imageOut

pipelineControl

PipelineMgr

acqControl

framedOut

client/server

imagePipe

Componentes, Conectores e Portas ( Visão Tradicional )

client/server

ImagePipeline


Visão Conceitual - Diagrama de Classes UML Visão Conceitual - Diagrama de Classes UML

<<Componente>>PipelineMgr

<<Componente>>Imager

<<Componente>>ImagePipeline

<<Conector>>imagePipe

<<Componente>>Framer

<<Conector>>Client/Server

Modelo Preliminar


Visão Conceitual - Diagrama de Classes UML Visão Conceitual - Diagrama de Classes UML <<Componente>>ImagePipeline

framedOut

packetIn acqControl

sender<<Conector>>Client/Server

receiver

packetIn <<Componente>>Framer

stageControl

imageOut

source dest<<Conector>>imagePipe


acqControl

pipelineControl

receiver<<Conector>>Client/Server

sender


stageControl

ImageOutimageIn


Visão Conceitual - Diagrama de Classes UML Visão Conceitual - Diagrama de Classes UML


<<Porta>>stageControl

<<Porta>>ImageOut

<<Porta>>imageIn


<<Porta>>acqControl

<<Porta>>pipelineControl

<<Componente>>ImagePipeline

<<Conector>>imagePipe

<<Papel>>source

<<Papel>>dest

<<Porta>>framedOut

<<Porta>>packetIn <<Porta>>

acqControl


<<Papel>>sender

<<Papel>>receiver


<<Papel>>receiver

<<Papel>>sender

<<Componente>>Framer

<<Porta>>packetIn

<<Porta>>stageControl

<<Porta>>imageOut


Visão de MóduloVisã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



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



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



<<module>>MPipelineAPI

<<module>>MPipelineControl

<<module>>MFramer

<<module>>MImageMgrAPI

<<module>>MImageBUffer

<<module>>MImager

<<subsystem>>SPipeline

Elemento ConceitualImagePipeline (cp)acqControl(pt),pipelineControl(pt)pipelineMgr(cp), ImagePipe(cn),Client/Server (cn)stageControl(pt), imageIn(pt), imageOut(pt)Framer (cp)Imager(cp)

Subsistema ou MóduloSPipelineMpipelineAPIMpipelineControl, MImageBufferMImageMgrAPIMFramerMImager


Visão de Módulo - Visão de Módulo - Dependências de Uso

<<module>>MPipelineAPI

<<module>>MPipelineControl

<<module>>MFramer

<<module>>MImageMgrAPI

<<module>>MImageBuffer

<<module>>MImager

<<module>>MClient

<<layer>>ApplicationService

<<module>>MDataMgrAPI

<<layer>>ImageProcessing

interface


Visão de ExecuçãoVisã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


Visão de ExecuçãoVisã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>>


Visão de ExecuçãoVisão de Execução

<< module >>Mclient

<< process >>Eclient

<< module >>MPipeLineAPI

<< module >>MpipelineControl

<< process >>EpipelineMgr

<< module >>MImageMgrAPI

<< process >>EFramer

<< module >>MDataMgrAPI

<< module >>MImageMgrAPI

<< process >>EImager

<< module >>MImager

<< module >>MImageBuffer

<< shared Data >>EImageBUffer

<< module >>MFramer


Visão de CódigoVisã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


Visão de CódigoVisã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


Visão de CódigoVisão de CódigoDependência entre arquivos fonte

<<Source>>CPipelineControl.CPP

<<Source>> CPipelineControl.H

<<Source>>CPipelineControlPvt.H

<<Source>>CstageControl.H

<<directory>>PipelineControl

<<Source>>CPipelineAPI.CPP

<<Source>>CPipeline.H

<<Source>>CPipelinePvt.H

<<directory>>PipelineAPI <<Source>>

CImageMgrAPI.CPP

<<Source>>CImageMgr.H

<<Source>>CImageMgrPvt.H

<<directory>>ImageMgrAPI


Múltiplas Visões: Relação entre as visõesMúltiplas Visões: Relação entre as visões

conceitual módulos

execuçãocódigo

elementos arquiteturais módulos

arquivos elementos de execução (processos)


ConclusãoConclusã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

Documents

CIn-UFPE1 Modelagem de Arquitetura com UML. CIn-UFPE2 Arquitetura de software n “Uma arquitetura de software deve conter: a definição dos elementos de