padroes&manut para a industria final.ppt

padrões de manutenção

1. Eliane Martins - Instituto de Computação - UNICAMP
Melhoria da Manutenibilidade
Criado: Set/2005
Atualizado: Nov/2010

2. Eliane Martins - Instituto de Computação - UNICAMP 2
Tópicos
•Manutenibilidade
•Técnicas para melhoria da manutenibilidade
•Métricas

3. Eliane Martins - Instituto de Computação - UNICAMP 3
Referências
CHIOSSI, T.S. “Técnicas de Desenvolvimento para a Manutenibilidade”. Cap2 do livro
sobre Manutenção de Software, em andamento.
DESCHAMPS, F. “Padrões de Projeto. Uma Introdução”. Notas de Aula. Departamento
de Automação e Sistemas (DAS). Universidade Federal de Santa Catarina.
KON, F. “Padrões de Projeto de Software Orientado a Objetos”. Notas de Aula.
IME/USP, 2005. URL: www.ime.usp.br/~kon/MAC5714/2005/aulas/slides/GoF.ppt
JANDL, P. Jr. “Uma Introdução aos Padrões de Projeto com Java”. 2003. Obtido na
Internet em ago/2005.
PRESSMAN, R.S. “Sw Engineering: a Practitioner’s Approach”. McGraw-Hill, 3ª ed,
1992.
SOMMERVILLE , I.. “Sw Engineering”, 6ª ed, 2001, cap27.
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. "Design Patterns: Elements of
Reusable Object-Oriented Software". Reading, MA: Addison Wesley, 1995.

4. Eliane Martins - Instituto de Computação - UNICAMP
Manutenibilidade
•Algumas definições
–Facilidade com que um sistema ou componente de software
pode ser modificado para se corrigir falhas, melhorar
desempenho (ou outros atributos), ou ser adaptado a
mudanças no ambiente; (IEEE 610.12, 1990)
–Facilidade para corrigir um sw, quando possui falhas ou
deficiências, e também para expandir ou contrair o sw para
satisfazer a novos requisitos (Martin e McClure 1983)
–Conjunto de atributos relativos ao esforço necessário para
se realizar modificações em um sw (ISO/IEC 8402 1986)

5. Eliane Martins - Instituto de Computação - UNICAMP
Considerações
•Todos os sistemas são igualmente fáceis de manter ?
Porque não ?
–Sistemas não são desenvolvidos visando manutenibilidade

–manutenibilidade deve ser uma das metas do desenvolvimento
•Que critérios usar para determinar se um sw é fácil de
manter ou não ?
•É possível estimar o grau de manutenibilidade de um sw ?

6. Eliane Martins - Instituto de Computação - UNICAMP
Como determinar se o sw é ou não fácil de
manter?
•Manutenibilidade é uma característica que deve ser considerada ao
longo de todo o desenvolvimento. Isso se deve ao fato de que alguns
fatores relacionados ao desenvolvimento a influenciam [PRESSMAN
92; SOMMERVILLE 01]:
–Modularidade
–Linguagem de programação
–Estilo de programação
–Verificação e Validação (V&V)
–Disponibilidade dos testes
–Depurador (debugger)
–Documentação
–Controle de Configuração

7. Eliane Martins - Instituto de Computação - UNICAMP
Fatores de influência
•Modularidade
–Quanto melhor a estruturação do sistema, isto é, quanto mais
independentes forem os módulos que o compõem, mais fácil fica
modificar um componente sem afetar todos os outros.
•Linguagem de programação
–programas escritos em linguagem de alto nível são geralmente
mais fáceis de entender, e conseqüentemente, de manter. O uso
linguagens padronizadas também é útil.
•Estilo de programação
–a forma como um programa é escrito (uso de comentários, escolha
de nomes mnemônicos para variáveis e constantes, uso de
indentação, entre outros) contribui para a sua inteligibilidade, e
conseqüentemente, para a facilidade em mantê-lo.

