Padrões de Interação com o Usuário. Granularidade dos Padrões Padrões estão relacionados a 3...
-
Upload
nathan-nicolau -
Category
Documents
-
view
219 -
download
0
Transcript of Padrões de Interação com o Usuário. Granularidade dos Padrões Padrões estão relacionados a 3...
Padrões de Interação com o Usuário
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
Análise e Projeto OO com UML e Padrões| 2
Problema SoluçãoContextoocorre resolve
Camada de
Negócio
RecapitulandoPadrão Camadas
• Problema– Como organizar os elementos?
• Solução– Organizar pela suas
responsabilidades em comum– Promovendo
• Encapsulamento• Desacoplamento• Coesão
Análise e Projeto OO com UML e Padrões| 3
Camada de
Dados
Camada de
Apresentação
Exemplos de Padrões ArquiteturaisPadrõ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
Análise e Projeto OO com UML e Padrões| 4
Já Vimos
Focaremos o restante desta aula na categoria Interactive Systems
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.
Análise e Projeto OO com UML e Padrões| 5
Visões Dados
Apresentador
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.
Análise e Projeto OO com UML e Padrões| 6
MODEL
VIEW
CONTROLLER
CamadaApresentação
CamadaNegócio
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
Model
MVC Original
• 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
Análise e Projeto OO com UML e Padrões| 8
Controller
View
Em geral para cada elemento visão existe um controlador
associação indireta associação direta
Variações• Duas variações do padrão podem ser identificadas mais comumente:
– Passiva (chamada Passsive View)
– Ativa (chamada Supervising Controller)
Análise e Projeto OO com UML e Padrões| 9
ModelViewDesacopladas
ModelViewSincronizaçãocom Observer
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
Análise e Projeto OO com UML e Padrões| 10
Interação [em Camadas] no MVCDescriçã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.
Análise e Projeto OO com UML e Padrões| 11
PresentationModel Controller
View
BusinessModel
input
output
notificação
notificação
C. ApresentaçãoC. N
egócio
1
2
3
4
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
Model
Dolphin MVP Original
• 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| 13
Presenter
View
Utilizado em diversasaplicações GUI Desktop
Múltiplas visões podem estar associadas ao mesmo presenter
foco do padrão
associação indireta associação direta
Interação [em Camadas]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.
Análise e Projeto OO com UML e Padrões| 14
PresentationModel Presenter
View
BusinessModel
notificação
notificação
C. ApresentaçãoC. N
egócio
1
2
3
4
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
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
• 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
De fato, segundo Fowler, o supervising presenter
segue um estilo de controller.
Model
Passive MVP
• 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
Presenter
View
Utilizado em diversasaplicações Web
foco do padrão
associação indireta associação direta
Model tem papel periférico no padrão
InteraçãoDescriçã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
Presenter
View
BusinessModel
1
23
C. ApresentaçãoC. N
egócio
P. Model 4
Model
Supervising Presenter
• 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
Análise e Projeto OO com UML e Padrões| 19
Presenter
View
Utilizado em diversasaplicações GUI Desktop
foco do padrão
Similar ao Dolphin MVP, porém enfatiza que o Presenter deve ter mais responsabilidades (lógica de apresentação)
associação indireta associação direta
Diagrama SequênciaSupervising Presenter
Análise e Projeto OO com UML e Padrões| 20
:Presenter
:Model:View
:Main
inicializa
inicializa
inicializa
se cadastra
atualiza'processa
atualizanotifica
Observer
modifica visão
se cadastra Usuario
botãonotifica
Observer
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
Análise e Projeto OO com UML e Padrões| 22
Cliente Web(Browser)
Servidor Web
Cliente Web
HTTP
Internet
HTTP
HTTP
A comunicação entre cliente e servidor na web é feita utilizando o protocolo HTTP.
Arquitetura Cliente-Servidor
Análise e Projeto OO com UML e Padrões| 23
Cliente Web
Servidor Web
Cliente Web
requisição HTTPresposta HTTP
(conteúdo HTML)
página HTML
Via get de uma URL
Parametros: - Get (explicitamente) - Post (implicitamente)
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
Model
Passive View [MVC]
• 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
Controller
View
Utilizado em diversasaplicações Web
foco do padrão
associação indireta associação direta
Model tem papel periférico no padrão
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ênciaMVC 2
Análise e Projeto OO com UML e Padrões| 27
:Front Controller :Model
v2 :View
serviço “1”
comando
Browser
serviço “2”
comando
gera
Command
:Helper1
:Helper2
processa
processa
:FabricaHelpers
obter(“1”)
obter(“2”)
htmlHttpResponse
Cliente Servidor
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 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| 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