Arquitetura de Sw - Eds

9/24/2020 1 slide 1 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Capítulo 6 Projeto de arquitetura 1 © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 slide 2 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Os tópicos abordados • Introdução a arquitetura de SW • Visões de arquitetura • Padrões de arquitetura • Arquiteturas de aplicações 2 1 2 9/24/2020 2 slide 3 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 3 O que é Arquitetura de Software? Não existe uma definição universal “Arquitetura é a organização fundamental de um sistema, incorporada em seus componentes, nas relações entre eles e com o ambiente, e os princípios que regem seu projeto e evolução. ” ANSI/IEEE Std 1471-2000 Estrutura do sistema: • componentes ou partes da implementação • as propriedades visíveis externamente desses componentes, e • as relações entre eles slide 4 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Projeto de Arquitetura • Uma fase inicial do processo de concepção do sistema. • Representa a ligação entre a levantamento de requisitos e o projeto do sistema. • Muitas vezes realizadas em paralelo com algumas atividades de especificação. • Descrito no Documento de Arquitetura 4 3 4 9/24/2020 3 slide 5 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura: componentes e relações Componentes ▪ Blocos (alto nível) do sistema ▪ Suporta • Modularidade • Separação de papéis ▪ Colaboração entre componentes • Prover serviços (funcionalidades) • Num dado nível de serviço (qualidades) ▪ Interface entre componentes • Provê encapsulação, com pontos de acesso restritos ▪ Especificação dos componentes • Define propriedades visíveis externamente • Provê guias de utilização slide 6 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Propriedades visíveis externamente: o propósito das interfaces Interfaces ▪ Define os pontos de acesso aos componentes ▪ Facilita o plug-and-play entre componentes • ameniza restrições entre clientes e provedores • Serve como um contrato entre provedores de componentes e clientes ▪ Define externamente propriedades visíveis Uma interface bem definida ▪ Facilita o entendimento e compreensão do comportamento do componente e como ele é usado ▪ Aumenta a produtividade do desenvolvedor • Foca na montagem e ligação entre componentes através de suas interfaces 5 6 9/24/2020 4 slide 7 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 7 Arquitetura X Projeto Toda arquitetura é projeto, mas nem todo projeto é arquitetura A arquitetura restringe as decisões de projeto de mais baixo nível ▪ Essas decisões devem ser compatíveis com a arquitetura O comportamento dos componentes (funcionamento interno) é definido no projeto slide 8 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 8 Documentação da Arquitetura  Todo sistema tem uma arquitetura  A documentação é uma tentativa de representação desta arquitetura  Serve como ▪ Veículo de comunicação entre atores ▪ Base para análise dos atributos do sistema ▪ Guia para o desenvolvimento 7 8 9/24/2020 5 slide 9 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 9 Visões slide 10 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 10 Visões Uma arquitetura é algo difícil de ser visualizado de uma única vez Sistemas são compostos de várias estruturas ▪ Módulos, mostrando a composição/decomposição mapeadas ao código ▪ Processos e como estes se sincronizam ▪ Programas e como estes trocam dados ▪ Como o software é distribuído no hardware Visões são usadas para gerenciar esta complexidade 9 10 9/24/2020 6 slide 11 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 11 Visões Diferente visões expõem certos requisitos não funcionais em diferentes níveis. Ex: ▪ Visão de Deployment – Performance e confiança ▪ Visão em Camada - Portabilidade A relevância das visões varia de acordo com o projeto ▪ Quem são os atores? ▪ Qual relação destes com a arquitetura? Nenhum visão específica pode representar toda a arquitetura slide 12 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 12 Esquemas de Visões São conjuntos de visões propostos por vários autores ▪ Kruchten, Rational 4+1 ▪ OMT ▪ Booch Apesar de diferirem, todas as visões podem ser classificadas usando alguma destas categorias: ▪ Estruturação em termos de unidades de implementação, denominados módulos ▪ Estruturação em termos de componentes que possuem comportamento em tempo de execução ▪ Relacão ou alocação do software com o ambiente 11 12 9/24/2020 7 slide 13 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Visões da arquitetura Arquitetura Conceitual • Diagramas arquiteturais, especificação informal de componentes • Foco: identificação e alocação de responsabilidades entre componentes Arquitetura Lógica • Atualiza os diagramas arquiteturais (apresentando as interfaces), especificação interface, especificação de componentes e guias de utilização • Foco: design da interação, mecanismos e protocolos de conexão; provimento de info contextual para os usuários dos componentes Arquitetura Execução • Visão do Processo (via Diagramas de Colaboração) • Foco: informa como se dará o comportamento do componente em tempo de execução, threads; como eles se comunicam; como os recursos físicos são alocados. Visão global do sistema Esquema para os desenvolv: •preciso •Sem ambigui- dade slide 14 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Endereçando trade-offs (re)Lembrando: arquitetura aborda ▪ a decomposição do sistema em componentes ▪ foco nas propriedades críticas do sistema e seus trade-offs Trade-offs devem ser endereçados ▪ Através de padrões/estilos arquiteturais ▪ Estrutura: componentes e interfaces ▪ Mecanismos: papéis dos componentes e padrões de interação • Responsabilidades (atribuídas aos componentes) • Comportamento expresso nas interações • fluxo das interações 13 14 9/24/2020 8 slide 15 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Visões da arquitetura Arquitetura Conceitual • Diagramas arquiteturais, especificação informal de componentes • Foco: identificação e alocação de responsabilidades entre componentes Arquitetura Lógica • Atualiza os diagramas arquiteturais (apresentando as interfaces), especificação interface, especificação de componentes e guias de utilização • Foco: design da interação, mecanismos e protocolos de conexão; provimento de info contextual para os usuários dos componentes Arquitetura Execução • Visão do Processo (via Diagramas de Colaboração) • Foco: informa como se dará o comportamento do componente em tempo de execução, threads; como eles se comunicam; como os recursos físicos são alocados. Qualidades do sistema: encapsulamento e separação de papéis Mecanismos e interações entre componentes Topologia do sistema/recursos e concorrência slide 16 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Estilos/Padrões de arquitetura • Padrões são um meio de representar, partilhar e reusar conhecimento. • Um padrão de arquitetura é uma descrição estilizada das boas práticas de projeto, que tem sido experimentadas e testadas em diferentes ambientes. • Os padrões devem incluir informações sobre quando elas são úteis ou não. • Definem uma família de arquiteturas 16 15 16 9/24/2020 9 slide 17 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 17 Estilo Pipe-and-Filter - Exemplo Divide a tarefa de um sistema em vários passos de processamento sequencial Componentes ▪ São chamados filtros ▪ Tem um conjunto de entradas e saídas ▪ Processa um stream de dados Conectores ▪ Pipes: servem como condutores dos dados Ex: Compiladores, Shell Unix slide 18 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 18 Estilo Pipe-and-Filter - Exemplo  Especializações do estilo ▪ Pipelines, Typed Pipes...  Implementação ▪ Divida as tarefas do sistema em uma sequência de estágios de processamento • Cada estágio deve depender somente da saída do seu predecessor • Todos os estágios são conectados por um fluxo de dados ▪ Defina o formato de dados a ser passado ao longo de cada pipe ▪ Decida como implementar cada conexão com pipe • Se estes serão ativos ou passivos 17 18 9/24/2020 10 slide 19 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 19 Exemplo do Uso de Estilos  “O sistema X tem como entrada um conjunto de linhas. As linhas são formadas por palavras que por sua vez são formadas por caracteres. As linhas podem sofrer um shift circular quando a primeira palavra é retirada do início e colocada no final. O sistema gera a lista de todas os possíveis shifts de todas as linhas em ordem alfabética.”  Cada estilo possuis suas vantagens e desvantagens: ▪ Subrotina com dados compartilhados ▪ Pipe-and-Filter ▪ Etc... slide 20 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 20 Subrotina com dados compartilhados  Não permite reuso, mudanças não são bem toleradas, eficiente no uso do espaço 19 20 9/24/2020 11 slide 21 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 21 Pipe-and-Filter Unidades de processamento isolados (assimila melhor as mudanças) Facilidade de acréscimos de novos filtros Porém ineficiente em termos de uso de espaço slide 22 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 22 Processo de Arquitetura 21 22 9/24/2020 12 slide 23 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 23 Processo de Arquitetura Fases em um nível macro: ▪ Elaboração do modelo de negócio ▪ Entendimento dos requisitos ▪ Criação ou seleção de uma arquitetura ▪ Representação e divulgação ▪ Implementação baseada na arquitetura ▪ Avaliação da arquitetura Modelos Arquiteturais ▪ Negócio, domínio da aplicação, componentes, infra-estrutura tecnológica, distribuição do software slide 24 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 24 Papéis Analista de requisitos ▪ Identifica requisitos funcionais e não-funcionais Arquiteto ▪ Cria a arquitetura e identifica outros requisitos não-funcionais que a arquitetura deve atender ▪ Acompanha o processo de desenvolvimento da arquitetura proposta Projetista ou Implementador ▪ Implementador dos componentes propostos 23 24 9/24/2020 13 slide 25 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 25 Relação com outras fases do processo  A arquitetura deve objetivar todo o sistema  Pode haver ênfase para a 1ª versão slide 26 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 26 Relação com outras fases do processo  Arquitetura guia as fases subsequentes 25 26 9/24/2020 14 slide 27 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 27 Na prática... slide 28 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 28 Mas e aí, como se faz?  O conjunto de visões arquiteturais é o meio pelo qual tentamos gerenciar a complexidade do software  Etapa intermediária necessária da transformação dos requisitos em código  Na prática, podemos adotar uma abordagem crescente de detalhamento ▪ Visão de Negócio ▪ Visão Conceitual ▪ Visão de Desenvolvimento ▪ Visão de Deployment 27 28 9/24/2020 15 slide 29 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 29 Fazendo um “Zoom” Visão de Negócio ▪ Como o negócio funciona? Visão Conceitual ▪ Quais os principais conceitos envolvidos e como estes se relacionam? Visão de Desenvolvimento ▪ Qual a melhor maneira de implementar estes conceitos tendo em vista a solução? Visão de Deployment ▪ Depois de pronto como o software sera instalado e distribuído ao longo da infra-estrutura? slide 30 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 30 Visão de Negócio  Atores, processos e suas interações Como o negócio resolve o problema 29 30 9/24/2020 16 slide 31 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 31 Visão de Negócio  Como as entidades de negócio colaboram slide 32 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 32 Visão Conceitual  Mais próxima ao domínio da solução  Ainda não tem os detalhes necessários à implementação  Conceitos e suas relações 31 32 9/24/2020 17 slide 33 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 33 Visão de Desenvolvimento  Qual a melhor maneira de implementar a solução tendo em vista os requisitos?  Modularização, comunicação entre subsistemas, reusabilidade  Emprego de padrões/estilos arquiteturais ▪ Pipe and Filters, MVC, etc slide 34 © 2011 Pearson Prentice Hall. Todos os direitos reservados. 34 Visão de Deployment  Modela ▪ Infra-estrutura ▪ Como o Software está instalado na infra-estrutura ▪ Mecanismos de comunicação (middleware) 33 34 9/24/2020 18 slide 35 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Decisões de projeto de arquitetura • Como o sistema será distribuído? • Que abordagem será usada para estruturar o sistema? • Como o sistema pode ser decomposto em módulos? • Qual estratégia de controle deve ser usada? • Existe uma arquitetura genérica que possa ser usada? • Quais estilos de arquitetura são apropriados? • Como o projeto de arquitetura será avaliado? • Como a arquitetura deve ser documentada? 35 slide 36 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Material Complementar para estudo Chapter 6 Architectural design 36 35 36 9/24/2020 19 slide 40 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Padrões de arquitetura • Padrões são um meio de representar, partilhar e reusar conhecimento. • Um padrão de arquitetura é uma descrição estilizada das boas práticas de projeto, que tem sido experimentadas e testadas em diferentes ambientes. • Os padrões devem incluir informações sobre quando elas são úteis ou não. 40 slide 41 © 2011 Pearson Prentice Hall. Todos os direitos reservados. O padrão do Modelo-Visão-Controlador (MVC) 41 40 41 9/24/2020 20 slide 42 © 2011 Pearson Prentice Hall. Todos os direitos reservados. A organização do MVC 42 slide 43 © 2011 Pearson Prentice Hall. Todos os direitos reservados. A arquitetura de aplicações web usando o padrão MVC 43 42 43 9/24/2020 21 slide 44 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura em camadas • Usada ​para modelar a interface dos subsistemas. • Organiza o sistema em um conjunto de camadas (ou máquinas abstratas) cada uma das quais fornecem um conjunto de serviços. • Apoia o desenvolvimento incremental de subsistemas em diferentes camadas. Quando uma camada na interface muda, apenas a camada adjacente é afetada. • No entanto, em algumas situações, é artificial estruturar sistemas dessa forma. 44 slide 45 © 2011 Pearson Prentice Hall. Todos os direitos reservados. O padrão de arquitetura em camadas 45 44 45 9/24/2020 22 slide 46 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Uma arquitetura genérica em camadas 46 slide 47 © 2011 Pearson Prentice Hall. Todos os direitos reservados. A arquitetura do sistema LIBSYS 47 46 47 9/24/2020 23 slide 48 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Pontos Importantes • Uma arquitetura de software é uma descrição de como um sistema de software é organizado. • Decisões de projeto de arquitetura incluem decisões sobre o tipo de aplicação, a distribuição do sistema, e o estilo de arquitetura a ser usada. • As arquiteturas podem ser documentadas de várias perspectivas ou visões diferentes tais como uma visão conceitual, uma visão lógica, uma visão de processo, uma visão de desenvolvimento e uma visão física. • Os padrões de arquitetura são um meio de reusar o conhecimento sobre as arquiteturas genéricas de sistemas. Eles descrevem a arquitetura, explicam quando podem ser usados e descrevem suas vantagens e desvantagens. 48 slide 49 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura cliente-servidor • O modelo de sistema distribuído mostra como os dados e processamento são distribuídos através de uma série de componentes. • Um conjunto de servidores autônomos que prestam serviços específicos, tais como impressão, gerenciamento de dados, etc. • Um conjunto de clientes que solicitam estes serviços. • Rede que permite aos clientes acessar os servidores. 49 48 49 9/24/2020 24 slide 50 © 2011 Pearson Prentice Hall. Todos os direitos reservados. O padrão cliente-servidor 50 slide 51 © 2011 Pearson Prentice Hall. Todos os direitos reservados. A arquitetura cliente-servidor para uma biblioteca de filmes 51 50 51 9/24/2020 25 slide 52 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Padrões de arquitetura C/S • Estilos amplamente usadas de organizar a arquitetura de um sistema distribuído: ✓ Arquitetura mestre-escravo, usada em sistemas de tempo real em que é necessária a garantia dos tempos de resposta de interação. ✓ Arquitetura cliente-servidor de duas camadas, usada para sistemas cliente-servidor simples e nos quais o sistema é centralizado por razões de proteção. ✓ Arquitetura cliente-servidor multicamadas, usada quando existe um grande volume de transações a serem processadas pelo servidor. ✓ Arquitetura distribuída de componentes, usada quando os recursos de diferentes sistemas e bases de dados precisam ser combinados, ou como um modelo de implementação para sistemas cliente-servidor multicamadas. ✓ Arquitetura ponto-a-ponto, usada quando os clientes trocam informações armazenadas localmente e o papel do servidor é apresentar os clientes uns aos outros slide 53 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquiteturas mestre-escravo • As arquiteturas mestre-escravo geralmente são usadas ​em sistemas de tempo real onde existem processadores separados associados à aquisição de dados do ambiente do sistema, processamento de dados, gerenciamento de atuadores e computação. • O processo 'mestre' geralmente é responsável pelo processamento, coordenação e comunicações e controla os processos 'escravos'. • Os processos 'escravos' são dedicados a ações específicas, tais como a aquisição de dados de um vetor de sensores. 52 53 9/24/2020 26 slide 54 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Um sistema de gerenciamento de tráfego com uma arquitetura mestre-escravo slide 55 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura mestre-escravo: Computação de alto desempenho 55 54 55 9/24/2020 27 slide 56 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquiteturas cliente-servidor de duas camadas • Em uma arquitetura cliente-servidor de duas camadas, o sistema é implementado como um único servidor lógico mais um número indefinido de clientes que usam esse servidor. ✓ O modelo cliente-magro (thin-client), em que a camada de apresentação é implementada no cliente e todas as outras camadas (gerenciamento de dados, processamento de aplicação e banco de dados) são implementadas em um servidor. ✓ O modelo cliente-gordo (fat-client), em que parte ou todo o processamento da aplicação é realizado no cliente. As funções de gerenciamento de dados e banco de dados são implementadas no servidor. slide 57 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Modelos de arquiteturas cliente-magro e cliente-gordo 56 57 9/24/2020 28 slide 58 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Modelo cliente-magro • Usado quando sistemas legados são migrados para arquiteturas cliente- servidor. ✓ O sistema legado atua como um servidor em si, com uma interface gráfica implementada em um cliente. • Uma grande desvantagem é que coloca uma carga pesada de processamento no servidor e na rede. slide 59 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Modelo cliente-gordo • Mais processamento é delegado ao cliente já que o processamento da aplicação é executado localmente. • Mais adequado para sistemas cliente-servidor novos em que as capacidades do sistema cliente são conhecidas antecipadamente. • Mais complexo do que um modelo cliente-magro, especialmente no gerenciamento. • Novas versões da aplicação precisam ser instaladas em todos os clientes. 58 59 9/24/2020 29 slide 60 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquiteturas cliente-servidor multicamadas • Em uma arquitetura cliente-servidor multicamadas, as diferentes camadas do sistema, chamadas apresentação, gerenciamento de dados, processamento de aplicação e banco de dados são processos separados que podem ser executados em diferentes processadores. • O que evita problemas com escalabilidade e desempenho, caso um modelo cliente-magro de duas camadas seja escolhido, ou problemas de gerenciamento do sistema caso um modelo cliente-gordo for usado. slide 61 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura de três camadas de um sistema de Internet Banking 60 61 9/24/2020 30 slide 62 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Uso de padrões de arquitetura cliente-servidor slide 66 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Desvantagens da arquitetura de componentes distribuídos • As arquiteturas de componentes distribuídos sofrem de duas grandes desvantagens: ✓ Elas são mais complexas para se projetar do que sistemas cliente-servidor. A arquitetura de componentes distribuídos é difícil para as pessoas visualizarem e compreenderem. ✓ Middlewares padronizados para sistemas de componentes distribuídos nunca foram aceitos pela comunidade. Diferentes fornecedores como a Microsoft e a Sun desenvolveram middlewares diferentes e incompatíveis. • Como resultado desses problemas, em muitas situações as arquiteturas orientadas a serviços estão substituindo arquiteturas de componentes distribuídos. 62 66 9/24/2020 31 slide 68 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Modelos de arquitetura p2p: A arquitetura da rede lógica • Arquiteturas descentralizadas • Arquiteturas semicentralizadas slide 69 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura de sistemas de informação • Os sistemas de informação têm uma arquitetura genérica que pode ser organizada como uma arquitetura em camadas. • Esses são sistemas baseados em transações pois geralmente a interação com esses sistemas envolve transações de banco de dados. • As camadas incluem: ✓ Interface de usuário ✓ Comunicações de usuário ✓ Recuperação e modificação de informações ✓ Banco de dados do sistema 69 68 69 9/24/2020 32 slide 70 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Arquitetura do sistema de informação em camadas 70 slide 71 © 2011 Pearson Prentice Hall. Todos os direitos reservados. A arquitetura do MHC-PMS 71 70 71 9/24/2020 33 slide 80 © 2011 Pearson Prentice Hall. Todos os direitos reservados. Pontos Importantes • Modelos genéricos de arquiteturas de sistemas de aplicação nos ajudam a entender e comparar as aplicações, validar projetos de sistemas de aplicação e avaliar componentes para reuso em larga escala. • Os sistemas de processamento de transações são sistemas interativos que permitem que a informação em um banco de dados seja acessada remotamente e modificada por vários usuários. • Os sistemas de processamento de linguagem são usados para traduzir textos de uma linguagens para outra e para realizar as instruções especificadas na linguagem de entrada. • Eles incluem um tradutor e uma máquina abstrata que executa a linguagem gerada. 80 80