8. Eliane Martins - Instituto de Computação - UNICAMP
Fatores de influência
•Verificação e Validação (V&V)
–em geral, quanto maior o esforço com V&V, menor o número de
falhas residuais no sistema, diminuindo assim a necessidade de
manutenções corretivas
•Disponibilidade dos testes
–a aplicação de testes de regressão é necessária a cada modificação
do sistema. A disponibilidade dos testes aplicados facilita a
geração dos testes na fase de manutenção.
•Depurador (debugger)
–a existência de ferramentas de auxílio à depuração (“debugging”)
de programas facilita o diagnóstico das falhas encontradas.

9. Eliane Martins - Instituto de Computação - UNICAMP
Fatores de influência
•Documentação
–quanto mais a documentação é clara, completa e atualizada, mais
fácil se torna entender o sistema. O uso de uma padronização para
a documentação facilita a criação e manutenção da mesma.
•47% - 62% é a % de esforço requerido para a compreensão de
programas e documentos [Pigosrki 1996]
•Controle de Configuração
–um dos aspectos importantes na manutenção é o controle de todos
os produtos que foram gerados durante o processo de construção
do sistema.

10. Eliane Martins - Instituto de Computação - UNICAMP
Fatores externos
•Além dos fatores internos, relativos à forma como o sw é
desenvolvido, fatores externos também influenciam na
manutenibilidade:
–Equipe
–Domínio da aplicação
–Idade do sistema
–Dependência do ambiente externo
–Estabilidade do hw
–Disponibilidade de ferramentas de desenvolvimento

11. Eliane Martins - Instituto de Computação - UNICAMP
Fatores externos
•Equipe
–idealmente a manutenção de um sistema seria realizada pela equipe
que o desenvolveu. Se tal não é possível, recomenda-se que a
equipe de manutenção acompanhe o processo de desenvolvimento.
• Domínio da aplicação
–se o domínio da aplicação é conhecido e pode ser facilmente
compreendido e definido, os requisitos em geral são completos e
estáveis, e com isso a necessidade de manutenção perfectiva
diminui. Em domínios mais complexos, ou não muito conhecidos, a
tendência é que os requisitos mudem com mais freqüência, e com
isso a manutenção preventiva é mais necessária.
•Métodos evolutivos (ex.: métodos ágeis)  a manutenção preventiva é
intrínseca ao desenvolvimento

12. Eliane Martins - Instituto de Computação - UNICAMP
Fatores externos
•Idade do sistema
–quanto mais velho um sistema, mais modificações ele sofreu ao
longo do tempo, e, portanto, mais complexo ele se torna. A
manutenção preventiva (reengenharia) tem por objetivo melhorar a
sua manutenibilidade.
•Dependência do ambiente externo
–se um sistema é muito dependente do ambiente externo ele precisa
ser alterado a cada mudança nesse ambiente.

13. Eliane Martins - Instituto de Computação - UNICAMP
Fatores externos
•Estabilidade do hw
–geralmente são necessárias modificações para adaptar o software a
uma nova plataforma.
•Disponibilidade de ferramentas de desenvolvimento
–as ferramentas CASE evoluem ou podem sair do mercado. É útil
guardar versões das ferramentas usadas para desenvolver o
sistema. A manutenção se torna mais fácil, pois pode-se atualizar
diagramas e documentos de Análise/Projeto, modificar código
fonte escrito em linguagens que caíram em desuso, atualizar os
testes, entre outros.
A implicação disto é que às vezes o hw em que a ferramenta roda
precisa ser preservado!

14. Eliane Martins - Instituto de Computação - UNICAMP
Manutenibilidade
•Como medir ?
•Como conseguir ao longo do desenvolvimento?

15. Eliane Martins - Instituto de Computação - UNICAMP
Técnicas de desenvolvimento 
manutenibilidade
•Muitos métodos são utilizados durante as diferentes etapas
do desenvolvimento de software com o objetivo de garantir
qualidade. Alguns exemplos:
–Reutilização de software
–Uso de mecanismos de separação de interesses:
•reflexão computacional
•orientação a aspectos

16. Eliane Martins - Instituto de Computação - UNICAMP
•“Qualquer procedimento que produza (ou ajude a
produzir) um sistema tornando a utilizar algo desenvolvido
previamente”
[Peter Freeman 1987, citado em Pressman95, cap.26]]
•Reutilização é algo praticado há muito tempo em
Engenharia de Software, só que de maneira ad hoc
•Dada a pressão por produzir sw de boa qualidade em pouco
tempo  necessidade de reutilizar de forma sistemática
Reutilização em Engenharia de Software

