Padrões Arquiteturais Layers, Façade, Repositório, Eventos, MVC Nazareno 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 Padrão Layers (Camadas)

O que veremos agora? Padrões arquiteturais Padrã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 Padrão Layers (Camadas)

Padrão Layers (Camadas) Problema CAOS!!! Contextos das classes Interface Relatório Armazenamento Negócio Padrão Layers (Camadas)

Decomposição do sistema: partições e camadas 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 Camada n Partição n_1 Partição n_2 Partição n_3 Partição n_4 Camada 2 Partição 2_1 Partição 2_2 Partição 2_3 Partição 2_4 Camada 1 Partição 1_1 Partição 1_2 Padrão Layers (Camadas)

Padrão Layers (Camadas) Solução Apresentação Interface Gráfica Interface Texto Lógica de Negócio/Domínio Vendas Compras Fonte de dados/Armazenamento Acesso a SGBD Acesso a XML Padrão Layers (Camadas)

Conseqüências Vantagens Reúso de camadas Suporte para a padronização 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 Padrão Layers (Camadas)

Desvantagens Cascatas de mudanças de comportamento 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 Padrão Layers (Camadas)

Como implementar?

Implementação 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 Exemplo com TCP/IP vs. exemplo com simulador de futebol Padrão Layers (Camadas)

Cada nível de abstração corresponde a uma camada 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 Padrã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 Padrã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" Padrã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 Padrã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 Padrão Layers (Camadas)

7. Estruture as camadas individuais Quebre a camada em subsistemas (partições) menores se ela for complexa Padrã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 Padrão Layers (Camadas)

Acoplamento unidirecional é preferível (push) 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 Padrã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í" Padrã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 Padrã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 Padrão Layers (Camadas)

Arquitetura em 2 camadas Padrã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) Padrão Layers (Camadas)

Arquitetura em 3 camadas Observe que as camadas são lógicas... Padrã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 Padrão Layers (Camadas)

Arquitetura em 3/4 camadas (web-based) Utilizou-se então o browser como cliente universal Padrã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...) Padrão Layers (Camadas)

Exemplos (arquitetura em n camadas) middleware Padrão Layers (Camadas)

Padrão arquitetural E de projeto de baixo nível: Façade (Fachada)

Façade A arquitetura de um sistema dividido em camadas, possui dependências entre classes de camadas adjacentes Apresentação Resulta em mudanças em outras camadas!!! Negócio Pequenas mudanças locais em classes de uma camada... Armazenamento

Problema: Como garantir baixo acoplamento entre as camadas 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

Façade Define-se uma fachada de acesso a cada camada Apresentação Classes “cliente” permanecem inalteradas!!! Fachada Negócio Fachada Alterações locais alteram a fachada! Armazenamento

GerenciadorImpressão Estrutura de classes antes da aplicação do padrão Camada de negócio Relatório gerarRelatorio() InterfaceGráfica Imprimir() GerenciadorImpressão efetuarMatricula() Matrícula

Após a aplicação do padrão Camada de negócio InterfaceGráfica Relatório gerar FachadaSistema imprimir verificar GerenciadorImpressão gerarRelatório() imprimirRelatorio() efetuarMatricula() VerificadorAdicional Agora... antes de efetuar a matrícula!!! Preciso verificar!!!! efetuar Matrícula boolean efetuarMatricula(){ return verificar()&&efetuar(); }

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

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”

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)

Padrão Repositório Solução Clientes operam sobre os dados Cliente 2 Cliente n Dados compartilhados Estado atual consistente

Padrão Repositório Exemplo: banco de dados tradicional Cliente 2 Gatilhos (triggers) Transações Cliente n Dados compartilhados

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)

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”

Arquitetura baseada em eventos Problema Uma possível solução seria a ligação entre os componentes... Muito acoplada, pouco escalável... imprimir a.imprimir() A X

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

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 imprimir() A interessado(“relatorioOK”) X relatorioOK Consumidor Produtor Relatório OK

Arquitetura baseada em eventos Exemplo Interface gráfica onKeyDown onMouseOver onKeyUp onMouseReleased onMouseClick menuDown onMousePressed onSelected

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!!!

Arquitetura baseada em eventos Testando 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?

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. Padrã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. Padrão MVC

Padrão MVC Solução Com as diversas possibilidades de interfaces que conhecemos hoje, MVC é uma ferramenta indispensável Padrã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 Padrã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? Padrã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 Padrão MVC

Padrão MVC Implementação Passo 3 Implementar as visões que, através do controlador, acessarão o estado do modelo Model Controller View Padrão MVC

Padrão MVC Responsabilidades Modelo (Model) Visão (View) 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 Padrã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) Padrã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 Padrã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. Padrão MVC

Padrão MVC Quando usar? Web, Swing Planilhas, Tabelas, Gráficos 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 Padrão MVC

Padrão MVC Em Java, vários frameworks disponíveis... Apache Struts Apache Cocoon Spring MVC WebWork JavaServer Faces Grails Padrão MVC

O que vimos? Padrão Layers (Camadas) Padrão Façade Padrão Repositório Arquitetura baseada em eventos MVC

O que veremos na próxima aula? Estudos de caso de arquiteturas Padrão Layers (Camadas)

Dúvidas? ? Padrão Layers (Camadas)