Padrões de Arquitetura

Apresentação em tema: "Padrões de Arquitetura"— Transcrição da apresentação:

1 Padrões de Arquitetura

2 Padrões e Estilos Há um debate em relação a se esses termos representam o mesmo conceito Um estilo de arquitetura é uma coleção de decisões de arquitetura que: São aplicadas em um determinado contexto Restringe decisões de projeto da arquitetura que são específicas a um determinado software Um padrão de arquitetura é um conjunto de decisões de arquitetura que são aplicáveis em um problema de design recorrente. É mais comum falar em estilos de arquitetura Vamos usar os dois termos como sinônimos neste curso

3 Níveis de Padrões Padrões de Arquitetura Padrões de Projeto Idiomas
Padrões de alto nível, usados para especificar a estrutura fundamental de um sistema de software Padrões de Projeto Padrões em médio nível usados para organizar as funcionalidades de subsistemas de forma independente Idiomas Padrões em baixo nível, orientados a resolver problemas de implementação específicos, ou como implementar algo em uma linguagem de programação

4 Camadas (Layered) Organização hierárquica
Cada camada provê serviço para a camada acima Cada camada é cliente da camada abaixo Um dos padrões mais conhecidos Cada camada provê um conjunto de serviços coesos, e possui interface bem definida Os componentes de uma camada geralmente implementam serviços em diferentes níveis de abstração Cada camada passa a idéia de virtual machine

5 Virtual (abstract) machine
Coleção de módulos que provêem um conjunto coeso de serviços que outros módulos podem usar sem saber como esses serviços são implementados. Um módulo que possui uma interface pública provê um conjunto de serviços, mas não necessariamente constitui uma virtual machine.

6 Use vs. Call Um componente A usa um componente B se uma versão correta de B deve estar presente para que A seja executado corretamente Um componente A chama um componente B se a execução de A leva a execução de B No estilo em camadas, cada camada somente pode usar as camadas abaixo Uma camada pode chamar todas as outras camadas, mas somente pode usar as camadas abaixo

7 Boas propriedades de camadas
Projeto em diferentes níveis de abstração Particionamento de um problema complexo Facilita evolução do SW Mudanças são localizadas (camadas N, N-1 e N+1) Alto reuso Diversas implementações de cada camada (desde que as interfaces sejam mantidas) Alta coesão Relativo baixo acoplamento

8 Boas propriedades de camadas
Diversos níveis de abstração, de mais específicos (top levels), para níveis mais gerais (lower levels) Detalhes são escondidos de acordo com a conveniência, aumentando separation of concerns Camadas podem ser agrupadas/expandidas

9 Desvantagens de Camadas
Não são todos os sistemas que podem ser estruturados em camadas Desempenho A informação precisa passar em muitos níveis Debug Operações são implementadas em uma série de calls

10 Quantas camadas? Difícil acertar o nível de abstração Poucas Muitas
mudanças podem não ser tão isoladas, camadas podem ser muito grandes, baixo reuso Muitas pode ocorrer baixa coesão, necessidade de muita colaboração entre camadas, baixo desempenho

11 Quando usar camadas? Com o objetivo de aumentar as possibilidades de alterações, manutenibilidade, reusabilidade Quando o desempenho não é um fator primordial Quando nenhum outro estilo parece ser correto para o problema

12

13 Layers vs. Tiers Layers: construções conceituais que separam logicamente funcionalidades de um sistema Tiers: quando layers são implementadas em sistemas reais

14

15

16 Two-tier architectures
Originados com o surgimento de PCs Mainframes e grandes servidores conectados a PCs e workstations A camada de apresentação é movida para o cliente A capacidade computacional do cliente é aproveitada Arquitetura popular, particularmente como arquiteturas cliente-servidor

17

18 Three-tier architectures
Como fazer o cliente conversar com vários servidores? Como integrar diversos servidores? Como aproveitar a largura de banda provida pelas redes? Solução: 3-tier architectures

19

20 Three-tier architectures
A camada de aplicação pode ser distribuída entre diversos servidores, aumentando desempenho A camada de aplicação é menos dependente de um determinado gerenciador de recursos, aumentando a portabilidade e o reuso A camada de gerenciamento de recursos precisa prover interfaces bem definidas para serem acessadas por aplicações executando no middleware

21 Three-tier architectures
A camada de gerenciamento de recursos precisa prover interfaces de forma uniforme (ex. ODBC, JDBC) Desempenho é diminuído, mas há aumento de flexibilidade Desempenho pode não ser um problema se o middleware for executado em vários nós (aumento da escalabilidade e reliability) Desvantagem: Integração de sistemas legados com a internet