17. Eliane Martins - Instituto de Computação - UNICAMP
•Reutilização pode ser considerada em todas as fases do
desenvolvimento
•Pode-se reutilizar:
–Artefatos intermediários  padrões de software
–Sistemas de aplicação
–Componentes
–Classes
–Funções
Níveis de Abstração

18. Eliane Martins - Instituto de Computação - UNICAMP
Padrões
•Padrão, s.m.[do latim patronu, protetor]
1. Modelo oficial de pesos e medidas. 2. Aquilo que serve de base ou
norma para a avaliação de qualidade ou quantidade. 3. Qualquer
objeto que serve de modelo à feitura de outro. ...
[FERREIRA, Aurélio B. H. “Novo Dicionário da Língua Portuguesa”. Rio
de Janeiro, RJ: Nova Fronteira, 2ª edição, 1986.]

19. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de software
•Porquê
–Aumentar a possibilidade de reuso de boas soluções para problemas
freqüentes, garantindo, com isso, melhor qualidade para o software
–Reutilizar soluções para problemas surgidos em trabalhos anteriores
é uma tendência entre especialistas
–Os padrões surgem com a experiência prática
Experiência de especialistas pode ser compartilhada com novatos

20. Eliane Martins - Instituto de Computação - UNICAMP
Uma definição
•“Um padrão descreve um problema que ocorre
repetidamente no nosso ambiente, descrevendo a essência
de uma solução para este problema, de forma que pode-se
usar esta solução milhares de vezes, sem fazê-lo da mesma
forma duas vezes.”
[ALEXANDER, Christopher, 1977 --> propôs padrões a serem usados
em Arquitetura, de onde surgiu a idéia de utilizar do mesmo recurso
em software]
[ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING,
I., ANGEL, S. "A Pattern Language". New York, NY (USA): Oxford University Press, 1977].

21. Eliane Martins - Instituto de Computação - UNICAMP
Outra definição
•“Um padrão de software nomeia, motiva e explica uma
solução genérica a um problema recorrente que surge em
uma situção específica. Ele descreve o problema, a solução,
quando é aplicável e quais as conseqüências de seu uso.”
[Gamma et al]

22. Eliane Martins - Instituto de Computação - UNICAMP
Características [Jandl 2003]
•Descrevem e justificam soluções para problemas concretos
e bem definidos.
•Documentam a experiência existente e comprovada.
•Fornecem um vocabulário comum aos desenvolvedores de
software.
•Descrevem relações entre conceitos, estruturas e
mecanismos existentes nos sistemas.
•Podem ser utilizados em conjunto com outros padrões.

23. Eliane Martins - Instituto de Computação - UNICAMP
Uso de padrões
•Padrões podem ser utilizados nas diversas etapas de
desenvolvimento de software:
–Análise (M.Fowler 1997)
–Arquitetura, Projeto e Codificação (Gamma e al;
Buschmann 1996.)
–Testes (R.Binder 1999)
–Manutenção (Barry 2003; Hammouda 2004)
–Reengenharia (Demeyer 2003)
...

24. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de Arquitetura
•Representam esquemas para estruturar o software. Definem conjunto de
subsistemas pré-definidos, especificam suas responsabilidade e as regras para
organizar os relacionamentos entre eles.
–Ex.: Modelo em camadas
–Ex.: padrões IBM para e-business (www128.ibm.com/developerworks/patterns/)
Apresentação
Controle do Negócio
Dados
Entradas do usuário
Exibição de resultados na tela
 Lógica do negócio
 Comunicação com serviços: conexão
com banco de dados, troca de
mensagens, controle de transações, ...

25. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de Projeto e Idiomas
•Padrões de Projeto
–Permitem refinar os subsistemas da arquitetura, ou os
relacionamentos entre eles
–Focam em aspectos típicos de projeto, tais como: interface-usuário,
criação de objetos, entre outros
–São os mais comuns na literatura
•Idiomas
–São padrões de baixo nível, específicos para linguagens de
programação
–Descrevem como implementar aspectos dos subsistemas ou dos
relacionamentos entre eles, usando características de uma
determinada linguagem de programação

