Melhoria da Manutenibilidade Criado: Set/2005 Atualizado: Nov/2010

Tópicos Manutenibilidade Técnicas para melhoria da manutenibilidade Métricas 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. 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)

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 ?

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

Fatores de influência Modularidade Linguagem de programação 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.

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.

Fatores de influência Documentação Controle de Configuraçã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.

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

Fatores externos Equipe Domínio da aplicação 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

Fatores externos Idade do sistema Dependência do ambiente externo 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.

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!

Manutenibilidade Como medir ? Como conseguir ao longo do desenvolvimento?

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

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

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

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

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

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

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]

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.

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

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/) Entradas do usuário Exibição de resultados na tela Apresentação 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, ...

Padrões de Projeto e Idiomas 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

Outros padrões Padrões de análise Padrões de manutenção 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)

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]

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]

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]

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 ... Não é do GoF, mas usou o mesmo formato de descrição [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

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. Abstract Factory é diferente do FactoryMethod. Neste último, o cliente tem um método de criação (o dito Factory Method) enquanto que aqui, o cliente tem uma classe abstrata que possui métodos para isso.

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]

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]

Exemplo de utilização do abstract factory Define uma interface para as operações que criam objetos como produtos abstratos IGuiAbstrata GUIAbstrata criaBarraRolagem ( ) criaJanela ( ) 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) GUIMotif criaBarraRolagem ( ) criaJanela ( ) GUIWindows criaBarraRolagem ( ) criaJanela ( ) Fábrica: Implementa as operações que criam objetos para os produtos concretos AbstractFactory é um padrão muito útil para criar interfaces (GUI) portáteis para diversas plataformas (Motif, Windows, etc). Os objetos estão interligados pois não posso usar, por exemplo, uma janela estilo Windows com menu estilo Motif. Em Java, o pacote awt resolve esse problema pois ele implementa um Abstract FActory. Uma AbstractFactory concreta é geralmente um singleton (Linda Rising). concretas

Exemplo de utilização do abstract factory usa IGuiAbstrata cliente usa GUIAbstrata criaBarraRolagem ( ) criaJanela ( ) abstratas Janela usa janelaWindows janelaMotif BarraRolagem GUIMotif criaBarraRolagem ( ) criaJanela ( ) GUIWindows criaBarraRolagem ( ) criaJanela ( ) cria AbstractFactory é um padrão muito útil para criar interfaces (GUI) portáteis para diversas plataformas (Motif, Windows, etc). Os objetos estão interligados pois não posso usar, por exemplo, uma janela estilo Windows com menu estilo Motif. Em Java, o pacote awt resolve esse problema pois ele implementa um Abstract FActory. BarraRolagemWindows BarraRolagemMotif cria

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

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]

Abstract Factory - Conseqüências O padrão isola as classes concretas dos clientes; 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); promove a consistência de produtos (não há o perigo de misturar objetos de famílias diferentes); dificulta a criação de novos produtos ligeiramente diferentes (pois temos que modificar a fábrica abstrata e todas as fábricas concretas). [Kon2005]

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. Abstract Factory é diferente do FactoryMethod. Neste último, o cliente tem um método de criação (o dito Factory Method) enquanto que aqui, o cliente tem uma classe abstrata que possui métodos para isso.

Exemplo: Singleton Singleton static InstanciaUnica: 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(); Singleton static InstanciaUnica: Singleton static getinstance ( ): Singleton retorna a instância criada [Jandl2003]

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)

Exemplo: Composite * Componente +Operação ( ) +Adicionar (in Componente) +Remover (in Componente) +BuscarParte (in índice: int) usa * Cliente ImplemComponente +Operação ( ) Composite +Operação ( ) +Adicionar (in Componente) +Remover (in Componente) +BuscarParte (in índice: int) 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

Exemplo: Decorator Componente_visual Desenhar() Decorator Desenhar() Visualizador_Texto Desenhar () Borda Espessura _borda Desenhar() Desenhar_borda () Barra_Rolagem Posição-rolagem Desenhar() Rolar () [Thelma2005]

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

Exemplo: Facade Facade Interface única para o subsistema ou componente

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

Adapter (wrapper) Alvo + void operacao_cliente ( ) Cliente -Alvo: alvo1 Adapter - Servidor: servidor1 + void operacao_cliente ( ) void operação_cliente( ) { servidor1.operação_servidor( ) } Alvo: classe que implementa a interface requerida (esperada) pelo cliente. 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

return new ImplemIterator (this) Exemplo: Iterator IColeção getIterator( ): Iterator IIterator hasNext( ): boolean next ( ): Object ImplemColeção getIterator( ): Iterator ImplemIterator return new ImplemIterator (this)

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

Mediator Mediador Colaborador Colaborador_concreto1 Mediador_concreto

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

Exemplo: Observer * Observado Observador +attach (in Observer) +detach (in Observer) +notify ( ) Observador +update ( ) * o  {Observador}: o.update( ) Observado_concreto estado +getEstado ( ) Observador_concreto estadoObservado +update ( ) sujeito estadoObservado = sujeito.getEstado( )

Os padrões do GoF Criação: Estruturais: Abstract Factory Adapter Builder Factory Method Prototype Singleton Estruturais: Adapter Bridge Composite Decorator Façade Flyweight Proxy

Os padrões do GoF Comportamentais: Consultar o catálogo! Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Consultar o catálogo!

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.

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]

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

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

Outros Padrões Ver slides: Padroes_manut_Regina_2009.pdf (64-...)

Reuso - código Ver meus slides

Sumário dos principais pontos aprendidos