Padrões de Arquitetura

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 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 (lowerlevels) • Detalhes são escondidos de acordo com a conveniência, aumentando separationofconcerns • 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 • 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

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

16. Two-tierarchitectures • 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

18. Three-tierarchitectures • 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-tierarchitectures

20. Three-tierarchitectures • 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-tierarchitectures • 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-tierArchitectures (multi-tier) • De forma genérica, n-tierarchitectures 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

25. Existe o estiloemcamadas? • 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 • Filterslê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 • Filterspodem 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 pipesandfilters é chamado de pipeline • Boundedpipes • a quantidade de dados no pipe é limitada • Typedpipes • 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 • Inadequadoparaaplicaçõesinterativas

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

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, printservers • 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

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.