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

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

3. RecapitulandoPadrã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 (PatternOriented Software Architecture) • Categoria: FromMud 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: Controladiferentesvisõ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. MODEL 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 • 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 Controller View Model associação indireta associação direta Em geral para cada elemento visão existe um controlador

9. Variações • Duas variações do padrão podem ser identificados mais comumente: • Passiva (chamada Passsive View) • Ativa (chamada Supervising Controller) View View Model Model 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 View Presentation Model Business Model 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 • 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. Utilizado em diversas aplicações GUI Desktop Presenter View Model foco do padrão associação indireta associação direta 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 Presentation Model Business Model 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 supervisingpresenter segue um estilo de controller.

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

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 Business Model P. Model C. Apresentação 4 1 Presenter 2 3 C. Negócio

19. Supervising Presenter foco do padrão • 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 Utilizado em diversas aplicações GUI Desktop Presenter View Model associação indireta associação direta Similar ao Dolphin MVP, porém enfatiza que o Presenter deve ter mais responsabilidades (lógica de apresentação)

20. Diagrama SequênciaSupervisingPresenter inicializa inicializa :View :Model :Main 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. Cliente Web (Browser) ClienteWeb Internet HTTP HTTP Arquitetura Cliente-Servidor HTTP Servidor Web A comunicação entre cliente e servidor na web é feita utilizando o protocolo HTTP.

23. ClienteWeb ClienteWeb Arquitetura Cliente-Servidor Via getde uma URL Parametros: - Get (explicitamente) - Post (implicitamente) requisição HTTP página HTML resposta HTTP (conteúdo HTML) ServidorWeb

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

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 Browser :Front Controller :Fabrica Helpers Command :Helper1 :Model serviço “1” obter(“1”) comando gera v2 :View processa html HttpResponse obter(“2”) serviço “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 -> 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

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