Padr

1
Padrões de Interação com o Usuário
2
Granularidade dos Padrões

• Padrões estão relacionados a 3 elementos
• 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

resolve
ocorre
Problema
Solução
Contexto
3
RecapitulandoPadrão Camadas

• Problema
• Como organizar os elementos?
• Solução
• Organizar pela suas responsabilidades em comum
• Promovendo
• Encapsulamento
• Desacoplamento
• Coesão

4
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

Já Vimos
Focaremos o restante desta aula na categoria
Interactive Systems
5
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
6
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
Camada Apresentação
CONTROLLER
Camada Negócio
7
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)

8
MVC Original
Controller
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
9
Variações

• Duas variações do padrão podem ser identificadas
  mais comumente
• Passiva (chamada Passsive View)
• Ativa (chamada Supervising Controller)

Desacopladas
Sincronização com Observer
10
VariaçãoModelo 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

11
Interação em Camadas no MVC

• Descrição
• O usuário faz requisições por dados ou ações
  sobre os dados do modelo ao Controller.
• O Controller recebe as requisições e repassa para
  o objeto apropriado do B. Model para atendê-la.
• 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.
• Atualizações no P. Model são avisadas ao View.

output
input
C. Apresentação
notificação
1
4
Controller
3
notificação
2
C. Negócio
12
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.

13
Dolphin MVP Original
Utilizado em diversas aplicações GUI Desktop
Presenter
foco do padrão
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
14
Interação em Camadas

• Descrição
• O usuário faz requisições por dados ou ações
  sobre os dados do modelo à View.
• O Presenter recebe as requisições e repassa para
  o objeto apropriado do B. Model para atendê-la.
• 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.
• Atualizações no P. Model são avisadas ao View.

1
notificação
C. Apresentação
2
4
Presenter
3
notificação
C. Negócio
15
DiscussãoMVC 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

16
Variações MVP e MVC

• Por convenção mostraremos versões ativas e
  passivas para o Padrão MVP
• Passive MVP
• Supervising Presenter
• 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

De fato, segundo Fowler, o supervising presenter
segue um estilo de controller.
17
Passive MVP
Utilizado em diversas aplicações Web
Presenter
Model tem papel periférico no padrão
foco do padrão
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.

18
Interação

• Descrição
• A View faz requisições por dados ou ações sobre
  os dados do modelo.
• O Presenter recebe as requisições e repassa para
  o objeto apropriado do B. Model para atendê-la.
• 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.
• Objetos de modelo na camada de apresentação (P.
  Model) podem ser eventualmente utilizados para
  auxiliar a comunicação entre Presenter e View

C. Apresentação
P. Model
4
1
Presenter
2
3
C. Negócio
19
Supervising Presenter
foco do padrão
Utilizado em diversas aplicações GUI Desktop
Presenter
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)
20
Diagrama SequênciaSupervising Presenter
inicializa
inicializa
View
se cadastra
inicializa
Presenter
se cadastra
Usuario
Observer
Observer
botão
notifica
atualiza'
processa
modifica visão
notifica
atualiza
21
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

22
Arquitetura Cliente-Servidor
HTTP
Servidor Web
A comunicação entre cliente e servidor na web é
feita utilizando o protocolo HTTP.
23
Arquitetura Cliente-Servidor
Via get de uma URL Parametros - Get
(explicitamente) - Post (implicitamente)
requisição HTTP
página HTML
resposta HTTP (conteúdo HTML)
Servidor Web
24
Aplicações Web

• Características
• Requisições simples (http)
• Páginas dinâmicas, sem sincronização com o Model
• Que padrão usar?

25
Passive View MVC
Utilizado em diversas aplicações Web
Controller
Model tem papel periférico no padrão
foco do padrão
associação indireta
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.

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

27
Diagrama SequênciaMVC 2
Cliente
Servidor
Front Controller
Browser
Fabrica Helpers
Command
serviço 1
obter(1)
comando
gera
v2 View
processa
html
HttpResponse
serviço 2
obter(2)
Helper2
comando
processa
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.

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

30
Struts e JSF

• Struts e JSF possuem diversas similaridades
• Views -gt Páginas JSP
• Controller -gt Servlet (provido pelo framework)
• Presentation Model -gt 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 gt Action
• P. Model gt ActionForm
• No JSF, eles são representados em um única classe
• Helper P. Model -gt Managed Bean

31
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