PROJETO GAIA: Guia de Acessibilidade de Interfaces Web focado em aspectos do ...Talita Pagani
Brochure do meu projeto de mestrado apresentando um pouco sobre o contexto e os objetivos da minha pesquisa que tem como foco prover recomendações para o design de interfaces web acessíveis a pessoas com autismo.
Apresentação dos alunos da Pós-Graduação em Ergodesign de Interfaces e Arquitetura de Informação da PUC-RIO (CEE) - edição 2011.
Prof. Luiz Agner
Disciplina: Testes Formais de Usabilidade
Baseado no livro HandBook of Usability Testing, de J. RUBIN.
Teste de Usabilidade - Expandindo a usabilidade na sua empresaLuiz Agner
Material produzido pelos alunos da Pós em Ergodesign de Interfaces, Usabilidade e Arquitetura de Informação da PUC-Rio (2013). Mini-seminários sobre o livro "Handbook of Usability Testing" (Rubin e Chrisnell). - Prof. Luiz Agner
Aplicando conceitos gerais de gerenciamento de projetos à engenharia de softwareNatanael Simões
Apresentação sobre a forma como a Administração influencia diretamente a Engenharia de Software ao mostrar como são aplicados os conceitos gerais de Gerência de Projeto no ciclo de vida de sistemas
PROJETO GAIA: Guia de Acessibilidade de Interfaces Web focado em aspectos do ...Talita Pagani
Brochure do meu projeto de mestrado apresentando um pouco sobre o contexto e os objetivos da minha pesquisa que tem como foco prover recomendações para o design de interfaces web acessíveis a pessoas com autismo.
Apresentação dos alunos da Pós-Graduação em Ergodesign de Interfaces e Arquitetura de Informação da PUC-RIO (CEE) - edição 2011.
Prof. Luiz Agner
Disciplina: Testes Formais de Usabilidade
Baseado no livro HandBook of Usability Testing, de J. RUBIN.
Teste de Usabilidade - Expandindo a usabilidade na sua empresaLuiz Agner
Material produzido pelos alunos da Pós em Ergodesign de Interfaces, Usabilidade e Arquitetura de Informação da PUC-Rio (2013). Mini-seminários sobre o livro "Handbook of Usability Testing" (Rubin e Chrisnell). - Prof. Luiz Agner
Aplicando conceitos gerais de gerenciamento de projetos à engenharia de softwareNatanael Simões
Apresentação sobre a forma como a Administração influencia diretamente a Engenharia de Software ao mostrar como são aplicados os conceitos gerais de Gerência de Projeto no ciclo de vida de sistemas
Construindo sites adequados para pessoas com Autismo - Webbr 2016Talita Pagani
Palestra ministrada na conferência Web.br 2016 sobre como projetar websites e aplicações web mais acessíveis a pessoas com Autismo, apresentando recomendações do projeto GAIA.
Padronizar campos do cadastro de Clientes e Fornecedores para atender aos arquivos do SPED, e abreviar palavras e expressões recorrentes é uma necessidade para adequar os dados de entrada aos limites de caracteres em uso na base de dados.
O KeyCad-abreviador é uma solução para fazer esta tarefa de forma automatizada, e parametrizável pelo usuário.
Construindo sites adequados para pessoas com Autismo - Webbr 2016Talita Pagani
Palestra ministrada na conferência Web.br 2016 sobre como projetar websites e aplicações web mais acessíveis a pessoas com Autismo, apresentando recomendações do projeto GAIA.
Padronizar campos do cadastro de Clientes e Fornecedores para atender aos arquivos do SPED, e abreviar palavras e expressões recorrentes é uma necessidade para adequar os dados de entrada aos limites de caracteres em uso na base de dados.
O KeyCad-abreviador é uma solução para fazer esta tarefa de forma automatizada, e parametrizável pelo usuário.
Design patterns e tecnologias para modularização em java tdc2014Filipe Portes
A palestra apresenta uma visão sobre o conceito de modularização e seus benefícios arquiteturais, em seguida apresenta os principais design patterns e tecnologias como OSGi e Jigsaw que permitem modularizar uma aplicação java de forma organizada e eficiente.
Um padrão é a solução para um determinado problema em um determinado contexto. Um padrão codifica conhecimento específico obtido em uma experiência em um determinado domínio. Um sistema bem estruturado estará cheio de padrões: de linguagem; de projeto; e de arquitetura. Segundo Fowler, podem ser utilizados para melhorar o entendimento ou comunicação dos problemas e decisões arquiteturais. Podem ser vistos como uma tentativa de criar um vocabulário comum para comunicação.
Um padrão que se deve ter conhecimento na orientação a objetos é o GRASP que significa General Responsability Assignment Software Patterns e que descreve os princípios fundamentais do design orientado a objetos e a atribuição de responsabilidades. Outro padrão é o de Gamma, et al que descreve vinte e três padrões clássicos na orientação a objetos. O padrão de Gamma é mais conhecido como padrão da gangue dos quatro (Gang of Four patterns, ou apenas GoF).
Apresentação realizada por Douglas Fischer no Cocoaheads RJ que ocorreu no Space Coworking em Botafogo no dia 26 de Março de 2015.
Foram apresentados alguns tópicos e realizada uma discussão entre os participantes para ver como determinadas pessoas implementavam tal tema.
Dicas e truques sobre performance em JavaEE, JPA e JSFDr. Spock
Slides da apresentação realizada no JavaOne Brasil 2010. Apresenta algumas dicas e truques para evitar problemas de performance em aplicações Web baseadas em Ajax, JSF e JPA.
Acessibilidade Web Cognitiva - BrazilJS 2016Talita Pagani
Palestra ministrada na BrazilJS 2016 sobre como requisitos de acessibilidade web para pessoas com deficiências cognitivas, neuronais ou de aprendizagem como Autismo, Dislexia, TDAH, entre outras.
Caro Analista de Requisitos, você faz UX Design e nem sabe dissoTalita Pagani
Palestra apresentada no TDC 2016 São Paulo: Quem atua como analista de requisitos nem sempre tem a percepção do quão próximo está da área de UX Design. Você pode achar que está mais distante de projetar experiências de uso e que sua função é bem mais "de exatas" do que "de humanas", mas ficaria surpreso(a) ao descobrir que a análise de requisitos é gêmea do design de experiência do usuário e há intersecção em várias atividades.
Interface é código: aprimorando a experiência do usuário no front e no back-endTalita Pagani
Palestra realizada no The Developer's Conference (TDC) em 24 de julho de 2015. Nessa palestra, será abordado como o desenvolvedor/analista/engenheiro pode melhorar a experiência do usuário (UX) para aplicações web com boas práticas de JavaScript, tratamento, prevenção e recuperação de erros, configurações de cache e otimização de requisições HTTP com exemplos de sites de diferentes portes. Grande parte dos tópicos abordados se relacionam com a performance front-end e back-end contextualizados sob o impacto sobre a experiência de uso. Também será mostrado como validar e testar rapidamente requisitos funcionais e não funcionais com prototipagem rápida e quais ferramentas podem ser utilizadas para analisar e verificar diversos pontos do seu site.
Introdução a testes de usabilidade - 11º Diverso DesignTalita Pagani
Palestra sobre os conceitos básicos de testes de usabilidade ministrada no 11º Diverso Design em Bauru.
----
Talk about usability testing basics, in pt-br, presented on XI Design Diverso in Bauru, Brazil.
Guidelines Open-souce de interfaces para a inclusão sociodigital de autistasTalita Pagani
Nesta palestra, serão apresentados em primeira mão no FISL os resultados iniciais do projeto GAIA - Guidelines for Accessible Interfaces for Autistics (https://github.com/talitapagani/gaia), um projeto de mestrado open-source desde o início que visa estabelecer guidelines (diretrizes) para o projeto de interfaces web/mobile para crianças autistas, apoiado nos princípios de Design Universal.
Interface é código: aprimorando a experiência do usuário no front e no back-endTalita Pagani
Sendo desenvolvedor de software, qual a minha contribuição e o meu papel para a usabilidade dos sistemas que desenvolvo? Acredite, muita coisa que prejudica a usabilidade não está no design do seu sistema, mas no código dele.
Nessa palestra, é abordado como o desenvolvedor/analista/engenheiro pode melhorar a experiência do usuário (UX) para aplicações web – com boas práticas de JavaScript, tratamento, prevenção e recuperação de erros, configurações de cache e otimização de requisições HTTP com exemplos de sites de diferentes portes.
Também é mostrado como validar e testar rapidamente requisitos funcionais e não funcionais com prototipagem rápida e quais ferramentas podem ser utilizadas para analisar e verificar diversos pontos do seu site.
Desmistificando a IHC para programadoresTalita Pagani
O que é essa tal de Experiência de Usuário (ou UX)? UX não é da alçada do designer? Eu sou desenvolvedor de software, qual a minha contribuição e o meu papel para a usabilidade dos sistemas que desenvolvo? Estas são perguntas muito frequentes no universo do desenvolvimento de software e, nesta palestra, será abordado como o desenvolvedor/analista/engenheiro tem um papel importante na garantia da experiência de uso e usabilidade e que, sim, UX também envolve o código e até mesmo a metodologia de desenvolvimento que você utiliza.
2. Informações gerais
1. Definição de Design Patterns
2. Design Patterns para softwares orientados a objetos
a.
b.
c.
3.
4.
5.
6.
Padrões de criação;
Padrões estruturais;
Padrões comportamentais;
Estudo de caso de Design Patterns;
Modelagem de software com auxílio de Design Patterns
Design Patterns para interfaces gráficas;
Design Patterns para mobile.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
2
3. Padrões de criação
• Cria uma instância de
várias famílias de classes.
• Quando e onde usar:
– Para criar famílias de objetos
relacionados ou
dependentes;
– Quando é necessário isolar
classes concretas de suas
superclasses;
– Quando um sistema precisa
de independência de como
seus produtos são criados,
compostos e representados.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
3
4. Padrões de criação
• Separa a construção de um
objeto complexo de sua
representação.
• Quando e onde usar:
– Quando for necessário criar um
objeto complexo, especificando
apenas seu tipo e conteúdo. O
objeto construído está protegido
dos detalhes de sua construção;
– Quando se deseja dissociar o
processo de construção de um
objeto complexo a partir das
partes que compõem o objeto;
– Quando é necessário isolar o
código para a construção e
representação.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
4
5. Padrões de criação
• Cria uma instância de várias
classes derivadas.
• Quando e onde usar:
– Quando uma classe quer que
suas subclasses especifiquem o
objeto;
– Quando uma classe não pode
antecipar suas subclasses;
– Quando uma família de objetos
precisa ser separada utilizando
uma interface comum;
– Para esconder classes concretas;
– Para parametrização na criação
de objetos.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
5
6. Padrões de criação
•
Uma instância completa a ser
copiada ou clonada.
•
Quando e onde usar:
– Quando há muitas subclasses que
diferem apenas no tipo de objetos;
– Quando um sistema precisa de
independência de como seus produtos
são criados, compostos e
representados;
– Quando é necessário adicionar ou
remover objetos em tempo de
execução;
– Quando é necessário especificar novos
objetos, alterando a estrutura, ou
configurando uma aplicação com
classes dinâmicas.
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
6
7. Padrões de criação
• Garante que uma classe
tenha somente uma
instância e fornece um
ponto global de acesso
para ela.
• Quando e onde usar:
– Quando é necessário criar
uma instância única,
definindo uma classe final;
– Ao desejar controlar a
instanciação de uma classe
com um valor compartilhado
por todas as instâncias.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
7
8. Padrões estruturais
• Casa interfaces de
diferentes classes.
• Quando e onde usar:
– Ao necessitar de
delegação de objetos;
– Quando é necessário
fazer com que classes
não relacionadas
trabalhem juntas.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
8
9. Padrões estruturais
• Separa a interface de um
objeto de sua
implementação.
• Quando e onde usar:
– Quando se quer separar a
abstração da implementação
de forma permanente;
– Quando se quer melhorar a
extensibilidade;
– Quando se deseja ocultar
detalhes de implementação.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
9
10. Padrões estruturais
• Uma estrutura em árvore
de objetos simples e
consistentes.
• Quando e onde usar:
– Quando se deseja agrupar
componentes para formar
componentes maiores
que, por sua vez, podem
ser agrupados para
formar componentes
ainda maiores.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
10
11. Padrões estruturais
• Adiciona
responsabilidades a um
objeto dinamicamente.
• Quando e onde usar:
– Quando é necessário
adicionar uma nova
função para um objeto
sem afetar outros
objetos.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
11
12. Padrões estruturais
• Uma classe que
representa todo um
subsistema.
• Quando e onde usar:
– Em sistemas complexos,
quando se deseja reduzir
a complexidade;
– Quando é necessário
minimizar a comunicação
e a dependência entre
subsistemas.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
12
13. Padrões estruturais
• Uma instância granularizada
usada para
compartilhamento eficiente.
• Quando e onde usar:
– Quando é preciso instanciar
uma grande quantidade de
classes pequenas e
granuladas;
– Quando é necessário ícones
para representar objetos;
– Para ter um estado de objeto
extrínseco, que pode ser
compartilhado entre classes.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
13
14. Padrões estruturais
• Um objeto que representa outro
objeto.
• Quando e onde usar:
– Se a criação do objeto é muito
custosa em tempo e memória;
– Se é necessário adiar a criação do
objeto até que você precise do
mesmo;
– Quando é necessário realizar
operações que consomem tempo,
como carregar uma imagem
grande;
– Quando é necessário permissões
de acesso para um sistema
complexo.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
14
15. Padrões comportamentais
• Uma forma de passar
uma requisição entre
uma cadeia de objetos.
• Quando e onde usar:
– Quando uma requisição
deve ser tratada por mais
de um objeto;
– Quando não é possível
saber qual objeto deve
lidar com a requisição.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
15
16. Padrões comportamentais
• Encapsula a requisição de
um comando como um
objeto.
• Quando e onde usar:
– Quando uma ação pode ser
representada de várias
formas;
– Quando há necessidade de
desfazer uma ação,
armazenando seus estados
para mais tarde recuperálos.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
16
17. Padrões comportamentais
• Inclui elementos de
linguagem em um
programa.
• Quando e onde usar:
– Quando é necessário o
seu próprio gerador de
interpretador;
– Para traduzir uma
expressão específica;
– Ao tratar uma informação
em árvore.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
17
18. Padrões comportamentais
• Acessa sequencialmente
os elementos de uma
coleção.
• Quando e onde usar:
– Quando é necessário
distinguir variações
transversais de um
aggregate;
– Quando é necessário
filtrar alguma informação
de uma coleção de
agregação.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
18
19. Padrões comportamentais
• Define uma comunicação
simplificada entre classes.
• Quando e onde usar:
– Quando é necessário
particionar um sistema em
pequenos objetos;
– Quando é necessário limitar
subclasses;
– Quando a relação entre a
classe de controle e outras
classes participantes é
multidirecional.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
19
20. Padrões comportamentais
• Captura e restaura o
estado interno de um
objeto.
• Quando e onde usar:
– Quando é necessário
funções de desfazer e
refazer;
– Use para gerenciar
transações de banco de
dados.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
20
21. Padrões comportamentais
• Notifica uma alteração a
um determinado número
de classes.
• Quando e onde usar:
– Quando uma mudança afeta
um ou mais objetos;
– Quando o comportamento
de muitos objetos depende
de um ou mais estados;
– Quando é necessário
comunicação em broadcast.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
21
22. Padrões comportamentais
• Altera o comportamento
de um objeto quando seu
estado é alterado.
• Quando e onde usar:
– Quando é necessário
controlar muitos estados
sem o uso de declarações ifelse ou switch;
– Quando cada estado deve
agir de forma semelhante e
deve ser uma subclasse de
uma mesma superclass.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
22
23. Padrões comportamentais
• Encapsula um algoritmo
dentro de uma classe.
• Quando e onde usar:
– Quando é preciso
encapsular vários algoritmos
para desempenhar funções
semelhantes, mas estes
algoritmos são permutáveis
e variam de forma
independente;
– Use para reduzir instruções
condicionais.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
23
24. Padrões comportamentais
• Define as etapas exatas
de um algoritmo a uma
subclasse.
• Quando e onde usar:
– Para fazer template de
operações similares;
– Quando é necessário
passar de muitas
operações especializadas
para uma operação
genérica.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
24
25. Padrões comportamentais
• Define uma nova
operação a uma classe
sem alterá-la.
• Quando e onde usar:
– Quando é necessário
adicionar operações a
várias classes que
possuem interfaces
diferentes.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
25
26. Design Patterns para softwares orientados a objetos
Criacionais
• Foco: criação de objetos complexos
• Esconde como objetos complexos são criados
Estruturais
• Foco: compor objetos para formar estruturas robustas
• Cria novas funcionalidades a partir de funcionalidades
antigas
• Provê flexibilidade e extensibilidade
Comportamentais
22/02/2014
• Foco: algoritmos e atribuição de responsabilidades a
objetos
• Evita acoplamento forte a uma solução em particular
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
26
27. Design Patterns para softwares orientados a objetos
• Proxy: pode ser de 3 tipos
– Remote proxy
• Cache de informação
– Virtual Proxy
• Para objetos que consomem tempo e tamanho
– Protection Proxy
• Controle de acesso
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
27
28. Design Patterns para softwares orientados a objetos
• Abstract Factory para um jogo
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
28
30. Design Patterns para softwares orientados a objetos
Se no documento de requisitos constar...
Significa...
“independente de dispositivo”
“deve suportar uma família de produtos”
Abstract Factory
“deve se comunicar com objetos
existentes”
Adapter
“deve se comunicar com diversos
sistemas, sendo que alguns serão
desenvolvidos futuramente”
“um protótipo inicial deve ser
demonstrado”
Bridge
“deve se comunicar com um conjunto
existente de objetos”
Façade
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
30
31. Design Patterns para softwares orientados a objetos
Se no documento de requisitos constar...
Significa...
“estrutura complexa”
“deve variar em profundidade e largura”
Composite
“deve ser transparente quanto à
localização do acesso”
Proxy
“deve ser extensível e/ou escalável”
Observer
“deve prover uma política de
funcionamento independente do
mecanismo”
Strategy
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
31
34. Estudo de caso
• Sistema de
colaboração entre
componentes
(AMMAR, 2008)
– Rastrear os estados
de três
componentes
colegas e manter os
seus estados
idênticos.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
34
35. Estudo de caso
Figura 1 - Diagrama de Classe antes de aplicar o padrão.
Fonte: AMMAR, 2008.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
35
36. Estudo de caso
Figura 3 - A estruturação das classes utilizando o padrão Mediator.
Fonte: AMMAR, 2008.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
36
37. Estudo de caso
Figura 4 – Comunicação entre as classes com o Mediator.
Fonte: AMMAR, 2008.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
37
38. Estudo de caso
Figura 2 - Diagrama de Classe depois de aplicar o Mediator.
Fonte: AMMAR, 2008.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
38
39. Estudo de caso
• O padrão Mediator reduz a
dependência entre os componentes
e aumenta a reusabilidade,
extensibilidade e manutenibilidade
da arquitetura do software.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
39
41. Estudo de caso
• A estrutura ideal de um subsistema consiste
de:
– Uma interface;
– Um conjunto de objetos de domínio do
aplicativo (entidades) para modelar entidades
reais ou sistemas existentes;
– Um ou mais objetos de controle;
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
41
42. Estudo de caso
• Realização do objeto Interface: Façade
– Provê uma interface de acesso ao subsistema
• Interface ao sistema existente: Adapter ou
Bridge
– Provê a interface para os sistemas legados
– Os sistemas existentes não precisam ser
necessariamente orientados a objetos
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
42
43. Estudo de caso
• Façade
– Deve ser oferecido por todos os sistemas em um sistema
como um serviço
• Adapter
– Deve ser utilizado como uma interface para os componentes
existentes
• Bridge
– Deve ser utilizado como uma interface para um conjunto de
objetos, quando o conjunto completo de objetos não é
completamente conhecido
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
43
44. Estudo de caso
• Similaridades
– Ambos são utilizados para esconder detalhes de
implementação.
• Diferenças
– Adapter: para objetos que geralmente não trabalham
juntos
• Herança seguida de delegação
– Bridge: para deixar as abstrações e implementações
variarem independentemente
• Delegação seguida de herança
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
44
47. Laboratório 1
• Selecionando padrões:
– Considere como padrões de projeto solucionam
problemas de projeto;
– Examine as seções de Intenção;
– Estude como os padrões se interrelacionam;
– Estude padrões de finalidades semelhantes;
– Examine uma causa de reformulação de projeto ou
considere o que deveria ser variável no seu projeto.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
47
48. Laboratório 1
• Imagine uma situação onde você precisa
implementar um balanceador de carga para
gerenciar conexão com servidores.
• Apenas uma única instância da classe pode
ser criada, pois os servidores podem ficar
online e offline dinamicamente e cada
requisição deve passar por um objeto que
tenha conhecimento da web farm.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
48
49. Laboratório 1
• Solução: Singleton
– Uma única operação de instanciação;
– Criar e dar manutenção a esta única instância.
• Exemplo de código: p. 21 da apostila
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
49
50. Laboratório 1
• Você está desenvolvendo um plugin de
comentários para páginas de um sistema
gerenciador de conteúdo (CMS).
• Este plugin deve enviar um e-mail quando um
comentário é adicionado, sendo que o mailer é
uma função intrínseca do CMS.
• Dessa forma, ao adicionar um comentário, o
Mailer deve estar ciente de que deve enviar um
e-mail para o autor da página.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
50
51. Laboratório 1
• Solução: Observer
– Comportamento em que a alteração do estado
de um objeto afeta outro;
– Modificar o Mailer para que ele seja uma classe
observadora.
• Exemplo de código: p. 24 da apostila
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
51
53. Laboratório 1
• Formar grupos de 4 a 5 pessoas
• Duas situações para identificar os padrões
• Esboçar um diagrama no Astah Community
• 45min para cada situação apresentada
• Para cada situação, definir: Qual o pattern que poderia
ser utilizado?
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
53
54. Laboratório 1
• Você está desenvolvendo uma aplicação para agilizar a
criação de documentos usando modelos pré-definidos, que
atualmente suporta dois tipos: Relatórios e Currículos.
• A ferramenta precisa ser flexível para a criação destes
documentos. Embora eles tenham propriedades em comum
(ambos têm páginas), um Relatório deve conter tipos de
páginas para introdução, resultados, conclusão, sumário e
bibliografia, enquanto que um currículo possui páginas de
habilidades, formação e experiência profissional.
• Ao criar um Relatório ou um Currículo, ele já deve produzir
(retornar) estas páginas padrões.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
54
55. Laboratório 1
• Em um dado sistema de e-commerce, os produtos
podem ser classificados em categorias prédeterminadas, que compõem o menu de
navegação do site, e em tags, que são
classificações atribuídas pelos consumidores.
• Ambas conectam com o mesmo banco de dados e
precisam ser retornadas da mesma forma, sendo
selecionadas do banco de dados e listadas na tela.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
55
57. Tarefas
• Nesta atividade, você deverá selecionar uma
situação vivenciada no seu cotidiano de
trabalho onde você já implementou ou poderia
implementar ao menos um design pattern.
Descreva qual o problema resolvido (ou que
poderia ser resolvido) e porque aquele(s)
pattern(s) foi(foram) escolhidos (ou poderiam
ser escolhidos) para resolver esta situação.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
57
58. Tarefas
• Cada grupo, de 4 a 5 pessoas, deverá montar
um conjunto de, no mínimo, 5 patterns
identificados através de situações vivenciadas
no cotidiano de trabalho. Os patterns
identificados podem ser diversos: algoritmos,
soluções de interface ou processos.
• O importante é que eles sejam válidos como
uma solução de sucesso utilizada para resolver
um problema recorrente.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
58
59. •
ALEXANDER, C., et al. A Pattern Language. Oxford University Press, 1977.
•
AMMAR, H. H. 2008. Case Studies on Design Patterns. Disponível em: http://www.csee.wvu.edu/~ammar/rts/adv rts/design patterns
case studies/before and after CaseStudies.ppt
•
BRUEGGE, B.; DUTOIT, A. H. 2014. Object-Oriented Software Engineering. Disponível em:
http://www.cs.bilkent.edu.tr/~ugur/teaching/cs319/
•
DOFACTORY. 2014. .NET Design Patterns. Disponível em: http://www.dofactory.com/Patterns/Patterns.aspx
•
GAMMA, E., et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos; tradução de Luiz A. Meirelles Salgado.
Porto Alegre: Bookman, 2007.
•
HEGODA, D. 2013. Why? When to? Software Design Patterns. Disponível em: http://dasunhegoda.com/software-designpatterns/158/
•
JAVACAMP. 2012. Java Design Patterns At a Glance. Disponível em: http://www.javacamp.org/designPattern/
•
LEACOCK, M.; MALONE, E.; WHEELER, C. Implementing a Pattern Library in the Real World: A Yahoo! Case Study. In: Sixth Annual
ASIS&T Information Architecture Summit. Montréal, Quebec, Canada, mar. 2005. Disponível em: http://leacock.com/patterns/
•
MCDONALD, J. 2007. Design Patterns Quick Reference. Disponível em: http://www.mcdonaldland.info/2007/11/28/40/
•
MEMÓRIA, F. Design para a internet: Projetando a experiência perfeita. Rio de Janeiro: Elsevier, 2005.
•
VINICIUS, G. 2011. Padrões de design orientado a objetos. Disponível em: http://pt.slideshare.net/glaucovinicius/padres-de-designorientado-a-objetos
•
WELIE, M. V. 2008. Patterns in Interaction Design. Disponível em: http://www.welie.com/patterns/
21/02/2014
Design Patterns | Aula 1 | Prof.ª Esp. Talita Pagani
59