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

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

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

Apresentações semelhantes


Apresentação em tema: "Eliane Martins - Instituto de Computação - UNICAMP Melhoria da Manutenibilidade Criado: Set/2005 Atualizado: Nov/2010."— Transcrição da apresentação:

1

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

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

4 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, URL: JANDL, P. Jr. Uma Introdução aos Padrões de Projeto com Java Obtido na Internet em ago/2005. PRESSMAN, R.S. Sw Engineering: a Practitioners Approach. McGraw-Hill, 3ª ed, 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.

5 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 , 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 )

6 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 ?

7 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

8 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.

9 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.

10 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.

11 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

12 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

13 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.

14 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!

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

16 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

17 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

18 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

19 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.]

20 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

21 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, > 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].

22 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]

23 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.

24 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)...

25 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,...

26 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

27 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)

28 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, 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]

29 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]

30 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]

31 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

32 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

33 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.

34 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]

35 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]

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

37 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 cria abstratas

38 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

39 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]

40 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]

41 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.

42 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]

43 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)

44 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)

45 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

46 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]

47 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

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

49 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

50 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( ) }

51 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

52 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

53 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

54 Eliane Martins - Instituto de Computação - UNICAMP Mediator MediadorColaborador Mediador_concreto Colaborador_concreto1Colaborador_concreto2 mediador

55 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

56 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

57 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

58 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!

59 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.

60 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]

61 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

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

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

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

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


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

Apresentações semelhantes


Anúncios Google