cin-ufpe1 modelagem de arquitetura com uml. cin-ufpe2 arquitetura de software n “uma arquitetura...
TRANSCRIPT
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
Arquitetura de Arquitetura de softwaresoftware
Modelo de Shaw, 1996 componentes conectores configuração
CIn-UFPECIn-UFPE 44
Arquitetura de Arquitetura de softwaresoftware
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
Arquitetura de Arquitetura de softwaresoftware
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
Arquitetura de Arquitetura de softwaresoftware
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
Arquitetura de Arquitetura de softwaresoftware
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
Múltiplas VisõesMú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-UFPECIn-UFPE 1111
Múltiplas VisõesMú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-UFPECIn-UFPE 1212
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
CIn-UFPECIn-UFPE 1313
Múltiplas VisõesMú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-UFPECIn-UFPE 1414
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
CIn-UFPECIn-UFPE 1515
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
CIn-UFPECIn-UFPE 1616
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.
CIn-UFPECIn-UFPE 1717
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
CIn-UFPECIn-UFPE 1818
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
CIn-UFPECIn-UFPE 1919
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
<<Componente>>PipelineMgr
acqControl
pipelineControl
receiver<<Conector>>Client/Server
sender
<<Componente>>Imager
stageControl
ImageOutimageIn
CIn-UFPECIn-UFPE 2020
Visão Conceitual - Diagrama de Classes UML Visão Conceitual - Diagrama de Classes UML
<<Componente>>Imager
<<Porta>>stageControl
<<Porta>>ImageOut
<<Porta>>imageIn
<<Componente>>PipelineMgr
<<Porta>>acqControl
<<Porta>>pipelineControl
<<Componente>>ImagePipeline
<<Conector>>imagePipe
<<Papel>>source
<<Papel>>dest
<<Porta>>framedOut
<<Porta>>packetIn <<Porta>>
acqControl
<<Conector>>Client/Server
<<Papel>>sender
<<Papel>>receiver
<<Conector>>Client/Server
<<Papel>>receiver
<<Papel>>sender
<<Componente>>Framer
<<Porta>>packetIn
<<Porta>>stageControl
<<Porta>>imageOut
CIn-UFPECIn-UFPE 2121
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
CIn-UFPECIn-UFPE 2222
Visão de MóduloVisã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-UFPECIn-UFPE 2323
Visão de MóduloVisã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-UFPECIn-UFPE 2424
Visão de MóduloVisão de Módulo
<<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
CIn-UFPECIn-UFPE 2525
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
CIn-UFPECIn-UFPE 2626
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
CIn-UFPECIn-UFPE 2727
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>>
CIn-UFPECIn-UFPE 2828
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
CIn-UFPECIn-UFPE 2929
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
CIn-UFPECIn-UFPE 3030
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
CIn-UFPECIn-UFPE 3131
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
CIn-UFPECIn-UFPE 3232
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)
CIn-UFPECIn-UFPE 3333
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