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.

Apresentação em tema: "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."— Transcrição da apresentação:

1 CIn-UFPE1 Modelagem de Arquitetura com UML

2 CIn-UFPE2 Arquitetura de software n “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]

3 CIn-UFPE3 Arquitetura de software n Modelo de Shaw, 1996  componentes  conectores  configuração

4 CIn-UFPE4 Arquitetura de software n Componente  modela a computação e/ou armazenamento de informações  desenvolvido independentemente  exemplos de componentes ècliente èservidor èbanco de dados èaplicação inteira

5 CIn-UFPE5 Arquitetura de software n Conector  modela as interações entre os componentes  desenvolvido independentemente  exemplos de conectores èprotocolos de comunicação èMiddleware (ex: CORBA, RMI)

6 CIn-UFPE6 Arquitetura de software n Configuração  topologia  conjunto de componentes combinados usando-se os conectores  grafo de componentes e conectores ligados, descrevendo uma estrutura arquitetural

7 CIn-UFPE7 Arquitetura de software n 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.

8 CIn-UFPE8 Uso de UML como uma “ADL” (Architecture Description Language) n Mesmo havendo uma “perda” em capturar todos os aspectos de uma arquitetura, o uso de UML tem sido crescente n 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

9 CIn-UFPE9 Múltiplas Visões n Vários stakeholders têm diferentes conceitos e interesses em aspectos distintos da arquitetura. n Assim como na construção civil, diferentes tipos de “plantas” são usadas para representar diferentes aspectos da arquitetura.

10 CIn-UFPE10 Múltiplas Visões n 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.

11 CIn-UFPE11 Múltiplas Visões n 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.

12 CIn-UFPE12 Arquitetura de software O modelo de “4+1 Visões” Visão de Implementação Visão Lógica Visão de Distribuição Visão de Processos Visão de Casos de Uso Analista de Sistemas Arquiteto Estrutura Programadores Arquiteto Escalabilidade Topologia, implantação, comunicação Arquiteto Estrutura, componentes

13 CIn-UFPE13 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

14 CIn-UFPE14 Visão Conceitual n Captura aspectos funcionais do sistema n Stakeholder interessado: Usuário final n Descrição da arquitetura em termos de elementos arquiteturais:  componentes, portas e conectores

15 CIn-UFPE15 Visão Conceitual - Continuação n Componentes, portas e conectores são modelados através do diagrama de classes de UML (“stereotyped class”) n Interação entre componentes através de Diagrama de Seqüência

16 CIn-UFPE16 Visão Conceitual - Exemplo n 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.

17 CIn-UFPE17 Visão Conceitual – O modelo informal stageControl Framer acqControl packet I n imageOut stageControl Imager imageIn imageOut pipeline Control PipelineMgr acqControl framed Out client/server imagePipe Componentes, Conectores e Portas ( Visão Tradicional ) client/server ImagePipeline

18 CIn-UFPE18 Visão Conceitual - Diagrama de Classes UML > PipelineMgr > Imager > ImagePipeline > imagePipe > Framer > Client/Server Modelo Preliminar

19 CIn-UFPE19 Visão Conceitual - Diagrama de Classes UML > ImagePipeline framedOut packetInacqControl sender > Client/Server receiver packetIn > Framer stageControl imageOut source dest > imagePipe > PipelineMgr acqControl pipelineControl receiver > Client/Server sender > Imager stageControl ImageOut imageIn

20 CIn-UFPE20 Visão Conceitual - Diagrama de Classes UML > Imager > stageControl > ImageOut > imageIn > PipelineMgr > acqControl > pipelineControl > ImagePipeline > imagePipe > source > dest > framedOut > packetIn > acqControl > Client/Server > sender > receiver > Client/Server > receiver > sender > Framer > packetIn > stageControl > imageOut

21 CIn-UFPE21 Visão de Módulo n Subsistemas são decompostos em módulos os quais são organizados em camadas n Stakeholders interessados: Analistas e Programadores n Elementos: módulos, subsistemas e camadas n Elementos conceituais são mapeados em módulos

22 CIn-UFPE22 Visão de Módulo n Componentes são “implementados” por módulos e subsistemas n Portas, conectores e componentes podem ser combinados em um único módulo n Dependências de uso entre módulos são derivadas das associações entre os elementos conceituais

23 CIn-UFPE23 Visão de Módulo n Módulos são representados por classes estereotipadas n Subsistemas e camadas são representados por pacotes estereotipados n Dependências de uso são representadas por dependências UML

24 CIn-UFPE24 Visão de Módulo > MPipelineAPI > MPipelineControl > MFramer > MImageMgrAPI > MImageBUffer > MImager > SPipeline 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

25 CIn-UFPE25 Visão de Módulo - Visão de Módulo - Dependências de Uso > MPipelineAPI > MPipelineControl > MFramer > MImageMgrAPI > MImageBuffer > MImager > MClient > ApplicationService > MDataMgrAPI > ImageProcessing interface

26 CIn-UFPE26 Visão de Execução n Visão do sistema em tempo de execução (TE) n Stakeholder interessado: Integradores do sistema n Define o mapeamento dos módulos em elementos de TE (processos, threads, etc) n Define a comunicação entre os elementos de TE, e os atribui a recursos físicos

27 CIn-UFPE27 Visão de Execução n Elementos: cenário de tempo de execução e caminho de execução n Conceitos principais: Uso de recursos e performance n Classes UML estereotipadas são usadas para representar elementos de TE n Estereótipos de acordo com o nome do elementos da plataforma: > >

28 CIn-UFPE28 Visão de Execução > Mclient > Eclient > MPipeLineAPI > MpipelineControl > EpipelineMgr > MImageMgrAPI > EFramer > MDataMgrAPI > MImageMgrAPI > EImager > MImager > MImageBuffer > EImageBUffer > MFramer

29 CIn-UFPE29 Visão de Código n Contém arquivos e diretórios n Stakeholder interessado: Engenheiros de Sistema (topologia, entrega, instalação, etc.) n Mapeamento dos módulos e interfaces da visão de módulo em arquivos fonte n Elementos de TE da visão de execução são mapeados em arquivos executáveis

30 CIn-UFPE30 Visão de Código n Elementos: código fonte, código intermediário, código executável, diretório n Arquivos são representados por componentes UML estereotipados n Diretórios são representados por pacotes UML estereotipados

31 CIn-UFPE31 Visão de Código Dependência entre arquivos fonte > CPipelineControl.CPP > CPipelineControl.H > CPipelineControlPvt.H > CstageControl.H > PipelineControl > CPipelineAPI.CPP > CPipeline.H > CPipelinePvt.H > PipelineAPI > CImageMgrAPI.CPP > CImageMgr.H > CImageMgrPvt.H > ImageMgrAPI

32 CIn-UFPE32 Múltiplas Visões: Relação entre as visões conceitual módulos execução código elementos arquiteturais módulos arquivoselementos de execução (processos)

33 CIn-UFPE33 Conclusão n Arquitetura de Software promove o reuso em alta escala n A UML pode ser usada como uma “ADL” (apresenta algumas deficiências). Existem propostas para sua extensão. n A grande motivação do uso da UML é que ela é um padrão largamente aceito e difundido