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
Já Vimos
• 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 identificadas mais comumente:
– Passiva (chamada Passsive 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
Variação
Modelo de Negócio e Apresentação
• Em muitos casos é necessária a criação de entidades
na camada de apresentação [modelo de
apresentação] para representar entidades de
negócio
– Ex.: Em aplicações Web, as linguagens de visão nem
sempre conseguem distinguir polimorfismo de tipo
(herança)
• Mas é importante não utilizar este mecanismo
(criação de duas representações) em excesso
Análise e Projeto OO com
UML e Padrões| 10
Interação [em Camadas] no MVC
output
View
4
input
notificação
1
Presentation
Model
Controller
C. Apresentação
3
notificação
2
Business
Model
Análise e Projeto OO com
UML e Padrões| 11
C. Negócio
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 B.
Model para atendê-la.
3. O B. 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 P. 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| 12
Dolphin MVP Original
Utilizado em diversas
aplicações GUI Desktop
Presenter
foco do
padrão
View
Model
associação indireta
associação direta
• Responsabilidades:
– Presenter: media View e Model
– View: realiza toda a interação com o usuário, possui lógica de
apresentação.
– Modelo: representação dos dados e regras de negócio.
Múltiplas visões podem estar associadas ao mesmo presenter
Análise e Projeto OO com
UML e Padrões| 13
Interação [em Camadas]
1
View
notificação
2
4
Presentation
Model
Presenter
C. Apresentação
3
notificação
Business
Model
Análise e Projeto OO com
UML e Padrões| 14
C. Negócio
Descrição:
1. O usuário faz requisições por dados
ou ações sobre os dados do modelo à
View.
2. O Presenter recebe as requisições e
repassa para o objeto apropriado do
B. Model para atendê-la.
3. O B. Model faz as operações sobre os
dados e retorna algum tipo de
informação ao Presenter,que por sua
vez devolve informações para objetos
na camada de apresentação.
4. Atualizações no P. Model são avisadas
ao View.
Discussão
MVC ou não MVC?
• Atualmente, são classificados como padrões MVC (ou variantes) aqueles
padrões que obedecem à seguinte condição:
– Controller é responsável pela entrada de dados do usuário
• Caso a View seja responsável pela entrada do usuário, assumiremos estar
utilizando uma variação MVP
Análise e Projeto OO com
UML e Padrões| 15
Variações MVP e MVC
• Por convenção mostraremos versões ativas e passivas para o
Padrão MVP
– Passive MVP
– Supervising Presenter
De fato, segundo Fowler,
o supervising presenter
segue um estilo de
controller.
• Indicações de uso em aplicações GUI
– Ativa: mais indicadas para aplicações “ricas” (desktop)
– Passiva: Mais indicadas para aplicações com acoplamento fraco entre
a visão e o modelo
• necessitam de uma menor sincronização Model-View
Análise e Projeto OO com
UML e Padrões| 16
Passive MVP
Utilizado em diversas
aplicações Web
Presenter
foco do
padrão
View
Model
associação indireta
Model tem papel
periférico no padrão
associação direta
• Responsabilidades:
– Presenter: Media View e Model
– View: realiza toda a interação com o usuário, possui lógica de
apresentação.
– Modelo: representação dos dados e regras de negócio.
Análise e Projeto OO com
UML e Padrões| 17
Interação
Descrição:
View
P. Model 4
1
Presenter
2
Business
Model
C. Negócio
3
C. Apresentação
1. A View faz requisições por dados ou ações
sobre os dados do modelo.
2. O Presenter recebe as requisições e repassa
para o objeto apropriado do B. Model para
atendê-la.
3. O B. Model faz as operações sobre os dados e
retorna algum tipo de informação ao
Presenter,que por sua vez devolve informações
para a View.
4. Objetos de modelo na camada de apresentação
(P. Model) podem ser eventualmente utilizados
para auxiliar a comunicação entre Presenter e
View
Análise e Projeto OO com
UML e Padrões| 18
Supervising Presenter
foco do
padrão
Utilizado em diversas
aplicações GUI Desktop
Presenter
View
Model
associação indireta
associação direta
• Responsabilidades:
– Presenter: Media View e Model, possui lógica de apresentação
– View: realiza toda a interação com o usuário
– Modelo: representação dos dados e regras de negócio
Similar ao Dolphin MVP, porém enfatiza que o Presenter deve ter
mais responsabilidades (lógica de apresentação)
Análise e Projeto OO com
UML e Padrões| 19
Diagrama Sequência
Supervising Presenter
:Main
inicializa
inicializa
:Model
:View
se cadastra
inicializa
:Presenter
Usuario
se cadastra
Observer
botão
Observer
notifica
atualiza'
modifica visão
processa
notifica
atualiza
Análise e Projeto OO com
UML e Padrões| 20
Exercício
• Dado:
– A arquitetura do sistema modelada no exercício anterior
• Modelar a camada de Apresentação para uma aplicação GUI
Desktop, utilizando MVP.
– Observe que nem todas as interfaces precisam de um supervising
presenter
Análise e Projeto OO com
UML e Padrões| 21
Arquitetura Cliente-Servidor
Cliente Web
(Browser)
Internet
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| 22
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| 23
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| 24
Passive View [MVC]
Utilizado em diversas
aplicações Web
Controller
foco do
padrão
View
Model
associação indireta
Model tem papel
periférico no padrão
associação direta
• Responsabilidades:
– Controller: Media View e Model, possui lógica de apresentação.
– View: realiza toda a interação com o usuário
– Modelo: representação dos dados e regras de negócio.
Análise e Projeto OO com
UML e Padrões| 25
MVC 2
• A aplicação do padrão MVC em Aplicações Corporativas (web)
requer algumas mudanças
– MVC 2 = Passive View+ Front Controller
• Padrão FrontController [Martin Fowler]
– Baseado no padrão Command (mesma estrutura)
– Aplicação específica à camada de Apresentação
– Utiliza um controlador como um ponto inicial para todas requisições.
O controlador é responsável por delegar processamentos, gerenciar
visões, etc.
Análise e Projeto OO com
UML e Padrões| 26
Diagrama Sequência
MVC 2
Cliente
:Front
Controller
Browser
Servidor
:Fabrica
Helpers
:Model
Command
serviço “1”
obter(“1”)
:Helper1
comando
v2 :View
HttpResponse
serviço “2”
gera
processa
html
obter(“2”)
:Helper2
comando
processa
Análise e Projeto OO com
UML e Padrões| 27
Exercício
• Dado:
– A arquitetura do sistema modelada no exercício anterior
• Modelar a camada de Apresentação para uma aplicação Web,
utilizando MVC 2.
Análise e Projeto OO com
UML e Padrões| 28
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| 29
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
• Principais diferenças existem apenas na definição do HelperModel
– No Struts, eles são representados por duas classes
• Helper –> Action
• P. Model –> ActionForm
– No JSF, eles são representados em um única classe
• Helper + P. Model -> Managed Bean
Análise e Projeto OO com
UML e Padrões| 30
No curso ...
• Vamos usar o Play
– Baseado no princípio “Convention over configuration” (ou “coding by
convention”)
– Não atrelado ao J2EE
– Será apresentado em detalhes na aula de monitoria
Análise e Projeto OO com
UML e Padrões| 31