26. Eliane Martins - Instituto de Computação - UNICAMP
Outros padrões
•Padrões de análise
–Fazem parte da Especificação de Requisitos ou da Modelagem Conceitual
–Definem conjunto de objetos do mundo real, seus relacionamentos e as
regras que definem seu comportamento
–São dependentes da aplicação pois descrevem aspectos específicos do
domínio do problema
•Padrões de manutenção
–Regras e restrições que devem ser satisfeitas por entidades de um programa
(classes, métodos e atributos) para facilitar a manutenção, mais
especificamente, a documentação (HAMMOUDA 2004)
•Padrões para reengenharia
–padrões para refatoração
•Padrões de teste
–Definem procedimentos, modelos de falhas, entre outros, para descrever
métodos de testes (Binder 2000)

27. Eliane Martins - Instituto de Computação - UNICAMP
Gang of Four (GoF)
•E. Gamma and R. Helm and R.
Johnson and J. Vlissides.
Design Patterns - Elements of
Reusable Object-Oriented
Software. Addison-Wesley,
1995.
•Existem diversas formas de descrever um padrão. Para os padrões de projeto a forma
mais comum é aquela descrita no livro de Gamma et al, denominado Gang of Four
(GoF):
[Kon2005]

28. Eliane Martins - Instituto de Computação - UNICAMP
O Formato dos padrões no GoF
–Nome (inclui número da página)
•um bom nome é essencial para que o padrão caia na boca do povo
–Objetivo / Intenção ou Motivação
•um cenário mostrando o problema e a necessidade da solução
–Aplicabilidade
•como reconhecer as situações nas quais o padrão é aplicável
–Estrutura
•uma representação gráfica da estrutura de classes do padrão
–Participantes
•as classes e objetos que participam e quais são suas responsabilidades
–Colaborações
•como os participantes colaboram para exercer as suas responsabilidades
[Kon2005]

29. Eliane Martins - Instituto de Computação - UNICAMP
O Formato dos padrões no GoF
–Conseqüências
•vantagens e desvantagens, trade-offs
–Implementação
•com quais detalhes devemos nos preocupar quando implementamos o padrão
•aspectos específicos de cada linguagem
–Exemplo de Código
•no caso do GoF, em C++ (a maioria) ou Smalltalk
–Usos Conhecidos
•exemplos de sistemas reais de domínios diferentes onde o padrão é utilizado
–Padrões Relacionados
•quais outros padrões devem ser usados em conjunto com esse
•quais padrões são similares a este, quais são as dierenças
[Kon2005]

30. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo – padrão de teste de regressão
•Nome:
–Teste de caso de uso de maior risco
•Problema
–Útil quando não se dispõe de
tempo, recursos ou pessoal
suficiente para reaplicar todos os
testes
•Solução
–Usar critérios de risco para avaliar
os casos de uso a serem testados
–Aplicar os critérios para obter o
subconjunto de testes a ser
reaplicado
–Usar como oráculo os resultados
do conjunto de testes aplicado
anteriormente
–Critérios de entrada:
•Delta já foram testados
•Conjunto de testes previamente
aplicados já existe
•Matriz associando casos de uso
aos casos de teste foi criada
•O ambiente de testes já foi
configurado igual aos dos testes
prévios
–Critérios de saída
•Todos os testes selecionados
foram aplicados e os bugs
devidamente registrados
• Conseqüências
–Risco moderado de não revelar
uma falha de regressão
–Baixo custo de análise para seleção
de casos de teste
...
[Binder 2000, c.15]Não é do GoF, mas usou o mesmo formato de descrição

31. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de projeto
•No GoF, padrões de projeto podem ser divididos nas
seguintes categorias:
–Padrões de criação (creational): abstraem o processo de criação de
objetos a partir da instanciação de classes
•Ex.: Abstract Factory, Builder, Singleton
–Padrões estruturais (structural): tratam da forma na qual classes e
objetos estão organizados para a formação de estruturas maiores
•Ex.: Adapter, Composite, Decorator, Façade
–Padrões comportamentais (behavioral): tratam de algoritmos e da
atribuição de responsabilidades a objetos.
•Ex.: Iterator, Mediator, Observer, State, Visitor

32. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de criação
•Abstract Factory
–Fornece uma interface para a criação de uma família de objetos
relacionados ou dependentes, sem especificar as suas classes
concretas
•Usos conhecidos:
–sistemas que necessitam de suporte a diferentes tipos de interfaces gráficas
(Motif, Windows, ...).
–Sistemas que devem ser configurados em uma dentre várias famílias de
produtos.

33. Eliane Martins - Instituto de Computação - UNICAMP
Abstract Factory - Motivação
•Considere uma aplicação com interface gráfica que é implementada para
plataformas diferentes (Motif para UNIX e outros ambientes para Windows e
MacOS).
•As classes implementando os elementos gráficos não podem ser definidas
estaticamente no código. Precisamos de uma implementação diferente para
cada ambiente. Até em um mesmo ambiente, gostaríamos de dar a opção ao
usuário de implementar diferentes aparências (look-and-feel).
•Podemos solucionar este problema definindo uma classe abstrata para cada
elemento gráfico e utilizando diferentes implementações para cada aparência ou
para cada ambiente.
•Ao invés de criarmos as classes concretas com o operador new, utilizamos uma
Fábrica Abstrata para criar os objetos em tempo de execução.
•O código cliente não sabe qual classe concreta utilizamos.
[Kon2005]

34. Eliane Martins - Instituto de Computação - UNICAMP
Abstract Factory - Aplicabilidade
Use uma fábrica abstrata quando:
•um sistema deve ser independente da forma como seus produtos
são criados e representados;
•um sistema deve poder lidar com uma família de vários produtos
diferentes;
•você quer oferecer uma biblioteca de classes de produtos mas não
quer revelar as suas implementações, quer revelar apenas suas
interfaces.
[Kon2005]

35. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo de utilização do abstract factory
GUIMotif
criaBarraRolagem ( )
criaJanela ( )
GUIWindows
criaBarraRolagem ( )
criaJanela ( )
GUIAbstrata
criaBarraRolagem ( )
criaJanela ( )
IGuiAbstrata
concretas
Define uma interface para as operações que
criam objetos como produtos abstratos
Fábrica Abstrata: classe abstrata contendo
o código comum às classes concretas
(fábricas) que têm um tema comum (ex.:
interface-usuário)
Fábrica: Implementa as operações que
criam objetos para os produtos
concretos

36. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo de utilização do abstract factory
GUIMotif
criaBarraRolagem ( )
criaJanela ( )
GUIWindows
criaBarraRolagem ( )
criaJanela ( )
GUIAbstrata
criaBarraRolagem ( )
criaJanela ( )
IGuiAbstrata cliente
janelaWindowsjanelaMotif
BarraRolagem
Windows
BarraRolagem
Motif
Janela
usa
BarraRolagem
usa
usa
cria
cria
abstratas

37. Eliane Martins - Instituto de Computação - UNICAMP
Abstract Factory - Participantes
•AbstractFactory (GUIAbstrata)
•ConcreteFactory (GUIMotif, GUIWindows)
•AbstractProduct (Janela, Barra de Rolagem)
•ConcreteProduct (JanelaMotif, BarraRolagemMotif,
JanelaWindows, BarraRolagemWindows)
•Cliente - usa apenas as interfaces declaradas pela
AbstractFactory e pelas classes AbstratProduct

38. Eliane Martins - Instituto de Computação - UNICAMP
Abstract Factory - Colaborações
•Normalmente, apenas uma instância de ConcreteFactory é
criada em tempo de execução.
•Esta instância cria objetos através das classes
ConcreteProduct correspondentes a uma família de produtos.
•Uma AbstractFactory deixa a criação de objetos para as
suas subclasses ConcreteFactory.
[Kon2005]

39. Eliane Martins - Instituto de Computação - UNICAMP
Abstract Factory - Conseqüências
O padrão
1.isola as classes concretas dos clientes;
2.facilita a troca de famílias de produtos (basta trocar uma linha
do código pois a criação da fábrica concreta aparece em um
único ponto do programa);
3.promove a consistência de produtos (não há o perigo de
misturar objetos de famílias diferentes);
4.dificulta a criação de novos produtos ligeiramente diferentes
(pois temos que modificar a fábrica abstrata e todas as fábricas
concretas).
[Kon2005]

40. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de criação
•Singleton
–Garante a existência de uma única instância de uma
determinada classe e fornece um ponto global de acesso
para ela.
•Uso conhecido:
–programas que só podem ter uma instância sendo executada em
um determinado momento.

41. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Singleton
// SingletonImpl.java
public final class SingletonImpl {
private static SingletonImpl instance = null;
private SingletonImpl() { ... }
public static SingletonImpl getInstance() {
if (instance==null) {
instance = new SingletonImpl();
}
return instance;
}
}
// usando o sigleton
public class UsoDoSingletonImpl {
:
SingletonImpl obj;
:
obj = SingletonImpl.getInstance();
:
}
retorna a
instância criada
Singleton
static InstanciaUnica: Singleton
static getinstance ( ): Singleton
[Jandl2003]

42. Eliane Martins - Instituto de Computação - UNICAMP
Padrões estruturais
•Composite
–Compõe objetos em estrutura de árvore para representar hierarquias
do tipo partes-todo.
–Permite que se trate de maneira uniforme objetos individuais e
composição de objetos, permitindo que objetos complexos sejam
compostos, recursivamente, de objetos mais simples.
–Uso conhecido:
•representar hierarquias de agregação (parte-todo)

43. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Composite
Cliente
usa
1
*
Componente
+Operação ( )
+Adicionar (in Componente)
+Remover (in Componente)
+BuscarParte (in índice: int)
ImplemComponente
+Operação ( )
Composite
+Operação ( )
+Adicionar (in Componente)
+Remover (in Componente)
+BuscarParte (in índice: int)

44. Eliane Martins - Instituto de Computação - UNICAMP
Padrões estruturais
•Decorator
–Atribui, dinâmicamente, responsabilidades adicionais a um objeto,
para facilitar o uso de subclasses para extensão de funcionalidades.
–Só as responsabilidades do objeto são alteradas, não sua interface.
–Uso conhecido:
•atribuição de enfeites gráficos e outras funcionalidades acessórias a
widgets

45. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Decorator
Componente_visual
Desenhar()
Decorator
Desenhar()
Visualizador_Texto
Desenhar ()
Borda
Espessura _borda
Desenhar()
Desenhar_borda ()
Barra_Rolagem
Posição-rolagem
Desenhar()
Rolar ()
[Thelma2005]

46. Eliane Martins - Instituto de Computação - UNICAMP
Mais alguns padrões estruturais
•Facade
–Fornece uma interface única para um conjunto de interfaces de um
subsistema.
–Define uma interface de alto nível, tornando o subsistema mais fácil
de usar.
–Uso conhecido:
•interface única em sistemas complexos

47. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Facade
Facade
Subsistema ou componente
Interface única para o
subsistema ou componente

48. Eliane Martins - Instituto de Computação - UNICAMP
Mais alguns padrões estruturais
•Adapter
–Converte a interface de uma classe em outra, na forma esperada
pelas suas clientes. Permite que classes com interfaces que, de outra
forma, seriam incompatíveis, possam colaborar.
–Uso conhecido:
• wrapper, serve para adaptar interface de classes

49. Eliane Martins - Instituto de Computação - UNICAMP
Adapter (wrapper)
Cliente
-Alvo: alvo1
Adapter
- Servidor: servidor1
+ void operacao_cliente ( )
Servidor
- Servidor: servidor1
+ void operacao_servidor ( )
Alvo
+ void operacao_cliente ( )
void operação_cliente( )
{
servidor1.operação_servidor( )
}

50. Eliane Martins - Instituto de Computação - UNICAMP
Padrões comportamentais
•Iterator
–Fornece uma forma de aceder seqüencialmente aos elementos de
uma coleção sem expor sua representação subjacente
–Uso conhecido:
• bibliotecas C++, Java

51. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Iterator
ImplemColeção
getIterator( ): Iterator
return new ImplemIterator (this)
ImplemIterator
IColeção
getIterator( ): Iterator
IIterator
hasNext( ): boolean
next ( ): Object

52. Eliane Martins - Instituto de Computação - UNICAMP
Padrões comportamentais
•Mediator
–Define um objeto que encapsula a interação entre um conjunto de
objetos.
–Promove o acoplamento fraco, evitando que os objetos refiram
explicitamente uns aos outros.
–Uso conhecido:
•arquitetura de aplicações

