Modelagem Arquitetural e a Visão 4+1

Apresentação em tema: "Modelagem Arquitetural e a Visão 4+1"— Transcrição da apresentação:

1 Modelagem Arquitetural e a Visão 4+1
Adriano de Pinho Tavares Janeiro 2009 – Circuito IGTI de Palestras Corporativas 1

2 Modelagem Arquitetural Sobre o palestrante
Adriano no corpo de professores do IGTI professores&task=view&Itemid=17&professor=23 Adriano Tavares em PANGEA

3 Modelagem Arquitetural e a Visão 4+1
3

4 Introdução à Modelagem Arquitetural Modelos são Simplificações
Um modelo é uma simplificação da realidade. Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade. Isso se deve aos limites da capacidade humana de compreender complexidades. Com a ajuda da modelagem, delimitamos o problema que estamos estudando, restringindo nosso foco a um único aspecto por vez. Em essência esse é o procedimento de “dividir-para-conquistar”, do qual Edsger Dijkstra comentava desde os anos 60. “Ataque um problema difícil, dividindo-o em vários problemas menores que você pode solucionar. “ Com o auxílio da modelagem somos capazes de ampliar o intelecto humano. Um modelo escolhido de maneira adequada permitirá a quem usa a modelagem trabalhar em níveis mais altos de abstração. Em resumo, modelos são usados para simplificar os problemas de engenharia de software 4

5 Introdução à Modelagem Arquitetural Modelagem – Para quê
Objetivos da modelagem: Compreensão de sistemas complexos. Explorar e comparar as alternativas de desenho a um baixo custo. Formar a fundação para implementação. Capturar requisitos com precisão. Comunicar decisões sem ambigüidade. Ajudar na Compreensão de Sistemas Complexos A importância dos modelos aumenta à medida que os sistemas se tornam mais complexos. Por exemplo, uma casinha de cachorro pode ser construída sem um projeto. No entanto, à medida que evoluímos para casas e, depois, para arranha-céus, a necessidade de um projeto torna-se evidente. Explorar e Comparar as Alternativas de Design a um Baixo Custo Modelos simples podem ser criados e modificados a um baixo custo para explorar alternativas de design. Idéias inovadoras podem ser capturadas e revisadas por outros desenvolvedores antes de investir em um desenvolvimento de código caro. Quando ligada ao desenvolvimento iterativo, a modelagem visual ajuda os desenvolvedores a avaliar mudanças de design e a comunicar essas mudanças a toda a equipe de desenvolvimento. Formar uma Fundação para Implementação Atualmente, muitos projetos empregam linguagens de programação orientadas a objetos para obter sistemas reutilizáveis, tolerantes a mudanças e estáveis. Para obter essas vantagens, é ainda mais importante usar tecnologia de objetos em design. O RUP (Rational Unified Process) produz um modelo de design orientado a objetos que é a base para a implementação. Capturar Requisitos com Precisão Antes de construir um sistema, é essencial capturar os requisitos. A especificação dos requisitos utilizando um modelo preciso e não ambíguo ajuda a assegurar que todos os investidores entendam e concordem com os requisitos. Um modelo que separa o comportamento externo do sistema da implementação o ajuda a se concentrar no uso pretendido do sistema, sem ficar perdido nos detalhes de implementação. 5

6 Introdução à Modelagem Arquitetural Modelagem – Vantagens
Vantagens da Modelagem: Prover a estrutura para a solução de problemas. Experimentação de múltiplas soluções. Produzir abstrações para tratar complexidade. Reduzir o tempo do projeto. Diminuir custos de desenvolvimento. Controlar riscos de erros. Todo sistema complexo é melhor alcançado através de diferentes visões de um modelo. Uma visão única não é suficiente. Todo modelo pode ser expresso em diferentes níveis de fidelidade. Todo sistema complexo é melhor alcançado através de diferentes visões de um modelo. Uma visão única não é suficiente. Todo modelo pode ser expresso em diferentes níveis de fidelidade. A linguagem UML define vários diagramas gráficos para representação de modelos. 6

