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, Messageoriented
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 (spacedecoupled)
• 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.