22 N-tier Architectures (multi-tier)
De forma genérica, n-tier architectures existem para: Conectar sistemas diferentes Adicionar sistemas a Internet A camada de gerenciamento de recursos pode incluir além de um banco de dados outros sistemas em camadas (2 ou 3) ex. adicionar web servers na camada de apresentação

23

24

25 Existe o estilo em camadas?
In Stephen T. Albin's view in "The Art of Software Architecture: Design Methods and Techniques", hierarchical layer is not a real architecture style. He considers layer as the basic attribute of large complicated software architecture. In Stephen's view, all of the complicated systems have different layers, this means there exists a basic architecture structure view that represents system' s composition. So, Stephen did not describe the hierarchical layer in single part.

26 Pipe and Filters Estilo que pode ser usado em sistemas que transformam strings de entrada em strings de saída Não é útil para sistemas que interagem com pessoas ou para sistemas reativos É muito usado quando grande string de dados deve ser processada

27 Características Filters lêem a entrada e produzem saída através de:
Refinamentos: comprimir ou extrair informações Conversões: mudar o formato Enriquecimento: adição de informações Filters não possuem estados externos visíveis Não comunicam com outros componentes Filters podem produzir saída antes mesmo de consumir toda a entrada

28 Características Filters são independentes um do outro
Portanto, vários filters podem ser executados concorrentemente. Neste caso, pipes devem ser usados para sincronia Pipes podem ser Buffers: segura a entrada enquanto os filters de saída não estão prontos

29 Características Filters devem ser bloqueados se:
Estão prontos para entrada, mas seus input pipes não estão Estão prontos para saída, mas seus output pipes estão cheios Filters podem atuar de forma assíncrona, concorrente e independente Filters não precisam saber a identidade de outros filters

30 Topologias Um arranjo linear de pipes and filters é chamado de pipeline Bounded pipes a quantidade de dados no pipe é limitada Typed pipes dados fortemente tipados no pipe

31 Vantagens Filters podem ser facilmente modificados, substituídos
Filters podem ser rearranjados com pouco esforço (vários programas semelhantes podem ser desenvolvidos) Filters são altamente reusáveis Suporte a concorrência é relativamente fácil de implementar Uso em grandes sistemas que devem tratar grande quantidade de dados Filters podem ser combinados/divididos

32 Desvantagens Filters geralmente consomem e produzem dados simples, como strings de caracteres Tratamento de erros é difícil, tornando esse estilo inadequado quando segurança é um requisito Pipes podem ter dificuldade de fazer a sincronização Componente mais lento em um pipeline Inadequado para aplicações interativas

33

34 Compilador O analisador léxico converte uma cadeia de caracteres em uma cadeia de tokens O analisador semântico enriquece uma árvore sintática ao adicionar anotações a ela

35

36 Event-Driven Boa escolha para sistemas que devem reagir a eventos imprevisíveis do ambiente Boa escolha para softwares com complexa interface gráfica (o software deve estar pronto para vários eventos) Escalável Efetivo para aplicações altamente distribuídas

37 Vantagens Componentes que anunciam eventos não possuem conexão com componentes que respondem a eles (estão desconectados) Relativamente fácil adicionar, remover e alterar componentes A independência dos componentes dá suporte a reusabilidade, tolerância a falhas e robustness

38 Desvantagens Componentes que anunciam eventos não podem garantir que algum componente irá responder Não há garantia que a ordem de resposta é a ideal O tráfego de eventos tem a tendência de ser altamente variável (possíveis problemas de desempenho)

39 Cliente-Servidor O cliente faz pedidos aos servidores e trata entradas e saídas do ambiente do sistema O servidor oferece serviços. Ex. File servers, print servers Vários usuários querem compartilhar e trocar dados.

40 Cliente-Servidor Os servidores possuem interfaces que descrevem os serviços que eles podem prover. Os clientes iniciam as ações ao pedir serviços aos servidores. Portanto, o cliente deve saber a identidade do servidor para poder invocá-lo. Servidores não sabem a identidade nem o número de clientes antes do pedido de serviço, e devem responder aos pedidos iniciados pelo cliente

41 Cliente-Servidor – análises a serem feitas
Determinar se os servidores são capazes de prover os serviços requeridos pelos clientes. Determinar se os clientes usam os serviços de forma apropriada. Entender se um sistema consegue se recuperar após uma falha de um ou mais serviços. Análise de segurança: determinar se a informação é limitada apenas aos clientes que têm o privilégio de recebe-la. Desempenho: determinar se os servidores conseguem acompanhar os pedidos dos clientes, em termos de volume e taxas.

