Padrões de Interação com o Usuário

Apresentação em tema: "Padrões de Interação com o Usuário"— Transcrição da apresentação:

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 ocorre resolve Contexto Problema Solução 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.

3 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

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 Este livro está disponível na minha biblioteca google como “lendo agora”. Além das categorias acima, tem uma sobre sistemas adaptativos. 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. 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 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. 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 MODEL Camada Negócio

7 Padrão MVC O padrão foi originalmente criado em 1978
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) 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

8 MVC Original Responsabilidades:
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 Explicar as variações, com o controlador centralizando ou não o fluxo. Explorar as variações intuitivamente (o próximo slide registra as 2 variações e o seguinte explora a questão do presentation model). FALTA esclarecer aqui a ligação entre o controller e a view, em termos de associação e dependência. No MVC original, a ligação é uma associação entre o controlador e a view (o controlador tem a view como atributo). Isso muda no MVP, onde a view precisa enviar mensagem para o presenter. 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) View Model Desacopladas View Model Sincronização com Observer

10 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

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 View input notificação C. Apresentação 4 1 Presentation Model Controller Destacar aqui que no MVC (Supervising Controller) a comunicação entre o B. Model e a View pode ser direta, sem passar pelo Controlller. Neste caso, a implementação pode ser dada usando o Observer. 3 notificação 2 Business Model 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 Responsabilidades: Presenter: media View e Model
Utilizado em diversas aplicações GUI Desktop Presenter View Model 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. O destaque em vermelho é que são pontos que diferenciam o MVP do MVC. Com relação ao segundo ponto, destacar que a função do presenter (de mediar a comunicação entre view e model) permite reuso por várias views e tal presenter pode ser também um objeto mock para teste de unidade (o teste tende a ser mais simples do que no caso do MVC). 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 View notificação C. Apresentação 4 2 Presentation Model Presenter 3 notificação Business Model C. Negócio

15 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 Este slide precisa ser mais detalhado, pois há outras questões envolvidas, como facildiade de testes, questões tecnológicas (o suporte dado pelo framework adotado, a semelhança entre views, etc.).

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. Mencionar que se for um modelo remoto, entao teria que ser passiva, pois não teria como ter a ligacao direta entre o model e a view Enfatizar o comentário em azul: o MVC com Supervising Presenter é bem parecido com o MVC. Mencionar ajax

17 Passive MVP Responsabilidades: Presenter: Media View e Model
Utilizado em diversas aplicações Web Presenter View Model 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 View P. Model C. Apresentação 4 1 Presenter 3 2 Business Model C. Negócio

19 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)

20 Diagrama Sequência Supervising Presenter
:Main inicializa :Model 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 Não precisa de uma ligacao direta do modelo com a view pelo tipo da aplicacao

22 Arquitetura Cliente-Servidor
Cliente Web (Browser) HTTP Internet HTTP Servidor Web HTTP Cliente 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) Cliente Web requisição HTTP página HTML resposta HTTP (conteúdo HTML) Servidor Web Cliente 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? A escolha é MVC passivo por dois motivos: Como o modelo está remoto, não há um acoplamento entre a view e 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?

25 Passive View [MVC] Responsabilidades:
Utilizado em diversas aplicações Web Controller View Model 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ência MVC 2
Cliente Servidor Browser :Front Controller :Fabrica Helpers :Model Command serviço “1” :Helper1 obter(“1”) comando v2 :View gera 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 Jsf – padrao sun da mvc – cria um bin para ser o controlador, visoes jsf e define front controlador (ja é pre-definido) so define os helpers. Permite misturar o helper com o presentation model. Struts da APACHE tb tem isso. Mas separa helper do presentation model; fica mais organizado. versao atual do jsf parece mais poderoso, pois aproveitou varias coisas do struts. Spring mvc menos usado. Arquivos de configuracao. Indica quem é a visao que esta relacionada a tal helper, ou o cadastro de todos os helpers no arquivo de configuracao.

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 Com relação ao uso de JSP nas views, o JSF 2 usa como padrão “”facelets” em vez de JSP. Jsp tem uma tag lib que permite que o jsp fique parecido com html; ele puro parece uma linguagem de script.

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 Outros frameworks (ver seção ao final do artigo Stripes, Wicket, Play!, and Tapestry. The new Xforms, Grails. Na próxima edição, dar alguns detalhes comparativos de Play aqui.