Modelagem de Arquitetura com UML

Tamanho: px

Começar a partir da página:

Download "Modelagem de Arquitetura com UML"

Baltazar de Miranda Affonso
8 Há anos
Visualizações:

1 Modelagem de Arquitetura com UML 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] 2 1

software; a descrição das interações entre estes elementos; os padrões de

2 Arquitetura de software Modelo de Shaw, 1996 componentes conectores configuração 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 4 2

e/ou armazenamento de informações desenvolvido independentemente

3 Arquitetura de software Conector modela as interações entre os componentes desenvolvido independentemente exemplos de conectores protocolos de comunicação Middleware (ex: CORBA, RMI) 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 6 3

RMI) 5 Arquitetura de software Configuração topologia conjunto de componentes combinados

4 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. 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 8 4

7 Uso de UML como uma ADL (Architecture Description Language) Mesmo havendo uma perda em capturar todos os aspectos de uma arquitetura, o uso

5 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. 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. 10 5

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

6 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. 11 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 12 6

Exemplo de abordagens: Kructhen - O Modelo 4 + 1: Lógica, Processo, Física, Implantação e Casos

7 Múltiplas Visões: Relação entre as visões elementos arquiteturais conceitual módulos módulos código execução arquivos elementos de execução (processos) 13 Visão Conceitual Captura aspectos funcionais do sistema Stakeholder interessado: Usuário final Descrição da arquitetura em termos de elementos arquiteturais Elementos: componentes, portas e conectores 14 7

Captura aspectos funcionais do sistema Stakeholder interessado: Usuário final Descrição

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

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.

9 Visão Conceitual modelo informal Componentes, Conectores e Portas ( Visão Tradicional ) acqcontrol PipelineMgr ImagePipeline client/server acqcontrol pipeline Control client/server Framer stagecontrol Imager stagecontrol packetin packetin imageout imagepipe imagein imageout framed Out 17 Visão Conceitual - Diagrama de Classes UML Modelo Preliminar ImagePipeline PipelineMgr Framer Imager <<Conector>> Client/Server <<Conector>> imagepipe 18 9

packetin packetin imageout imagepipe imagein imageout framed Out 17 Visão Conceitual - Diagrama de Classes UML

10 Visão Conceitual - Diagrama de Classes UML packetin ImagePipeline acqcontrol framedout acqcontrol PipelineMgr pipelinecontrol <<Conector>> Client/Server sender receiver <<Conector>> Client/Server receiver packetin stagecontrol Framer sender imageout source <<Conector>> imagepipe dest imagein stagecontrol Imager ImageOut 19 Visão Conceitual - Diagrama de Classes UML packetin <<Papel>> receiver <<Componente> > ImagePipeline acqcontrol <<Conector>> Client/Server <<Componente> > Framer <<Papel>> sender framedout <<Papel>> sender acqcontrol <<Conector>> Client/Server <<Papel>> receiver PipelineMgr pipelinecontrol <<Componente >> Imager packetin imageout stagecontrol <<Papel>> <<Conector>> imagepipe <<Papel>> stagecontrol imagein ImageOut source dest 20 10

packetin <<Papel>> receiver <<Componente> > ImagePipeline acqcontrol <<Conector>> Client/Server <<Componente> > Framer <<Papel>> sender framedout <<Papel>> sender acqcontrol <<Conector>>

11 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 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 22 11

Visão de Módulo Componentes são implementados por módulos e subsistemas Portas, conectores e componentes podem ser

12 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 23 Visão de Módulo <<subsystem>> SPipeline MPipelineAPI MPipelineControl MFramer MImageMgrAPI MImageBUffer MImager Elemento Conceitual ImagePipeline (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ódulo SPipeline MpipelineAPI MpipelineControl, MImageBuffer MImageMgrAPI MFramer MImager 24 12

MImager Elemento Conceitual ImagePipeline (cp) acqcontrol(pt),pipelinecontrol(pt) pipelinemgr(cp), ImagePipe(cn),Client/Server (cn) stagecontrol(pt),

13 Visão de Módulo - Dependências de Uso MClient <<layer>> ApplicationService MImager MFramer <<layer>> ImageProcessing interface MPipelineAPI MImageMgrAPI MPipelineControl MImageBuffer 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 26 13

em tempo de execução (TE) Stakeholder interessado: Integradores do sistema Define o mapeamento dos módulos em

14 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>> 27 Visão de Execução Mclient << process >> Eclient << process >> EpipelineMgr MpipelineControl << process >> EImager MPipeLineAPI MDataMgrAPI MFramer << process >> EFramer MImageMgrAPI << shared Data >> EImageBUffer MImageBuffer MImageMgrAPI MImager 28 14

<<process>> <<shared data>> 27 Visão de Execução Mclient << process >> Eclient << process >> EpipelineMgr MpipelineControl << process >>

15 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 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 30 15

execução são mapeados em arquivos executáveis 29 Visão de Código Elementos: código fonte, código intermediário, código

16 Visão de Código Dependência entre arquivos fonte CPipelineControl.CPP <<directory>> PipelineControl CPipelineControlPvt.H CPipelineControl.H CstageControl.H <<directory>> <<directory>> CPipelineAPI.CPP PipelineAPI CImageMgrAPI.CPP ImageMgrAPI CPipeline.H CImageMgr.H CPipelinePvt.H CImageMgrPvt.H 31 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 32 16

Documentos relacionados

Arquitetura de Software

Arquitetura de Software Agenda de Software - Fundamentos e Tendências - Objetivos e Contexto de Software (A.S.) A.S. no Processo de Desenvolvimento Passado, Presente e Futuro Prof. Marco Fagundes mfagunde@tre-pa.gov.br 1 2 Objetivos