42 Cliente – servidor: Desvantagens
O cliente faz um pedido de serviço e espera até receber uma resposta. O cliente precisa conhecer que tipo de serviço é oferecido por determinado servidor O cliente precisa saber como contactar os servidores Servidores podem atuar como clientes, fazendo pedido a outros servidores, mas não podem fazer pedidos aos clientes.

43 Centralizado Um subsistema tem controle geral para iniciar e parar todos subsistemas Tipos: Call-return Controlador

44

45

46 Microkernel Aplicado a sistemas de software que devem ser capazes de se adaptar a mudanças nos requisitos. Uma parte funcional mínima de funcionalidades é separada de partes específicas do cliente. O microkernel também serve como socket para plugar as extensões Geralmente associado a sistemas operacionais. Entretanto, este estilo pode ser aplicado a outros domínios, como financeiro.

47 Problema Desenvolver software para um domínio que precisa lidar com muitos padrões e tecnologias similares não é uma tarefa trivial. Ex. SO e GUI. Fatores adicionais a considerar quando desenvolver esses sistemas: A aplicação deve lidar com muitas mudanças de HW e SW A aplicação deve ser portável, extensível e adaptável para permitir fácil integração de tecnologias emergentes

48 Solução com microkernel
Encapsular os serviços fundamentais da aplicação em um componente (microkernel) O microkernel inclui funcionalidade que: Mantém recursos do sistema como arquivos e processos Provê interfaces que permitem outros componentes acessar sua funcionalidade

49 Solução com microkernel
Funcionalidades devem ser separadas em servidores internos Manter complexidade e tamanho Servidores externos são processos separados que representam uma aplicação. Clientes se comunicam com servidores externos usando os mecanismos de comunicação provido pelo microkernel

50 Exemplos de microkernel
SO Amoeba formado por 2 elementos básicos: o microkernel Uma coleção de servidores (subsystems) usados para implementar funcionalidades adicionais. O kernel provê 4 serviços básicos: Gerenciamento de processos e threads, Low-level-management da memória do sistema, Comunicação, tanto ponto-a-ponto, como em grupos low-level I/O services. Serviços não providos pelo kernel devem ser implementados por servidores. Desta forma, o kernel é pequeno e a flexibilidade é alta.

51 Benefícios Portabilidade Flexibilidade e Extensibilidade
Migrar o microkernel para um novo HW  modificações apenas nas partes dependentes do HW Flexibilidade e Extensibilidade adicionar um novo servidor externo novas funcionalidades são implementadas adicionando-se servidores internos Alta manutenibilidade e modificabilidade

52 Microkernel e Layers O estilo microkernel pode ser considerado um variante do estilo em camadas O microkernel implementa uma máquina virtual através de servidores internos Aplicações estão no topo da camada

53 Distributed Microkernel
Uma variante do microkernel com benefícios: Escalabilidade Confiabilidade, através de availability e fault tolerance. Servidores executam em mais de uma máquina Falhas não necessariamente impactam a aplicação Falhas podem ser escondidas do usuário Transparência Cada componente pode acessar outros componentes sem precisar saber sua localização.

54 Blackboard Útil quando não são conhecidas soluções determinísticas
Subsistemas especialistas combinam conhecimento para construir uma solução parcial ou aproximada Contexto: domínio imaturo em que nenhuma abordagem de solução é conhecida ou possível Ex. visão, reconhecimento de imagens, reconhecimento de voz

55 O nome blackboard Cada especialista avalia o estado atual da solução de forma independente, e vai ao blackboard a qualquer momento para adicionar, mudar, apagar informações Pessoas decidem entre si quem tem o próximo acesso Componente moderador decide a ordem em que cada software executa para dar sua contribuição

56 Blackboard - características
Problemas típicos: decomposição leva a vários subproblemas em diversas áreas de conhecimento Soluções para problemas parciais requerem representações e paradigmas diferentes Cada passo na transformação pode levar a muitas soluções alternativas

57 Blackboard - características
Uma busca completa em todo o espaço de soluções não é possível em um período de tempo razoável Domínio imaturo → experimentar diferentes algoritmos para a mesma tarefa. Algoritmos com diversos paradigmas Incerteza e soluções aproximadas

58 Blackboard - estrutura
Blackboard – parte que centraliza dados, controle, e espaço de soluções. Knowledge sources – subsistemas independentes que resolvem aspectos específicos do problema Juntos modelam o domínio Nenhum pode resolver sozinho o problema Control component – usa os dados do blackboard para: Monitorar as mudanças Decidir as próximas ações

