Post on 18-Apr-2015
Padrões ArquiteturaisLayers, Façade, Repositório,
Eventos, MVCNazareno Andrade
(baseado em Hyggo Almeida e Jacques Sauvé)
O que vimos na última aula?
Arquitetura de software O que é? Para que serve? Como documentar?
O que é padrão arquitetural
2Padrão Layers (Camadas)
O que veremos agora?
Padrões arquiteturais
3Padrão Layers (Camadas)
Padrão Layers (Camadas)
Problema Como projetar um sistema cuja característica
principal é uma mistura de funcionalidades de alto nível e de baixo nível...
... onde a parte de baixo nível está frequentemente perto do hardware...
...e a parte de mais alto nível está frequentemente perto do usuário?
O fluxo de comunicação tipicamente consiste de pedidos fluindo do alto nível para o baixo nível E as respostas seguem a direção contrária
4Padrão Layers (Camadas)
Padrão Layers (Camadas)
Problema
5Padrão Layers (Camadas)
Interface
Relatório
Armazenamento
Negócio
Contextos das classes
CAOS!!!
Solução Decomposição do sistema: partições
e camadas Uma camada é um subsistema que adiciona valor a
subsistemas de menor nível de abstração Uma partição é um subsistema "paralelo" a outros subsistemas
6Padrão Layers (Camadas)
Camada n
Camada 2
Camada 1
Partição n_1 Partição n_2 Partição n_3 Partição n_4
Partição 2_1 Partição 2_2 Partição 2_3 Partição 2_4
Partição 1_1 Partição 1_2
Padrão Layers (Camadas)
Solução
7Padrão Layers (Camadas)
Apresentação
Lógica de Negócio/Domínio
Fonte de dados/Armazenamento
InterfaceGráfica
InterfaceTexto
Vendas Compras
Acesso a SGBD Acesso a XML
Conseqüências Vantagens
Reúso de camadas Devido ao bom encapsulamento provido pelo uso de
interfaces Suporte para a padronização
Certas camadas importantes podem ser padronizadas ex. API POSIX
Permite usar implementações de vários fornecedores Dependências são mantidas locais
Alterações de implementações que não alterem as interfaces não saem da camada
Intercambiabilidade Implementações podem ser trocadas
8Padrão Layers (Camadas)
Conseqüências Desvantagens
Cascatas de mudanças de comportamento Sob certas situações, alterações de
comportamento numa camada podem fazer cascata ex. alteração de um enlace de 10 Mbps para
1Gbps pode causar gargalos nas camadas superiores
Menor eficiência Camadas adicionam overhead Um "mar monolítico de objetos" pode ser mais
eficiente Porém, mais acoplado 9Padrão Layers (Camadas)
Como implementar?
Implementação1. Defina o critério de abstração para agrupar tarefas
em camadas Pode ser a distância conceitual do "chão“
ou outro critério dependente do domínio Pode ser baseado na complexidade conceitual Uma forma comum de criar camadas
Nas camadas inferiores, usa a distância do hardware Nas camadas superiores, usa a complexidade conceitual Exemplo de camadas:
Elementos visíveis ao usuário Módulos específicos da aplicação Nível de serviços comuns Nível de interface ao sistema operacional (ou outra
plataforma como uma JVM) O sistema operacional em si que pode estar estuturado em
camadas 11Padrão Layers (Camadas)
2. Determine o número de níveis de abstração (baseado no critério anterior)
Cada nível de abstração corresponde a uma camada
Às vezes não é simples decidir se deve haver uma quebra de uma
Camadas demais podem afetar o desempenho
Camadas de menos comprometem a estrutura
12Padrão Layers (Camadas)
3. Dê um nome e atribua tarefas a cada camada
Para a camada de cima, a tarefa é a tarefa global do sistema, do ponto de vista do usuário
Outras camadas existem para ajudar as camadas de cima
Pode-se proceder de baixo para cima, mas isso requer bastante experiência
Melhor proceder de cima para baixo
13Padrão Layers (Camadas)
4. Especifique os serviços O princípio básico é de separar as
camadas uma das outras Nenhum módulo abrange duas
camadas Tente manter mais riqueza (semântica)
acima e menos abaixo Isso ajuda a prover bons serviços de
alto nível para o programador "em cima”
"pirâmide invertida de reuso"
14Padrão Layers (Camadas)
5. Refine as camadas Itere nas 4 etapas anteriores Dificilmente se acerta o critério de
abstração de primeira, antes de ver que camadas estão surgindo
Quando as camadas surgem, pode-se verificar se o critério de abstração está ok
15Padrão Layers (Camadas)
6. Especifique uma interface para cada camada
Black box (preferível) A camada J nada sabe sobre a camada J-
1 e usa uma interface "plana" para acessá-la
Pode usar o padrão Façade para organizar a interface
White box A camada J conhece detalhes da
estrutura interna da camada J-1 e usa esse conhecimento ao acessar a camada
Por exemplo, conhece vários objetos ou componentes internos da camada 16Padrão Layers (Camadas)
7. Estruture as camadas individuais Quebre a camada em subsistemas
(partições) menores se ela for complexa
17Padrão Layers (Camadas)
8. Especifique a comunicação entre camadas
Normalmente, usa-se o modelo “push” A camada J passa a informação
necessária para a camada J-1 ao chamá-la
O modelo “pull” pode ser usado mas cria mais acoplamento entre camadas
Uma discussão será feita no padrão Observer
18Padrão Layers (Camadas)
9. Desacoplar camadas adjacentes Evite situações em que a camada de baixo sabe algo
sobre seus clientes (camada acima) Acoplamento unidirecional é
preferível (push) A grande técnica de desacoplamento é usar uma
interface
19Padrão Layers (Camadas)
10. Projete uma estratégia de tratamento de erros O esforço de programação e overhead podem
ser grandes para tratar erros numa arquitetura em camadas
Um erro pode ser tratado na camada onde foi descoberto ou numa camada superior
No segundo caso, deve haver mapeamento para tornar o erro semanticamente reconhecível pela camada de cima
Exemplo: Não apresente ao usuário uma mensagem dizendo "Exceção IllegalArgumentException em DoItNow()"
Tente tratar erros na camada mais baixa possível
Isso simplifica todas as camadas superiores que não sabem nem devem saber do erro
"O componente mais rápido, mais robusto e mais barato é aquele que não está aí"
20Padrão Layers (Camadas)
Arquitetura n-camadas
Inicialmente... Arquitetura centralizada
Dominantes até a década de 80 como arquitetura corporativa
Problema básico: interface não amigável
21Padrão Layers (Camadas)
2-camadas
Arquitetura em 2 camadas Melhor aproveitar os PCs da empresa Interfaces gráficas amigáveis Integrar o desktop aos dados corporativos
22Padrão Layers (Camadas)
Arquitetura em 2 camadas
23Padrão Layers (Camadas)
3-camadas
Arquitetura em 3 camadas Motivação
Arquitetura em 2 camadas possui vários problemas: Múltiplas conexões com o banco de dados Manutenção (mudanças forçam instalações
nos clientes)
24Padrão Layers (Camadas)
Arquitetura em 3 camadas Observe que as camadas são lógicas...
25Padrão Layers (Camadas)
Arquitetura em 3/4 camadas (web-based) Instalação inicial nos clientes é cara Manutenção na camada de apresentação
requer instalações Instalações do software fora do seu controle
administrativo são complicadas Parceiros Fornecedores Clientes distribuídos Internet
26Padrão Layers (Camadas)
Arquitetura em 3/4 camadas (web-based) Utilizou-se então o browser como cliente
universal
27Padrão Layers (Camadas)
Exemplos (arquitetura em n camadas) Arquitetura em n camadas
Como suportar clientes leves??? Como suportar componentização? Como facilitar a vida do desenvolvedor para
gerenciar (transações, pooling, persistência de dados...)
28Padrão Layers (Camadas)
Exemplos (arquitetura em n camadas)
29Padrão Layers (Camadas)
middleware
Padrão arquitetural E de projeto de baixo nível:
Façade
(Fachada)
31
FaçadeA arquitetura de um sistema dividido em camadas, possui
dependências entre classes de camadas adjacentes
Armazenamento
Negócio
Apresentação
Pequenas mudanças locais em classes de uma camada...
Resulta em mudanças em
outras camadas!!!
32
Problema: Como garantir baixo acoplamento entre as camadas... sabendo que é inevitável o relacionamento entre classes de camadas diferentes???
Resposta: Padrão Façade
Intenção Definir um ponto único de acesso a um subsistema para
isolá-lo e garantir baixo acoplamento com classes externas.
Aplicabilidade Fornecer uma interface simples a um sistema complexo Estruturar melhor as camadas do sistema Diminui dependências entre clientes e classes de
implementação
33
FaçadeDefine-se uma fachada de acesso a cada camada
Armazenamento
Negócio
Apresentação
Fachada
FachadaAlterações
locais alteram a fachada!
Classes “cliente”
permanecem inalteradas!!!
34
Estrutura de classes antes da aplicação do padrão
Matrícula
Relatório
GerenciadorImpressãoInterfaceGráfica
efetuarMatricula()
gerarRelatorio()
Camada de negócio
Imprimir()
35
Após a aplicação do padrão
Matrícula
Relatório
GerenciadorImpressão
InterfaceGráfica
efetuar
gerar
Camada de negócio
imprimirFachadaSistema
gerarRelatório()imprimirRelatorio()efetuarMatricula()
VerificadorAdicional
Agora... antes de efetuar a matrícula!!! Preciso verificar!!!!
verificar
boolean efetuarMatricula(){ return verificar()&&efetuar();}
36
Conseqüências Isola os clientes dos componentes internos do sistema Promove baixo acoplamento entre o subsistema e os
clientes Não impede clientes de utilizarem componentes
diretamente, caso seja necessário
37
Padrão Repositório (compartilhado)
Problema Como fazer com que várias aplicações-cliente
possam interoperar? Integridade, escalabilidade (novos clientes,
novos dados) Aplicações são independentes “Pontes” entre aplicações são “inviáveis”
38
Padrão Repositório
Solução Padrão Repositório
Centrado em dados Ponto “central” de acesso pelas várias
aplicações Interoperabilidade alcançada através da
mudança de estado do repositório (atualização dos dados)
39
Padrão Repositório
Solução
Dados compartilhados
Cliente 1
Cliente 2Cliente 3
Cliente n
Estado atualconsistente
Clientes operamsobre os dados
40
Padrão Repositório
Exemplo: banco de dados tradicional
Dados compartilhados
Cliente 1
Cliente 2Cliente 3
Cliente n
Transações
Gatilhos(triggers)
41
Consequências Novas aplicações-cliente podem ser
adicionadas à arquitetura sem alteração nas demais Desde que o modelo de repositório não seja
alterado significativamente Tem-se sempre um estado consistente no
repositório, independente da execução das aplicações
Desvantagens Ponto central de falha Gargalo Difícil compreensão Necessita de mecanismo de sincronização
Arquitetura baseada em eventos (padrão)
42
43
Arquitetura baseada em eventos
Problema Como criar uma relação 1-para-muitos entre
módulos da arquitetura mantendo o baixo acoplamento entre eles? Cada módulo está interessado apenas na
mudança de estado do outro
“Módulo A, B, C e D precisam executar uma dada rotina quando o módulo X alcançar um determinado estado”
44
ProblemaUma possível solução seria a ligação entre os
componentes...
Muito acoplada, pouco escalável...
Arquitetura baseada em eventos
A
imprimir
X
a.imprimir()
45
Arquitetura baseada em eventos
Solução Arquitetura baseada em eventos
Produtores (anunciantes) e consumidores (interessados) de eventos
Consumidores se registram nos Produtores Produtores notificam consumidores registrados
46
Arquitetura baseada em eventos
Solução Produtores e consumidores são independentes Execução via procedimentos disparados quando ocorrem
mudanças de estado Escalabilidade no número de interessados
A X
ProdutorConsumidor
interessado(“relatorioOK”)
relatorioOKRelatório
OK
imprimir()
47
Arquitetura baseada em eventos
Exemplo Interface gráfica
menuDown
onMouseOver
onMouseClick
onMousePressed
onMouseReleased
onSelected
onKeyDown
onKeyUp
48
Arquitetura baseada em eventos
Conseqüências Módulos desacoplados Novos componentes interessados podem ser
facilmente adicionados à arquitetura Escalabilidade
Desvantagem: Caso haja novos eventos, interessados
devem ser alterados!!!
49
Arquitetura baseada em eventosTestando seus conhecimentos
Como garantir, no nível de projeto e implementação, a independência entre os interessados e os anunciantes dos eventos? Esta resposta será dada quando o padrão
Observer for apresentado, mas alguém tem alguma sugestão?
50Padrão MVC
Padrão MVC
Problema Interfaces com o usuário são sensíveis a mudanças:
A aplicação pode ter que ser implementada em outra plataforma.
Diferentes requisitos de acordo com o usuário: Um digitador pode preferir uma interface onde tudo
pode ser feito através do teclado e visualizado como texto.
Um gerente pode preferir uma interface com botões, para utilizar o mouse
Se o código da interface gráfica é muito acoplado ao código da aplicação, o desenvolvimento pode se tornar muito caro e difícil.
51Padrão MVC
Padrão MVC
Solução Padrão MVC Separar dados ou lógica de negócios (Model) da interface
do usuário (View) e do fluxo da aplicação (Control) Uma mesma lógica de negócios possa ser acessada e
visualizada através de várias interfaces. O modelo (Model) não sabe quantas nem quais interfaces
com o usuário estão exibindo seu estado.
52Padrão MVC
Padrão MVC
Solução Com as diversas possibilidades de interfaces que
conhecemos hoje, MVC é uma ferramenta indispensável
53Padrão MVC
Padrão MVC
Implementação Passo 1
Isolar a lógica de negócio do sistema As classes de negócio não devem “conhecer” nada
relacionado à(s) interface(s) de exibição do seu estado
54Padrão MVC
Padrão MVC
Implementação Passo 2
Se as classes de negócio não conhecem a interface gráfica... como fazer para que o modelo informe mudanças em seu estado para as diversas interfaces?
55Padrão MVC
Padrão MVC
Implementação Passo 2
Arquitetura baseada em eventos!!! As telas interessadas em exibir os eventos do modelo,
cadastram-se nos controladores Além disso, controladores são responsáveis por
repassar as requisições das visões para o modelo. Implementar os controladores de acesso ao modelo
56Padrão MVC
Padrão MVC
Implementação Passo 3
Implementar as visões que, através do controlador, acessarão o estado do modelo
View
Controller
Model
57Padrão MVC
Padrão MVC
Responsabilidades Modelo (Model)
Funcionalidade principal da aplicação Registrar controllers e views Notificar controllers e views registrados de alterações
Visão (View) Criar e inicializar o controlador associado Exibir informação ao usuário Implementar o procedimento de atualização Recuperar dados do modelo
58Padrão MVC
Padrão MVC
Responsabilidades Controlador (Controller)
Receber a entrada de dados/requisições do usuário Transformar as requisições dos usuários em requisições
ao modelo Implementar o procedimento de atualização (se
necessário)
59Padrão MVC
Padrão MVC
Conseqüências Vantagens
Suporte a múltiplas interfaces de usuário utilizando o mesmo modelo de negócio
Novas interfaces podem ser adicionadas sem alteração do modelo
Alterações no estado do modelo são refletidas em todas as visões
60Padrão MVC
Padrão MVC
Conseqüências Desvantagens
Com muitas visões e modelo atualizado com muita freqüência, o desempenho do sistema pode ser afetado.
Se o padrão não for bem implementado, pode-se ter casos como o envio de atualizações para visões que estão minimizadas ou fora do campo de visão do usuário.
Ineficiência: uma visão pode ter que fazer inúmeras chamadas ao modelo, dependendo de sua interface.
61Padrão MVC
Padrão MVC
Quando usar? Necessidade de várias interfaces com o usuário
Web, Swing
Necessidade de várias visões dos dados Planilhas, Tabelas, Gráficos
Mudanças nos dados devem ser refletidas na interface
62Padrão MVC
Padrão MVC
Em Java, vários frameworks disponíveis... Apache Struts Apache Cocoon Spring MVC WebWork JavaServer Faces Grails
O que vimos?
Padrão Layers (Camadas)
Padrão Façade
Padrão Repositório
Arquitetura baseada em eventos
MVC
63
O que veremos na próxima aula?
Estudos de caso de arquiteturas
64Padrão Layers (Camadas)
Dúvidas?
?65Padrão Layers (Camadas)