Upload
internet
View
122
Download
0
Embed Size (px)
Citation preview
Eliane Martins - Instituto de Computação - UNICAMP
Melhoria da Manutenibilidade
Criado: Set/2005Atualizado: Nov/2010
Eliane Martins - Instituto de Computação - UNICAMP 2
Tópicos
• Manutenibilidade
• Técnicas para melhoria da manutenibilidade
• Métricas
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.
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)
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
• “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
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
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
– Ex.: padrões IBM para e-business (www128.ibm.com/developerworks/patterns/)
Apresentação
Controle do Negócio
Dados
Entradas do usuárioExibiçã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, ...
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)
• 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]
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
• 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
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
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
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
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
janelaWindows janelaMotif
BarraRolagemWindows
BarraRolagemMotif
Janela
usa
BarraRolagem
usa
usa
cria
cria
abstratas
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
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;
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]
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
Clienteusa
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)
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Decorator
Componente_visual
Desenhar()
Decorator
Desenhar()
Visualizador_Texto
Desenhar ()
BordaEspessura _borda
Desenhar()Desenhar_borda ()
Barra_RolagemPosição-rolagem
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
Facade
Subsistema ou componente
Interface única para o 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
Adapter- Servidor: servidor1+ void operacao_cliente ( )
Servidor- Servidor: servidor1+ void operacao_servidor ( )
Alvo
+ void operacao_cliente ( )
void operação_cliente( ){
servidor1.operação_servidor( )}
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Iterator
ImplemColeção
getIterator( ): Iterator
return new ImplemIterator (this)
ImplemIterator
IColeção
getIterator( ): Iterator
IIterator
hasNext( ): booleannext ( ): Object
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
Eliane Martins - Instituto de Computação - UNICAMP
Mediator
Mediador Colaborador
Mediador_concreto Colaborador_concreto1 Colaborador_concreto2
mediador
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
Eliane Martins - Instituto de Computação - UNICAMP
Exemplo: Observer
Observador
+update ( )
Observado
+attach (in Observer)+detach (in Observer)+notify ( )
*
Observado_concretoestado
+getEstado ( )
o {Observador}: o.update( )
Observador_concretoestadoObservado
+update ( )
estadoObservado = sujeito.getEstado( )
sujeito
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
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!
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".
– 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
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
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