53. Eliane Martins - Instituto de Computação - UNICAMP
Mediator
Mediador Colaborador
Mediador_concreto
Colaborador_concreto1 Colaborador_concreto2
mediador

54. Eliane Martins - Instituto de Computação - UNICAMP
Mais alguns padrões comportamentais
•Observer
–Permite que todos os dependentes de um objeto sejam notificados e
atualizados automaticamente quando o objeto (sujeito) muda de
estado.
–Utiliza um mecanismo de registro que permite ao sujeito notificar
aos interessados sobre mudanças.
–Uso conhecido: propagação de modificações e atualizações com
acoplamento fraco entre os objetos

55. Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Observer
Observador
+update ( )
Observado
+attach (in Observer)
+detach (in Observer)
+notify ( )
*
Observado_concreto
estado
+getEstado ( )
o  {Observador}: o.update( )
Observador_concreto
estadoObservado
+update ( )
estadoObservado = sujeito.getEstado( )
sujeito

56. Eliane Martins - Instituto de Computação - UNICAMP
Os padrões do GoF
•Criação:
–Abstract Factory
–Builder
–Factory Method
–Prototype
–Singleton
•Estruturais:
–Adapter
–Bridge
–Composite
–Decorator
–Façade
–Flyweight
–Proxy

57. Eliane Martins - Instituto de Computação - UNICAMP
Os padrões do GoF
•Comportamentais:
–Chain of Responsibility
–Command
–Interpreter
–Iterator
–Mediator
–Memento
–Observer
–State
–Strategy
–Template Method
–Visitor
Consultar o catálogo!

58. Eliane Martins - Instituto de Computação - UNICAMP
Como selecionar um padrão
•Examine a seção de Problemas do padrão.
•Considere como o padrão seleciona um determinado
problema.
•Estude como os padrões se interrelacionam.
•Estude padrões de finalidade semelhante.
•Determine a causa para a re-estruturação do projeto.
•Determine como o padrão podem melhorar o projeto.

59. Eliane Martins - Instituto de Computação - UNICAMP
Como usar um padrão
•Leia o padrão por inteiro, para ter uma visão geral.
•Estude as seções de descrição do problema e da solução.
•Olhe os exemplos de código do padrão.
•Escolha nomes para os elementos do padrão que façam
sentido para o contexto da aplicação.
•Defina as classes.
•Escolha nomes para as operações que façam sentido para o
contexto da aplicação.
•Implemente as operações de forma a apoiar as
responsabilidades e colaborações específicas da aplicação.
[Deschamps]

60. Eliane Martins - Instituto de Computação - UNICAMP
Padrões de projeto: utilizar ou não?
–Melhoram a estrutura de algo já
implementado, quando o domínio do
problema está bem compreendido
–Aumentam a compreensão do código
melhorando a modularidade,
separação de conceitos e
simplicidade de descrição
•ex.: é mais fácil dizer: “utiliza-se
uma instância do padrão Visitor do
que "este é um código que varre a
estrutura e realiza chamadas a alguns
métodos em uma ordem particular e de
uma determinada forma".
–Utilize padrões somente para
resolver problemas já
identificados no
projeto/código pois ...
–... podem diminuir a
capacidade de compreensão ao
introduzir acesso indireto e
aumentar a quantidade de
código

61. Eliane Martins - Instituto de Computação - UNICAMP
Onde obter mais informações
•Catálogo sobre padrões
–http://www.dofactory.com/Patterns/Patterns.aspx#list
•Tutorial sobre padrões:
–www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
objectives.html http://
•Padrões de projeto, Idiomas e Frameworks
–http://www.cs.wustl.edu/~schmidt/patterns.html
•Apresentação geral sobre padrões
–http://www.mindspring.com/~mgrand/pattern_synopses.htm

62. Eliane Martins - Instituto de Computação - UNICAMP
Outros Padrões
Ver slides: Padroes_manut_Regina_2009.pdf
(64-...)

63. Eliane Martins - Instituto de Computação - UNICAMP
Reuso - código
Ver meus slides

64. Eliane Martins - Instituto de Computação - UNICAMP
Sumário dos principais pontos aprendidos