Padrões de Arquitetura

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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)

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.

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

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.

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.

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

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.

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

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

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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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.

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.