padr es de arquitetura n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Padrões de Arquitetura PowerPoint Presentation
Download Presentation
Padrões de Arquitetura

Loading in 2 Seconds...

play fullscreen
1 / 76

Padrões de Arquitetura - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Padrões de Arquitetura' - gelsey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
padr es e estilos
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
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
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
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
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
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 camadas1
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
desvantagens de camadas
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
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
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 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
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
three tier architectures
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
three tier architectures1
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
three tier architectures2
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
n tier architectures multi tier
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
existe o estilo em camadas
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.
pipe and filters
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
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
caracter sticas1
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 sticas2
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
Topologias
  • Um arranjo linear de pipesandfilters é chamado de pipeline
  • Boundedpipes
    • a quantidade de dados no pipe é limitada
  • Typedpipes
    • dados fortemente tipados no pipe
vantagens
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
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
compilador
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
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
vantagens1
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
desvantagens1
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
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.
cliente servidor1
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
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
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
Centralizado
  • Um subsistema tem controle geral para iniciar e parar todos subsistemas
  • Tipos:
    • Call-return
    • Controlador
microkernel
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
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
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 microkernel1
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
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
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
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
DistributedMicrokernel
  • Uma variante do microkernel com benefícios:
    • Escalabilidade
    • Confiabilidade, através de availability e faulttolerance.
  • 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
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
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
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 sticas1
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 - 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
  • Controlcomponent – usa os dados do blackboard para:
    • Monitorar as mudanças
    • Decidir as próximas ações
exemplos
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
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
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
RemoteProcedureCall
  • 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 - 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
TransactionProcessingMonitors
  • 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 onetierarchitectures
tp monitors aplica es
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 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
ObjectBrokers
  • 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
Objectbrokers - 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-orientedmiddleware
  • Message-oriented middleware: fracamenteacoplado (loosely-coupled), tecnologiaassíncrona
    • unlike synchronous middleware technologies such as CORBA.
  • Infraestrutura de mensagensdesacoplasenders e receivers
    • Uso de umafila 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.
vantagens2
Vantagens
  • O sender nãoprecisa de umaresposta a umamensagem. Eleenvia a mensagem e continua seuprocesso
    • Send-and-forget messaging.
  • O receiver podedemoraralgunsminutosparaterumaresposta
    • Enquantoisso o sender podecontinuar o trabalho.
  • O sender confia no middleware paraenviar a mensagemcaso a conexão se perca
desvantagens2
Desvantagens
  • MOM é umatecnologia one-to-one.
  • Um sender enviaumamensagemparaumafila, e um receiver recebe a mensagem
  • Váriosproblemasnãopodem ser resolvidospor um estilo 1-1
publish subscribe
Publish-subscribe
  • Estendemecanismos MOM básicosparasuportarestilos de comunicação 1-n, n-1 e n-n
  • Senders e receivers sãodesacoplados
  • Subscribers podemdinamicamentesubscribee unsubscribe.
  • High-level of abstraction by hiding the complexity of a variety of platforms, networks and low-level process communication.
caracter sticas3
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 sticas4
Características
  • Publishers nãosabemqualsubscriber iráreceber a informaçãopublicada.
  • Subscribers sãoindiferentesemrelação a qualpublisher produz a informação.
    • Nãoprecisamseremexecutadosnamesmamáquina(space-decoupled)
  • Publishers e subscribers estãodecoupled in time: publishers e subscribers nãoprecisamestarconectadosaomesmo 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.