Aula8 padraoMVC

Prévia do material em texto

*
*
Padrões de Interação com o Usuário
*
Título da Apresentação | *
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| *
Problema
Solução
Contexto
ocorre
resolve
*
Título da Apresentação | *
Recapitulando
Padrã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| *
*
Título da Apresentação | *
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
Análise e Projeto OO com UML e Padrões| *
Já Vimos
Focaremos o restante desta aula na categoria Interactive Systems
*
Título da Apresentação | *
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| *
Visões
Dados
Apresentador
*
*
CIn.ufpe.br
*
Controlador
Controller
*
Título da Apresentação | *
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| *
VIEW
CONTROLLER
Camada
Apresentação
Camada
Negócio
*
Título da Apresentação | *
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| *
CIn.ufpe.br
*
MVC
View
Model
Controller
Input
CIn.ufpe.br
*
View
Model
Controller
Input
MVC (Passive View)
CIn.ufpe.br
*
CIn.ufpe.br
*
MVC (Supervising Controller)
View
Model
Controller
Input
CIn.ufpe.br
*
CIn.ufpe.br
*
MVP: Model-View-Presenter
View realiza toda a interação com o usuário, possui lógica de apresentação
Presenter media View e Model
Model engloba representação dos dados e regras de negócio
 
CIn.ufpe.br
*
MVP
View
Model
Presenter
Input
CIn.ufpe.br
*
MVP (Passive View)
View
Model
Presenter
Input
CIn.ufpe.br
*
CIn.ufpe.br
*
MVP (Supervising Presenter)
View
Model
Presenter
Input
CIn.ufpe.br
*
*
Título da Apresentação | *
Diagrama Sequência
Supervising Presenter
Análise e Projeto OO com UML e Padrões| *
:Presenter
:View
inicializa
inicializa
inicializa
se cadastra
atualiza'
processa
atualiza
notifica
Observer
modifica visão
se cadastra
 Usuario
botão
notifica
Observer
CIn.ufpe.br
*
MVC x MVP
Qual as principais diferenças?
Input - Quem é responsável por tratar os eventos
	 MVC: Controller
	 MVP: View
Multiplicidade dos relacionamentos. Usualmente:
View [1] - [1] Controller
View [n] - [1] Presenter 
*
Título da Apresentação | *
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| *
*
Título da Apresentação | *
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| *
*
Título da Apresentaçã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| *
*
Título da Apresentação | *
Diagrama Sequência
MVC 2
Análise e Projeto OO com UML e Padrões| *
:Front 
Controller
v2 :View
serviço “1”
comando
Browser
serviço “2”
comando
gera
Command
:Helper2
processa
processa
:Fabrica
Helpers
obter(“1”)
obter(“2”)
html
HttpResponse
Cliente
Servidor
*
Título da Apresentação | *
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| *
*
Partes envolvem múltiplas classes. Às vezes não queremos nos ater às relações entre as classes, mas entre as partes.
As partes podem ser concretas: componentes ou módulos, ou abstratas, como vimos com os pacotes.
*
*
Este livro está disponível na minha biblioteca google como “lendo agora”. Além das categorias acima, tem uma sobre sistemas adaptativos.
*
Destacar que o controle/apresentador acima não é o controlador do caso de uso visto até o momento, mas o controle do fluxo de informação na camada de apresentação. 
CONSIDERAR o artigo em http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M#_rating que coloca o problema de projetar a Camada de Apresentação como envolvendo 3 aspectos principais: Dados, Lógica de Controle e Sincronização. Os padrões são apresentados em termos de que elemento (V ou C(P)) tem a responsabilidade de lidar com cada um desses aspectos. 
*
*
*
MVC é um dos padrões mais conhecidos para iteração com o usuário (UI), porém, com o rápido desenvolvimento de interfaces gráficas mais ricas, foram criadas várias variações do padrão. Algumas, inclusive, nada tem a ver com o padrão original
*
“In some cases, such as a TextView, the user input is handled directly by the view and used to make changes to the model data. However, in most cases the user input events are 4 This was Doug Simmonds who was, at the time, working for Intuitive Systems Ltd 5 actually routed via the presenter and it is this which becomes responsible for how the model gets changed” - The evolution of the Dolphin Smalltalk MVP application framework. 
*
Não precisa de uma ligacao direta do modelo com a view pelo tipo da aplicacao
*
A escolha é MVC passivo por dois motivos:
Como o modelo está remoto, não há um acoplamento entre a viewe o model (não faria sentido um observer implementando notificações diretamente)
MVC porque há um controlador. A view pode ser, por exemplo, paginas html no browser, mas as requisicoes http são tratadas por um controlador do lado do servidor. 
*** RTR: aplicações MVP para web?
*
*
*
*