59 Exemplos HEARSAY-11. The first Blackboard system was the HEARSAY-11 speech recognition system from the early 1970's. HASP/SIAP. The HASP system was designed to detect enemy submarines CRYSALIS. This system was designed to infer the three-dimensional structure of protein molecules from X-ray diffraction data Expert systems

60 Middleware Gerencia as interações entre aplicações em plataformas heterogêneas Integra coleção de servidores e aplicações sob uma interface comum Objetivos facilitar o desenvolvimento de aplicações distribuídas facilitar a integração de sistemas legados Middleware é similar à camada intermediária da arquitetura three-tier, com a diferença de estar distribuído entre múltiplas aplicações

61 Características de Middleware
Middleware fornece abstrações que escondem a alta complexidade de construção de sistemas distribuídos As abstrações providas pelo middleware estão no topo de uma complexa estrutura de software Tipos: RPC, Monitors, Brokers, Message-oriented

62 Remote Procedure Call Proposto formalmente em 1984
Idéia: chamada de procedimentos em outras máquinas de forma transparente Cliente: chama um procedimento remoto e espera o retorno Servidor: programa que implementa o procedimento chamado

63 RPC - Problemas RPC funciona bem enquanto clientes e servidores estão funcionando bem Alguns problemas: O cliente não consegue localizar o servidor O pedido do cliente para o servidor é perdido A resposta do servidor para o cliente é perdida O servidor crashes após receber o pedido O cliente crashes após enviar o pedido

64 Transaction Processing Monitors
Uma das formas mais antigas de middleware IBM CICS (end of 1960's) TP Monitors foram desenvolvidos para que mainframes suportassem a distribuição de recursos para clientes Portanto, precisavam de consistência de dados → transações Inicialmente TP Monitors eram baseados em one tier architectures

65 TP Monitors - Aplicações
Atualmente fazem parte de muitas aplicações: Financeiras Indústria de vendas de passagens Seguradoras Sistemas de controle industriais 90% das Fortune 500 usam CICS Outras aplicações comerciais: Microsoft MTS BEA Tuxedo

66 Monitores e Transações
Monitores suportam milhares de clientes de forma concorrente Para isso usam threads ao invés de processos Segundo a IBM, implementações de CICS atuais suportam 300 bilhões de transações diariamente

67 Object Brokers Evolução natural de RPC
Differença: clientes chamam métodos de objetos O broker é responsável por Coordenar a comunicação Transmitir resultados e exceções Usado em sistemas distribuídos heterogêneos com componentes independentes

68 Object brokers - vantagens
Sistemas construídos a partir de componentes desacoplados que interagem entre si → Flexibilidade, manutenibilidade, modificabilidade Particionamento de funcionalidades em componentes independentes → alta distribuição e escalabilidade

69 Message-oriented middleware
Message-oriented middleware: fracamente acoplado (loosely-coupled), tecnologia assíncrona unlike synchronous middleware technologies such as CORBA. Infraestrutura de mensagens desacopla senders e receivers Uso de uma fila de mensagens The sender can send a message to a receiver and know that it will be eventually delivered, even if the network link is down or the receiver is not available.

70

71 Vantagens O sender não precisa de uma resposta a uma mensagem. Ele envia a mensagem e continua seu processo Send-and-forget messaging. O receiver pode demorar alguns minutos para ter uma resposta Enquanto isso o sender pode continuar o trabalho. O sender confia no middleware para enviar a mensagem caso a conexão se perca

72 Desvantagens MOM é uma tecnologia one-to-one.
Um sender envia uma mensagem para uma fila, e um receiver recebe a mensagem Vários problemas não podem ser resolvidos por um estilo 1-1

73 Publish-subscribe Estende mecanismos MOM básicos para suportar estilos de comunicação 1-n, n-1 e n-n Senders e receivers são desacoplados Subscribers podem dinamicamente subscribe e unsubscribe. High-level of abstraction by hiding the complexity of a variety of platforms, networks and low-level process communication.

74

75 Características Naturally supports an asynchronous, many-to-many communication between components in a network. Event based communication between components may act as publishers of information and/or subscribers for information. Publishers publish information through an event, which will be delivered to all (and only) interested subscribers, which expressed their interest in a certain type of information by subscribing to it. This allows improved system performance.

76 Características Publishers não sabem qual subscriber irá receber a informação publicada. Subscribers são indiferentes em relação a qual publisher produz a informação. Não precisam serem executados na mesma máquina (space-decoupled) Publishers e subscribers estão decoupled in time: publishers e subscribers não precisam estar conectados ao mesmo tempo. All this manners of decoupling (synchronization, space and time decoupling) increases scalability and reduces the necessity of coordination, making publish-subscribe middlewares most suited to DRTS.