A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


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
1

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. Análise e Projeto OO com UML e Padrões| 2 2

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 Análise e Projeto OO com UML e Padrões| 3 3

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 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 Análise e Projeto OO com UML e Padrões| 4 4

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 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. Apresentador Visões Dados Análise e Projeto OO com UML e Padrões| 5 5

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 Análise e Projeto OO com UML e Padrões| 6 6

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 Análise e Projeto OO com UML e Padrões| 7 7

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 Análise e Projeto OO com UML e Padrões| 8 8

9 Variações Duas variações do padrão podem ser identificados mais comumente: Passiva (chamada Passive View) Ativa (chamada Supervising Controller) View Model Desacopladas View Model Sincronização com Observer Análise e Projeto OO com UML e Padrões| 9 9

10 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 Model para atendê-la. O 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 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 Análise e Projeto OO com UML e Padrões| 10 10

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

12 Arquitetura Cliente-Servidor
HTTP Cliente Web (Browser) Internet HTTP Servidor Web HTTP Cliente Web A comunicação entre cliente e servidor na web é feita utilizando o protocolo HTTP. Análise e Projeto OO com UML e Padrões| 12 12

13 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 Análise e Projeto OO com UML e Padrões| 13 13

14 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? Análise e Projeto OO com UML e Padrões| 14 14

15 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. Análise e Projeto OO com UML e Padrões| 15 15

16 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 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. Análise e Projeto OO com UML e Padrões| 16 16


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

Apresentações semelhantes


Anúncios Google