Padrões de Interação com o
Usuário
Granularidade dos Padrões
• Padrões estão relacionados a 3 elementos:
Contexto
ocorre
Problema
resolve
Solução
• Problemas e Soluções podem ser observados em
diferentes níveis de granularidade
– Padrão de Projeto: Classes, Objetos e suas relações
• Relações: associações, herança, dependência, ...
– Padrão Arquitetural: Partes do Sistema e suas relações
• Visão de alto nível
– Idiom: considera o padrão na linguagem de programação
• Implementações específicas
Análise e Projeto OO com
UML e Padrões| 2
Recapitulando
Padrão Camadas
• Problema
– Como organizar os elementos?
• Solução
– Organizar pela suas
responsabilidades em comum
– Promovendo
• Encapsulamento
• Desacoplamento
• Coesão
Camada de
Apresentação
Camada de
Negócio
Camada de
Dados
Análise e Projeto OO com
UML e Padrões| 3
Exemplos de Padrões Arquiteturais
Padrões POSA (Pattern Oriented Software Architecture)
• Categoria: From Mud to Structure
– ajuda a evitar a proliferação exacerbada de componentes
– Ex.: Layers – Divisão em Camadas
• Categoria: Distributed systems
– Suporte à estruturação de sistemas com componentes distribuídos
– Ex.: Broker – Separa serviços remotos de forma transparente
• Frameworks (Implementações): Corba, COM, etc.
• Categoria: Interactive systems
– Facilidade de adaptação da interface do usuário
– Ex.: MVC: Controla diferentes visões da modelagem do sistema
Focaremos o restante desta aula na categoria Interactive Systems
Análise e Projeto OO com
UML e Padrões| 4
Padrões de
Interação com o Usuário
• O objetivo é promover duas separações:
– Separação Visão-Modelo
• Boa Prática de projeto de software!
“Separa as classes que descrevem o modelo e a lógica de negócios das
classes que realizam a interface com o usuário, permitindo que
ambas evoluam de forma independente.”
– Separação Visão-Controle (Visão-Apresentador)
• Separa a responsabilidade, facilita testes e manutenção
• Mais difícil de ser plenamente implementada em algumas
tecnologias.
– Em algumas GUI, regras de controle são associadas à visão.
Apresentador
Visões
Dados
Análise e Projeto OO com
UML e Padrões| 5
Padrões Camadas e MVC
• Distinção:
– Camadas preocupam-se principalmente com a divisão da estrutura
– MVC preocupa-se com interação entre partes do sistema.
• MVC foi criado, e continua largamente sendo utilizado, para definir
as interações da camada de apresentação.
VIEW
CONTROLLER
MODEL
Camada
Apresentação
Camada
Negócio
Análise e Projeto OO com
UML e Padrões| 6
Padrão MVC
• MVC: Model-View-Controller
– Um dos padrões mais conhecidos para interação com o usuário
• Divide a aplicação em três partes fundamentais
– Model – Representa os dados da aplicação e as regras de negócio
– View – Representa a interpretação visual do modelo pelo usuário
– Controller - Responsável por mediar a interação usuário-aplicação
• O padrão foi originalmente criado em 1978
– Desde então diversas variações foram criadas para acompanhar novas
demandas na iteração com o usuário (UI)
Análise e Projeto OO com
UML e Padrões| 7
MVC Original
Controller
View
Model
associação indireta
associação direta
• Responsabilidades:
– Controller: Recebe dados de Usuário (ex.: teclado) e possui lógica
de apresentação
– View: mostra projeções (saída) sobre os dados do modelo
– Modelo: representação dos dados e regras de negócio
Em geral para cada elemento visão existe um controlador
Análise e Projeto OO com
UML e Padrões| 8
Variações
• Duas variações do padrão podem ser identificados mais comumente:
– Passiva (chamada Passive View)
View
Desacopladas
Model
– Ativa (chamada Supervising Controller)
View
Model
Sincronização
com Observer
Análise e Projeto OO com UML e Padrões| 9
Interação [em Camadas] no MVC
output
View
input
4 notificação
Presentation
Model
3
1
Controller
2
Business
Model
Análise e Projeto OO com
UML e Padrões| 10
C. Negócio
notificação
C. Apresentação
Descrição:
1. O usuário faz requisições por dados ou
ações sobre os dados do modelo ao
Controller.
2. O Controller recebe as requisições e
repassa para o objeto apropriado do
Model para atendê-la.
3. O Model faz as operações sobre os
dados e retorna algum tipo de
informação ao Controller,que por sua
vez devolve informações para objetos
na camada de apresentação.
4. Atualizações no Model são avisadas ao
View.
Variação MVP
• Outros padrões (como o MVP) foram criados para resolver as
insuficiências do MVC quando aplicado a algumas tecnologias de interface
gráfica
• Qual a diferença do MVP (Model-View-Presenter)?
•
Em algumas GUI:
– View é responsável pela entrada de dados do usuário
– Presenter apenas media a View e o Model.
Análise e Projeto OO com
UML e Padrões| 11
Arquitetura Cliente-Servidor
Cliente Web
(Browser)
Internet
HTTP
Servidor Web
Cliente Web
A comunicação entre cliente e servidor na web é feita
utilizando o protocolo HTTP.
Análise e Projeto OO com
UML e Padrões| 12
Arquitetura Cliente-Servidor
Via get de uma URL
Cliente Web
página
HTML
Parametros:
- Get (explicitamente)
- Post (implicitamente)
Servidor Web
Cliente Web
Análise e Projeto OO com
UML e Padrões| 13
Aplicações Web
• Características
– Requisições simples (http)
– Páginas dinâmicas, sem sincronização com o Model
– Que padrão usar?
Análise e Projeto OO com
UML e Padrões| 14
Frameworks MVC
• Existem Diversos frameworks que auxiliam o desenvolvimento
Web de acordo com o padrão MVC
• Os frameworks Java mais conhecidos são:
– JSF
– Struts
– Spring MVC
– Todos provêem implementações para o Front Controller e indicam
formas para a representação dos demais papeis (View e Model)
• Realização de interfaces do Framework
• Arquivos de Configuração
Análise e Projeto OO com
UML e Padrões| 15
Struts e JSF
• Struts e JSF possuem diversas similaridades
– Views -> Páginas JSP
– Controller -> Servlet (provido pelo framework)
– Presentation Model -> Objetos Java, cujos atributos representam
campos de formulários
Análise e Projeto OO com
UML e Padrões| 16