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, etc
Padrão Arquitetural: Partes do Sistema e suas relações
• Visão de alto nível
Idiom: considera o padrão na ling. de programação
• Implementações específicas
Análise e Projeto OO com UML e Padrões| 2
Recapitulando
Padrão Camada
Problema
-
Como organizar os elementos?
Camada de
Apresentação
Solução
-
Organizar pela suas
responsabilidades em comum.
Promovendo
• Encapsulamento
• Acoplamento
• Coesã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 Architect)
Categoria: From Mud to Structure
-
padrões que ajudam a evitar um ‘mar' de componentes.
Ex.: Layers – Divisão em Camadas
Categoria: Distributed systems
-
Já Vimos
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 de interface do usuário
Ex.: MVC: Controla diferentes visões de modelos 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
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 Camandas e MVC
Distinção:
-
Camadas preocupa-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 iteração com o usuário
Um dos padrões mais confundidos para interação com o usuário*
Divide a aplicação em três partes fundamentais
-
„ odel – Representa os dados da aplicação e as regras de negócio
M
View – Representa a interpretação visual do modelo pelo usuário
„
Controller – Responsável por mediar a interação homem-máquina
„
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
Mais utilizado atualmente
em aplicações TUI Desktop
Controller
View
Model
associação indireta
realiza
<<interface>
Observer
associação direta
Responsabilidades:
-
Controller: Receber dados de Usuário (ex.: teclado) e
possui lógica de apresentação.
View: mostrar 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
Interação [em Camadas]
output
View
4
input
notificação
Presentation
Model
1
Controller
3
2
Business
Model
Análise e Projeto OO com UML e Padrões| 9
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 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 tecnologias de
interface gráfica mais modernas.
Qual a diferença do MVP (Model-View-Presenter) ?
Em interfaces GUI mais modernas:
• View é responsável pela entrada
de usuário.
• Presenter apenas media a View e
o Model.
Análise e Projeto OO com UML e Padrões| 10
Dolphin MVP Original
Utilizado em diversas
aplicações GUI Desktop
Presenter
View
foco do
padrão
Model
associação indireta
associação direta
Responsabilidades:
-
Controller: 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| 11
Interação [em Camadas]
1
View
notificação
2
4
Presentation
Model
Controller
3
Business
Model
Análise e Projeto OO com UML e Padrões| 12
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 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 eis a questão?
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| 13
Outras variações
Segundo Martin Fowler tanto as formas originais do MVC e MVP,
encontra-se em desuso.
Segundo Fowler, duas variações do padrão podem ser
identificados mais comumente:
-
Passiva (chamada Passsive View)
View
-
Desacopladas
Model
Ativa (chamada Supervising Controller)
View
Sincronização
com Observer
Model
Análise e Projeto OO com UML e Padrões| 14
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
controller segue um
estilo de Presenter.
Indicações de uso em aplicações GUI
-
Ativa: mais indicadas para aplicações “ricas”
Passiva: Mais indicadas para aplicações stateless
• necessitam de uma menor sincronização Model-View
Análise e Projeto OO com UML e Padrões| 15
Passive MVP
Utilizado em diversas
aplicações Web
Presenter
View
foco do
padrão
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| 16
Interação
Descrição:
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
1.
P. Model 4
1
Presenter
2
Business
Model
Análise e Projeto OO com UML e Padrões| 17
C. Negócio
3
C. Apresentação
View
Supervising Presenter
foco do
padrão
Utilizado em diversas
aplicações GUI Desktop
Presenter
View
Model
associação indireta
Model tem papel
periférico no padrão
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| 18
Diag. Sequencia
Supervising Presenter
:Main
inicializa
inicializa
inicializa
Usuario
botão
:Model
:View
se cadastra
:Controller
se cadastra
Observer
notifica
atualiza'
modifica visão
Observer
processa
notifica
atualiza
Análise e Projeto OO com UML e Padrões| 19
Discussão
Modelo de Negócio e Apresentação
Em muitos casos é necessária a criação de entidades na
camada 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)
De toda maneira, é importante não utilizar este mecanismo
(criação de duas representações) em excesso.
-
Sistemas podem ficar complicados e grandes (“BALOFO”).
BALOFO = Business Object x Logic Object
Análise e Projeto OO com UML e Padrões| 20
Discussão
1
notificação
A facilidade da
estruturação em
camadas permite que
adicionemos facilmente
alguns aspectos de
distribuição.
2
6
Presentation
Model
View
Controller
5
3
Business
Model
4
Business
Model
C. Apresentação C. Integração C. Negócio
Como faríamos para
acessar serviços de uma
Fachada remota?
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/controller.
Análise e Projeto OO com UML e Padrões| 22
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| 23
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| 24
Aplicações Web
Características
-
Requisições simples (http)
Páginas dinâmicas, sem sincronização com o Model
-
Escolha óbvia: Versão passiva do MVC (Passive View)
Análise e Projeto OO com UML e Padrões| 25
Passive View [MVC]
Utilizado em diversas
aplicações Web
Controller
View
foco do
padrão
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| 26
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 especifica à 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| 27
Diag. Seguencia
MVC 2
Cliente
Servidor
:Front
Controller
Browser
:Fabrica
Helpers
:Model
Command
serviço “1”
obter(“1”)
:Helper1
comando
v2 :View
HttpResponse
serviço “2”
gera
processa
html
obter(“1”)
:Helper2
comando
processa
Análise e Projeto OO com UML e Padrões| 28
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| 29
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| 30
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
Helper-Model
-
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| 31