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 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– 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– 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.