7 Introdução à Modelagem Arquitetural Modelagem – Princípios
Os quatro princípios da modelagem: Escolha o modelo mais adequado Use níveis diferentes de precisão. Procure conectar o modelo à realidade. Nenhum modelo único é suficiente. 1. A escolha dos modelos a serem criados possuem um enorme impacto em como o problema é atacado e como a solução é definida. 2. Cada modelo poderá ser expresso em diferentes níveis de precisão. 3. Os melhores modelos são conectados à realidade. 4. Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes de vários pontos de vista. 7

8 Introdução à Modelagem Arquitetural Modelagem e a UML
Combina conceitos de várias metodologias Abrangente – Modelagem de negócios, Requisitos, Análise, Desenho, Implementação, Testes, Implantação. Aplicável a qualquer domínio. Independente de linguagem, plataforma ou processo. Suportada por várias ferramentas. A OMG adotou a UML em Novembro de 1997 como padrão para modelagem de sistemas. ( A UML é um passo importante em direção à padronização de desenvolvimento de software. O padrão UML recebeu apoio da mesma maneira entre vendedores de ferramentas e desenvolvedores de diversas empresas em todo o mundo. Formalmente, a especificação UML descreve um metamodelo que define os elementos de cada diagrama, como os diagramas podem ser montados, e como podem ser estendidos. O padrão de UML não prescreve um processo para aplicar a notação de diagrama nem define o uso apropriado da notação para se criar "bons" produtos, ou guias para evitar produtos ruins. O padrão não dita como um vendedor implementa o padrão. A arquitetura de metamodelo de UML define quatro camadas: o objeto de usuário, modelo, meta-modelo (2M), e meta-meta-modelo (3M) camadas. As extensões de UML incluem estereótipos, comentários, restrições, valores de tagged, e perfis (profiles). A versão atual da UML é 2.1. (Abril de 2008) 8

9 Introdução à Modelagem Arquitetural UML 2 - Objetivos
Linguagem consistente para: Visualização. Especificação. Construção. Documentação. A linguagem UML foi pensada com os quatros objetivos básicos, descritos abaixo: - Visualização: Modelos gráficos com semântica precisa. - Especificação: Modelos precisos, não ambíguos e completos, que capturam todas as decisões importantes de Análise, Desenho e Implementação. - Construção: Modelos podem ser diretamente associados a linguagens de programação (engenharia direta e reversa). - Documentação: Diagramas capturam todas as informações coletadas pela equipe, permitindo o compartilhamento deste conhecimento. 9

10 Introdução à Modelagem Arquitetural UML 2 - Objetivos
Todos os objetivos abaixo são encorajados através da UML 2. Comunicação facilitada. Mecanismos de estensibilidade. Especificação independente de linguagem. Base formal. Crescimento do mercado de objetos. Desenvolvimento de conceitos de alto nível como colaborações e padrões. Espalhamento de boas práticas. 10

11 Introdução à Modelagem Arquitetural UML – Principais Diagramas
11

12 Introdução à Modelagem Arquitetural UML – Principais Elementos
Semântica dos modelos (UML2 e MOF). Linguagem de interoperabilidade chamada XMI. Linguagem de queries chamada OCL. Linguagem de transformações chamada QVT. MOF: Meta Object Facility. Linguagem abstrata e um framework para construir, especificar e gerenciar meta-modelos independentes de tecnologia. A UML, por exemplo, é construída a partir do MOF. MOF também é construído a partir de primitivas MOF. XMI: XML Metadata Interchange. XMI é um dialeto XML para troca de modelos (ex: UML). Padrão de interoperação de modelos. Por exemplo, modelos UML podem ser trocados através de ferramentas CASE que suportem o padrão XMI Exemplo de uso: Comunicar modelos feitos no Borland Together/J para o IBM Rational Software Modeler. OCL – Object Constraint Language. Linguagem para suporte a pesquisas em modelos e para a colocação de restrições em modelos Exemplo de uso: Descobrir padrões de projeto ou anti-padrões de projeto em uma aplicação. QVT – Query / Views / Transformation Especificação MOF para pesquisas, visões e transformações usada em métodos como o MDD (Model Driven Development). Exemplo de uso: Gerar código Java a partir de modelos UML e vice-versa. Todas estas especificações podem ser buscadas a partir do site 12

13 Introdução à Modelagem Arquitetural Arquiteturas de Softwares
A arquitetura de um sistema de software é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos constituídos de componentes e interfaces sucessivamente menores. A arquitetura de software é um conceito de fácil compreensão e que a maioria dos engenheiros entende de modo intuitivo, especialmente quando se tem um pouco de experiência. No entanto, é difícil defini-lo com precisão. Em particular, é difícil desenhar uma linha bem definida entre o design e a arquitetura - a arquitetura é um aspecto do design que se concentra em alguns recursos específicos. Em An Introduction to Software Architecture, David Garlan e Mary Shaw sugerem que a arquitetura de software é um nível de design voltado para problemas: "Além dos algoritmos e das estruturas de dados da computação; o design e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global; protocolos de comunicação, sincronização e acesso a dados; designação de funcionalidade a elementos de design; distribuição física; composição de elementos de design; escalação e desempenho; e seleção entre as alternativas de design." [GAR93] Mas há mais a arquiteturar do que apenas a estruturar; o artigo Working Group on Architecture da IEEE define isso como "o conceito de nível mais alto de um sistema em seu ambiente" [IEP1471]. Também abrange o "ajuste" à integridade do sistema, às restrições econômicas, às preocupações estéticas e ao estilo. Ele não se limita a um enfoque interno, mas leva em consideração o sistema como um todo em seu ambiente de usuário e de desenvolvimento, ou seja, um enfoque externo. 13

14 Introdução à Modelagem Arquitetural Conceitos errados
Arquitetura é apenas papel Arquitetura e desenho são a mesma coisa Arquitetura e infra-estrutura são a mesma coisa <minha tecnologia favorita> e a arquitetura Uma boa arquitetura é o trabalho de um único arquiteto Arquitetura é simplesmente estrutura Arquitetura pode ser representada em um único diagrama Arquitetura de sistemas (hardware) precede a arquitetura de software Arquitetura não pode ser medida ou validada Arquitetura é uma ciência Arquitetura é uma arte Conceitos errôneos sobre arquiteturas de software: Arquitetura é apenas papel. Arquitetura e desenho são a mesma coisa. Arquitetura e infra-estrutura são a mesma coisa. <minha tecnologia favorita> é a arquitetura. Uma boa arquitetura é o trabalho de um único arquiteto. Arquitetura é simplesmente estrutura. Arquitetura pode ser representada em um único diagrama. Arquitetura de sistemas (hardware) precede a arquitetura de software. Arquitetura não pode ser medida ou validada. Arquitetura é uma ciência. Arquitetura é uma arte. 14

15 Introdução à Modelagem Arquitetural Modelagem Arquitetural
Tipos de Projeto de sistemas de software Dirigidos por Calendário. Atendimento urgente a uma norma regulatória. Dirigidos por Qualidade. Sistemas que lidam com vidas humanas. Dirigidos por Requisitos. Sistemas com foco apenas na visão do usuário. Dirigidos por Documentação. Necessidades fortíssimas de sub-contratação e/ou gestão da informação. Dirigidos por Arquiteturas. Equilíbrio de fatores. Projetos dirigidos por arquitetura são mais adequados para a maioria dos projetos de software. Projetos dirigido a arquiteturas 1. Especificam o comportamento desejado do sistema através de um conjunto de cenários 2. Criam, e então validam um arquitetura que explora os padrões comuns nos cenários 3. Evoluem a arquitetura, fazendo correções a medida que o projeto se desenvolve, de forma a se adaptar aos novos requisitos assim que os mesmos são descobertos Estas atividades normalmente devem ocorrer nos primeiros 3/10 do tempo de um projeto, durante as fases de concepção e elaboração. 15

16 Introdução à Modelagem Arquitetural Visão 4+1
A visão 4+1 para desenho técnico de sistemas. Baseado nos princípios de: Modelo. Visão. Preocupação. Envolvidos. Um modelo é uma simplificação (abstração) da realidade, que permite entender melhor o sistema que será criado; Uma visão é uma representação do sistema, como um todo, da perspectiva de um conjunto de interesses relacionados; Uma preocupação pode se referir ao desenvolvimento do sistema, sua operação ou qualquer outro aspecto, que seja crítico ou de alguma forma importante para um ou mais envolvidos; Um envolvido é um indivíduo, equipe, ou organização com interesses em conceitos relativos ao sistema. Uma arquitetura tem na maioria das vezes muitos envolvidos diferentes. Exemplos incluem: Usuário final, cliente, administrador de sistema, gerente de projetos, analista de suporte, desenvolvedor, arquiteto,testador, outros sistemas. Para isso, precisamos capturar múltiplas realidades, múltiplas visões e múltiplos modelos de desenho técnico existentes. 16

17 Introdução à Modelagem Arquitetural Visão 4+1
Visão Lógica Funcionalidade Usuários finais Visão de implementação Desenvolvedores Gerência de configuração ◄lógico físico► Visão de casos de uso Visão de processos Desempenho Escalabilidade Vasão (Throughput) Integradores de sistemas Visão de implantação Topologia do sistema Comunicação Provisionamento Analistas de suporte 17

18 Introdução à Modelagem Arquitetural Visão de Casos de Uso
As visualizações de arquitetura podem ser vistas como abstrações ou simplificações dos modelos construídos, nas quais você torna mais visíveis as características importantes, deixando os detalhes de lado. A visualização de casos de uso mostra um subconjunto do modelo de casos de uso, um subconjunto de casos de uso e atores significativos para a arquitetura. Para fornecer uma base para o planejamento do conteúdo técnico de iterações, uma visualização arquitetural chamada visualização de caso de uso é utilizada na seguinte disciplina: Requisitos  . Só existe uma visualização de casos de uso do sistema, que ilustra os casos de uso e os cenários que englobam o comportamento, as classes ou os riscos técnicos significativos do ponto de vista da arquitetura. A visualização de casos de uso é aperfeiçoada e considerada inicialmente em cada iteração. 18

19 Introdução à Modelagem Arquitetural Visão Lógica
A visão lógica mostra um subconjunto do modelo de design significativo em termos de arquitetura, ou seja, um subconjunto das classes, subsistemas, pacotes e realizações de caso de uso. Para fornecer uma base para compreender a estrutura e a organização do design do sistema, uma visualização arquitetural denominada Visualização Lógica é utilizada no fluxo de trabalho Análise e Design. Existe somente uma visão lógica do sistema, que ilustra as principais realizações de caso de uso, subsistemas, pacotes e classes que abrangem o comportamento significativo em termos de arquitetura. A visão lógica é refinada durante cada iteração. 19

20 Introdução à Modelagem Arquitetural Visão de Implementação
Usada para capturar os sub-sistemas em um modelo de implementação, normalmente representada como um diagrama de componentes. Expressa a gestão da configuração. Agenda.INI Agenda.HLP A finalidade da visão de implementação é captar as decisões de arquitetura tomadas para a implementação. Normalmente, a visão de implementação contém: uma enumeração de todos os subsistemas no modelo de implementação. diagramas de componentes que ilustram como os subsistemas são organizados em camadas e hierarquias. ilustrações de dependências de importação entre subsistemas. A visualização de implementação é útil para o seguinte: . atribuir o trabalho de implementação a indivíduos e equipes ou a subcontratantes. . avaliar a quantidade de código que será desenvolvida, modificada ou excluída. . discutir a reutilização em larga escala. . considerar as estratégias do release Agenda.EXE Agenda.DLL 20

21 Introdução à Modelagem Arquitetural Visão de Implantação
A visão de implantação mostra a distribuição física do processamento no sistema. Para fornecer uma base que permitirá compreender a distribuição física do sistema em um conjunto de nós de processamento, uma visualização arquitetural chamada visualização de implantação é utilizada no fluxo de trabalho Análise & Design. A visão de implantação ilustra a distribuição do processamento em um conjunto de nós do sistema, incluindo a distribuição física dos processos e threads. Ela é refinada durante cada iteração. 21

22 Introdução à Modelagem Arquitetural Visão de Processos
Para fornecer uma base para compreender a organização do processo do sistema, uma visualização arquitetural denominada visualização do processo é utilizada na disciplina Análise e Design. Existe apenas uma visualização do processo do sistema, que ilustra a decomposição do processo do sistema, incluindo o mapeamento de classes e subsistemas para processos e encadeamentos. A visão de processos é refinada durante cada iteração. Em sistemas em tempo real, é recomendável o uso de Cápsulas para representar classes ativas na visualização do processo. As cápsulas possuem uma semântica forte para simplificar a modelagem da simultaneidade: Elas utilizam a comunicação baseada em mensagens assíncronas por meio de Portas utilizando Protocolos bem definidos. Elas utilizam uma semântica de execução-até-conclusão no processamento de mensagens. Elas encapsulam objetos passivos (assegurando que não ocorra interferência de encadeamentos). (*) Uma cápsula é um elemento UML usado para modelar sistemas de tempo real. 22

23 Introdução à Modelagem Arquitetural Visão 4+1 - O que usar
Nem todos os sistemas precisam de todas as visões: Sistema pequeno (ignore a visão de implementação). Processador único (ignore a visão de implantação). Processo único (ignore a visão de processos). Alguns sistemas precisam de visões adicionais: Visão de dados. Visão de segurança. Outros aspectos. 23

24 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Diagrama primário - Diagrama de classificadores estáticos (pacotes e classes). A visão da arquitetura do sistema que compreende o vocabulário do espaço do problema e da solução, as colaborações, que realizam os casos de uso do sistema, os subsistemas que determinam a decomposição do sistema em camadas, e as interfaces que são expostas pelos subsistemas e o pelo sistema como um todo. Foco em: Funcionalidade. Abstrações chave. Mecanismos. Separação de preocupações e distribuição de responsabilidades (colaborações). 24

25 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Pacotes: Mecanismo de propósito geral da UML para organização de elementos de modelos em grupos. Foco em: Funcionalidade. Abstrações chave. Mecanismos. Separação de preocupações e distribuição de responsabilidades (colaborações). Um pacote aglutina elementos UML. Cada elemento, entretanto, é contido por um único pacote. Se um pacote é “destruído”, os seus elementos também o são. Um pacote UML suporta a decomposição dos modelos hierarquicamente 25

26 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Exemplos: 26

27 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência: Representa principais abstrações da tecnologia, e serve como um template para que o código possa ser implementado. Expressa como um diagrama de classes. Um diagrama de classes de uma arquitetura de referência usa estereótipos e muitas vezes padrões de desenho para a sua representação. 27

28 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (1/7) Aplicação Delphi C/S 2 camadas com lógica nos formulários 28

29 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (2/7) Aplicação Delphi 3 Camadas C/S com lógica nos DataModules. Não verdadeiramente OO, mas MVC 29

30 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (3/7) Aplicação Delphi 3 Camadas C/S. 30

31 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (4/7) Aplicação Web Monolítica. 31

32 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (5/7) Aplicação ASP 3 Camadas com Componentes COM. 32

33 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (6/7) Aplicação Java EE Web Centric. 33

34 Introdução à Modelagem Arquitetural Modelagem da Visão Lógica
Arquitetura de referência - Exemplos: (7/7) Aplicação Java EE EJB Centric. 34

35 Diagrama primário - Diagrama de componentes.
Introdução à Modelagem Arquitetural Modelagem da Visão de Implementação Diagrama primário - Diagrama de componentes. Um diagrama de componentes é usado para mostrar as dependências de compilação e construção bem como de tempo de execução. A visão de implementação e a visão da arquitetura do sistema que compreende os componentes usados para montar e liberar fisicamente o sistema. A definição formal de componente para a UML é: “Uma parte modular de um sistema que encapsula seu conteúdo e cuja manifestação é substituível em seu ambiente. Um componente define seu comportamento em termos de interfaces fornecida e requerida. Portanto, um componente serve como um tipo, cuja conformidade é definida pelas interfaces fornecida e requerida (incluindo as semânticas estática e dinâmica).” 35

36 Introdução à Modelagem Arquitetural Modelagem da Visão de Implementação
UML 1.x UML 2.x Um componente representa um módulo de software (código fonte, binário, executável, DLL, etc.) com uma interface bem definida A interface do componente é representada por uma ou várias interfaces que o componente implementa. Considere o exemplo UML2 mostrado acima: A figura acima mostra uma classe Motor com uma porta p e duas interfaces: Uma interface fornecida trem de força, que especifica os serviços que o motor oferece nesta porta (isto é, as operações e recepções acessíveis por comunicação que chegam a esta porta). Uma interface requerida força, que especifica os serviços que o motor espera que seu ambiente forneça. Na porta p, a classe Motor está completamente encapsulada; ela pode ser especificada sem qualquer conhecimento do ambiente em que o motor será incorporado. Desde que o ambiente obedeça às restrições expressas pelas interfaces fornecidas e requeridas do motor, este funcionará corretamente. Para ilustrar isso, dois usos da classe Motor são mostrados neste exemplo: A classe Carro conecta a porta p do mecanismo a um conjunto de rodas por meio do eixo. A classe Barco conecta a porta p do mecanismo a uma hélice por meio do eixo. Desde que a interação entre o Motor e a peça vinculada à sua porta p obedeça às restrições especificadas pelas interfaces fornecidas e requeridas, o motor funcionará conforme especificado, independentemente se é um motor de carro ou um motor de barco. 36

37 Introdução à Modelagem Arquitetural Modelagem da Visão de Implementação
Exemplo: O pacote da API de Log Java sendo implementado como um componente com interfaces fornecidas agrupadas em portas Na especificação da API de Log Java, alguns dos serviços de log foram implementados como classes e outros como interfaces. Neste exemplo, modelamos cada um desses serviços conforme as interfaces fornecidas, que poderiam ser realizadas pelas peças dentro do componente. Os dois tipos diferentes de comportamento relacionados às colaborações de Gravação e Administração mencionadas acima poderiam ser representados por interfaces logicamente agrupadas em portas. Portanto, temos: As interfaces Registrador e Nível agrupadas na porta LogWriter. Essas interfaces são acessadas por clientes de log para gravar no log. As interfaces Rotina de Tratamento, Filtro e Formatador agrupadas na porta LogController. Essas interfaces são acessadas por administradores de log, que acessam o log e alteram as configurações. Essa alternativa de modelagem conduz a uma separação de interesses, agrupando logicamente as interfaces em diferentes portas. Temos precisão adicional para a especificação do componente e a interconexão que ela pode ter com o mundo externo. 37

38 Introdução à Modelagem Arquitetural Modelagem da Visão de Implantação
Diagrama primário - Diagrama de implantação. Um diagrama de implantação mostra a configuração dos processadores (nodos) em tempo de execução, os links de comunicação entre eles e as instâncias dos componentes e objetos que residem neles. A visão de implantação é a visão da arquitetura do sistema que compreende os nós que formam a topologia de hardware do sistema na qual o sistema vai executar Focos em: Distribuição. Comunicação. Provisionamento. 38

39 Introdução à Modelagem Arquitetural Modelagem da Visão de Implantação
Principais elementos: 1. Nodos Elementos com capacidade de processamento no sistema Propriedades: Nome; Descrição, provendo informação a respeito do processador, capacidade de armazenamento/memória, ou qualquer outra declaração de sua capacidade; A lista de processos e threads que executam no processador 2. Dispositivos Elementos sem capacidade de processamento, com os quais os nodos interagem Propriedades: Nome; Descrição das capacidades do dispositivo 3. Conexões (links) Representam uma conexão física entre nodos, tal como uma conexão Ethernet ou um barramento compartilhado. São associações estereotipadas e podem incluir papéis, multiplicidade, restrições, etc. 39

40 Introdução à Modelagem Arquitetural Modelagem da Visão de Implantação
Exemplo: 40

41 Introdução à Modelagem Arquitetural Modelagem da Visão de Implantação
Exemplo: 41

42 Introdução à Modelagem Arquitetural Dicas (1/2)
Arquiteturas devem capturar abstrações. Bom uso de hierarquias de classes. Decomposição baseada em pacotes. Uso de colaborações. 1. Monte arquiteturas que capturem todas as abstrações presentes no modelo do domínio, com os mecanismos necessários para animar estas abstrações dentro do domínio 2. Uma única hierarquia de classes é apropriado para aplicações muito simples. Em um sistema complexo, toda abstração fundamental no modelo do domínio deve possuir exatamente uma hierarquia de classes correspondente 3. Em um sistema orientado por objetos de larga escala, a unidade de decomposição é a categoria de classes, e não a classe individualmente (pacotes UML) Namespaces em C++, C# ou VB.NET, pacotes em Java ou Object Pascal Devem ser usadas para sistemas com mais de classes Cada categoria de classes deve possuir pelo menos uma dezena de classes, na média 4. Uma classe não faz muitas coisas por si só. Assim, especialmente quando considerar a dinâmica de um sistema, concentre-se em como certos grupos de objetos colaboram, de forma a capturar comportamento comum em mecanismos comuns Colaborações podem ser rastreadas para casos de uso 42

43 Introdução à Modelagem Arquitetural Dicas (2/2)
Uso de mecanismos arquiteturais. Uso de decisões estratégicas vs decisões táticas. Simplicidade. 5. A maioria dos sistemas requer menos de mecanismos centrais. Um mecanismo central é aquele que provoca mudanças arquiteturas mais profundas. Exemplos incluem: Persistência, mensagens, distribuição de objetos e migração de objetos, rede, transações, look and feel comum, eventos, condições excepcionais. 6. Um arquitetura bem estruturada denota a estrutura lógica e física do sistema, a partir das decisões estratégicas e táticas no desenvolvimento. 7. Procure construir arquiteturas simples, onde comportamento comum é capturado por mecanismos comuns (patterns). 43

44 Introdução à Modelagem Arquitetural Formalização do Modelo
Use templates estabelecidos para fazer a modelagem arquitetural. Um bom exemplo é o template de Documento de Arquitetura de Software (DAS) do RUP. Use este modelo para derivar o seu documento para uso em sistemas do mundo real. O DAS é contruído durante as fases de concepção e elaboração e mantido durante todo o restante do projeto pelo arquiteto de software. 44

45 Introdução à Modelagem Arquitetural Conclusões
A modelagem arquitetural captura as principais decisões estratégicas de um sistema. A UML2 fornece diversos diagramas para a modelagem arquitetural. A visão 4+1 é uma boa abstração para a representação de diversas visões. Visão 4+1 deve ser complementada com tópicos mais avançados como mecanismos de arquitetura e padrões. A representação UML de uma arquitetura é um conjunto de visualizações arquiteturais relevantes: Caso de Uso, Lógica, Processo, Implantação, Dados. Algumas visões de arquitetura podem ser irrelevantes: A Visão de Implantação não é necessária para sistemas de uma única CPU. A Visão de Processos não será necessária se o sistema usar apenas um único encadeamento de controle. A Visualização de Dados não é necessária, a menos que a persistência de objeto seja um aspecto significativo do sistema e o mecanismo de persistência requeira um mapeamento entre objetos persistentes e não persistentes. Alguns aspectos específicos do software podem necessitar de uma seção própria; por exemplo, os aspectos relacionados às questões de gerenciamento de dados ou de usabilidade. Apêndices adicionais podem ser necessários para explicar determinados aspectos, como os fundamentos de algumas escolhas críticas junto com as soluções que foram eliminadas, ou para definir acrônimos ou abreviações, ou para apresentar princípios gerais de design. A ordem das várias seções pode variar, dependendo do foco ou do interesse dos envolvidos no negócio. 45

46 The 4+1 View Model of Architecture
Para saber mais... The 4+1 View Model of Architecture PANGEA Pangea é uma rede formada por profissionais e acadêmicos interessados no crescimento e evolução da arquitetura de software.

47 Capacitação IGTI