Melhoria da Manutenibilidade
Criado: Set/2005
Atualizado: Nov/2010
Eliane Martins - Instituto de Computação - UNICAMP
Tópicos
• Manutenibilidade
• Técnicas para melhoria da manutenibilidade
• Métricas
Eliane Martins - Instituto de Computação - UNICAMP
2
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.
Eliane Martins - Instituto de Computação - UNICAMP
3
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)
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 ?
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
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.
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.
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.
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
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
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.
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!
Eliane Martins - Instituto de Computação - UNICAMP
Manutenibilidade
• Como medir ?
• Como conseguir ao longo do desenvolvimento?
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
Eliane Martins - Instituto de Computação - UNICAMP
Reutilização em Engenharia de Software
• “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
Eliane Martins - Instituto de Computação - UNICAMP
Níveis de Abstração
• 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
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.]
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
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].
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]
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.
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)
...
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
Apresentação
Entradas do usuário
Exibição de resultados na tela
Controle do Negócio  Lógica do negócio
Dados
 Comunicação com serviços: conexão
com banco de dados, troca de mensagens,
controle de transações, ...
– Ex.: padrões IBM para e-business (www128.ibm.com/developerworks/patterns/)
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
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)
Eliane Martins - Instituto de Computação - UNICAMP
Gang of Four (GoF)
•
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):
• E. Gamma and R. Helm and R.
Johnson and J. Vlissides.
Design Patterns - Elements of
Reusable Object-Oriented
Software. Addison-Wesley,
1995.
[Kon2005]
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]
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]
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo – padrão de teste de regressão
•
– Critérios de entrada:
Nome:
• 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
– 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 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
...
Não é do GoF, mas usou o mesmo formato de descrição
Eliane Martins - Instituto de Computação - UNICAMP
[Binder 2000, c.15]
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
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.
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]
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]
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo de utilização do abstract factory
Define uma interface para as operações que
criam objetos como produtos abstratos
IGuiAbstrata
GUIAbstrata
criaBarraRolagem ( )
criaJanela ( )
GUIMotif
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)
GUIWindows
criaBarraRolagem ( )
criaJanela ( )
criaBarraRolagem ( )
criaJanela ( )
Fábrica: Implementa as operações que
criam objetos para os produtos
concretos
concretas
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo de utilização do abstract factory
usa
IGuiAbstrata
cliente
usa
GUIAbstrata
abstratas
criaBarraRolagem ( )
criaJanela ( )
GUIMotif
GUIWindows
criaBarraRolagem ( )
criaJanela ( )
criaBarraRolagem ( )
criaJanela ( )
Janela
janelaWindows
usa
janelaMotif
BarraRolagem
cria
BarraRolagem
Windows
cria
Eliane Martins - Instituto de Computação - UNICAMP
BarraRolagem
Motif
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
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]
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]
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.
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Singleton
// SingletonImpl.java
public final class SingletonImpl {
private static SingletonImpl instance = null;
Singleton
private SingletonImpl() { ... }
static InstanciaUnica: Singleton
public static SingletonImpl getInstance() {
if (instance==null) {
instance = new SingletonImpl();
}
return instance;
}
static getinstance ( ): Singleton
retorna a
instância criada
}
// usando o sigleton
public class UsoDoSingletonImpl {
:
SingletonImpl obj;
:
obj = SingletonImpl.getInstance();
[Jandl2003]
:
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)
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Composite
Componente
Cliente
usa
+Operação ( )
+Adicionar (in Componente)
+Remover (in Componente)
+BuscarParte (in índice: int)
*
ImplemComponente
Composite
+Operação ( )
+Operação ( )
+Adicionar (in Componente)
+Remover (in Componente)
+BuscarParte (in índice: int)
Eliane Martins - Instituto de Computação - UNICAMP
1
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Decorator
Componente_visual
Desenhar()
Visualizador_Texto
Decorator
Desenhar ()
Desenhar()
Borda
Espessura _borda
Barra_Rolagem
Posição-rolagem
Desenhar()
Desenhar_borda ()
Desenhar()
Rolar ()
[Thelma2005]
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Facade
Interface única para o
subsistema ou componente
Facade
Subsistema ou componente
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
Eliane Martins - Instituto de Computação - UNICAMP
Adapter (wrapper)
Cliente
-Alvo: alvo1
Alvo
+ void operacao_cliente ( )
Adapter
- Servidor: servidor1
+ void operacao_cliente ( )
void operação_cliente( )
{
servidor1.operação_servidor( )
}
Eliane Martins - Instituto de Computação - UNICAMP
Servidor
- Servidor: servidor1
+ void operacao_servidor ( )
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Iterator
IColeção
getIterator( ): Iterator
IIterator
hasNext( ): boolean
next ( ): Object
ImplemColeção
getIterator( ): Iterator
return new ImplemIterator (this)
Eliane Martins - Instituto de Computação - UNICAMP
ImplemIterator
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
Eliane Martins - Instituto de Computação - UNICAMP
Mediator
Mediador
Mediador_concreto
mediador
Colaborador
Colaborador_concreto1
Eliane Martins - Instituto de Computação - UNICAMP
Colaborador_concreto2
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Observer
Observado
+attach (in Observer)
+detach (in Observer)
+notify ( )
*
Observador
+update ( )
o  {Observador}: o.update( )
Observado_concreto
estado
sujeito
Observador_concreto
estadoObservado
+update ( )
+getEstado ( )
estadoObservado = sujeito.getEstado( )
Eliane Martins - Instituto de Computação - UNICAMP
Os padrões do GoF
• Criação:
–
–
–
–
–
• Estruturais:
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Eliane Martins - Instituto de Computação - UNICAMP
–
–
–
–
–
–
–
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Os padrões do GoF
• Comportamentais:
–
–
–
–
–
–
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
–
–
–
–
–
Observer
State
Strategy
Template Method
Visitor
Consultar o catálogo!
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.
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]
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".
Eliane Martins - Instituto de Computação - UNICAMP
– 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
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
Eliane Martins - Instituto de Computação - UNICAMP
Outros Padrões
Ver slides: Padroes_manut_Regina_2009.pdf
(64-...)
Eliane Martins - Instituto de Computação - UNICAMP
Reuso - código
Ver meus slides
Eliane Martins - Instituto de Computação - UNICAMP
Sumário dos principais pontos aprendidos
Eliane Martins - Instituto de Computação - UNICAMP