1 Padrões de Reengenharia Orientada a Objetos Nome: Gewerton J. Gomes da Cruz Silva Prof: Fabio Kon.

Apresentação em tema: "1 Padrões de Reengenharia Orientada a Objetos Nome: Gewerton J. Gomes da Cruz Silva Prof: Fabio Kon."— Transcrição da apresentação:

1 1 Padrões de Reengenharia Orientada a Objetos Nome: Gewerton J. Gomes da Cruz Silva Prof: Fabio Kon

2 2 Contexto  O software é um produto que evolui constantemente.  São realizadas diversas atividades de manutenção: Degradando o código fonte. Tornando-o difícil de mantê-lo. Normalmente a documentação não é atualizada. Estes são os chamados sistemas legados. Única documentação acaba sendo o próprio código fonte.

3 3 Qual a importância dos sistemas legados nas empresas?  É grande o interesse da empresa em manter estes softwares em funcionamento, pois: São considerados propriedades. Agregam lógicas do negócio codificadas. Investimento realizado. Anos de desenvolvimento e testes. Experiências. Estratégias empresariais.

4 4 Atividades de manutenção  Geralmente são realizadas quando é necessário: Adicionar novas funcionalidades:  Satisfazer novas regras do negócio.  Adaptar a novas políticas governamentais. Adaptar o sistema a novas tecnologias emergentes:  Software  Hardware Corrigir erros que foram introduzidos em manutenções anteriores do sistema. Adicionar melhorias no sistema:  Facilitar manutenções futuras.  Melhorar a confiabilidade.

5 5 Termos relacionados a Reengenharia de Software  Engenharia avante  Engenharia reversa Redocumentação Recuperação do projeto  Reestruturação  Reengenharia

6 6 Engenharia avante  Transferência de abstrações, modelos lógicos e projeto do sistema para uma implementação física.  Método mais tradicional de engenharia.

7 7 Engenharia reversa  Processo de análise de um sistema legado.  Identifica seus componentes e relacionamentos, e os representa em um nível mais alto de abstração.  Pode ser classificada como: Redocumentação – Criação ou revisão da representação da abstração semântica do sistema. Recuperação do projeto – Considera domínio do conhecimento e informações externas para identificar no sistema abstrações de alto nível.  O que o sistema faz?  Como?  Por que?

8 8 Reestruturação  Transformação de uma maneira de representação do sistema para outra no mesmo nível de abstração.  É preservado o comportamento externo: Funcionalidade Semântica  Este termo também é conhecido como Refatoração.

9 9 Reengenharia  Consiste na análise e alteração do sistema para reconstruí-lo em uma nova forma.  Também conhecida como Renovação.  Geralmente inclui Engenharia Reversa seguida por Engenharia Avante ou Reconstrução.  Transforma uma implementação concreta em outra implementação concreta.  Custo efetivo e menos riscos do que desenvolver um novo sistema.

10 10 Representação dos conceitos

11 11 Riscos associados à Reengenharia  Diversos riscos devem ser evitados no processo de reengenharia: Não cumprimento de prazo e custo estipulados. Ausência de garantia de qualidade do sistema resultante. Grande extensão e alto custo da documentação. Dificuldade de recuperar o projeto e requisitos a partir do código fonte. Perda do conhecimento do negócio embutido no código fonte. Dificuldade na migração dos dados existentes. Ausência de conhecimento e experiência dos envolvidos no projeto.

12 12 Padrões de Reengenharia  Codificam a gravam informações sobre as modificações do software legado. Ajudam a diagnosticar problemas. Detectam fraquezas. Facilita futuros desenvolvimentos adicionais do sistema. Ajuda a encontrar as soluções mais apropriadas para as novas exigências. Determina os problemas existentes no atual sistema, reparando-os. A Refatoração do código é apenas o último estágio deste processo.

13 13 Mapa de padrões de Reengenharia

14 14 Iniciação do sistema legado  Agrupa os padrões que mostram o que fazer quando se tem o primeiro contato com o sistema de software.  Alguns padrões desta etapa: Ler todo o código em uma hora. Estudar superficialmente a documentação. Entrevistar o usuário durante o sistema em execução.

15 15 Ler todo código em uma hora  Intuito – Fazer avaliação inicial da condição interna do sistema.  Problema – Precisa-se desta avaliação para planejar esforços da engenharia reversa.  Contexto: A condição interna do sistema varia muito. Alguns sistemas possuem muitas linhas de código. Falta de familiaridade do engenheiro de software com o sistema. Tem-se o código fonte disponível como informação confiável. O engenheiro têm boa habilidade com a linguagem usada no sistema legado.

16 16 Ler todo o código em uma hora (cont.)  Solução: Ler o código fonte sem ser interrompido. Anote pouca coisa, maximizando o contato com o código. Gaste mais uma hora criando um relatório:  Entidades importantes (classes, packages).  Estilo de código de difícil interpretação.  Dê nome as entidades de acordo como são mencionadas no código fonte.  Padrões relacionados – Juntamente com o padrão Estudar Superficialmente a Documentação, eles maximizam a chance de se obter uma visão coerente do sistema.

17 17 Estudar Superficialmente a Documentação  Intuito – Supor a funcionalidade do sistema por meio da leitura da documentação existente.  Problema – Planejar os esforços necessários para a realização da engenharia reversa a a partir da idéia inicial do sistema.  Contexto: A funcionalidade do sistema muda com o tempo. Alguns sistemas possuem muitas linhas de código. A falta de familiaridade do engenheiro com o sistema. Tem-se a documentação disponível. O engenheiro é capaz de interpretar especificações formais do sistema.

18 18 Estudar Superficialmente a Documentação (cont.)  Solução: Ler a documentação sem ser interrompido. Faça pouca anotação para facilitar o contato com a documentação. Utilize mais uma hora para montar um relatório:  Requisitos importantes.  Características importantes.  Limitações importantes.  Referências para informações relevantes do projeto.  Padrões relacionados – O padrão Entrevistar o Usuário Durante o Sistema em Operação pode ajudar a coletar uma lista de entidades que se deseja analisar na documentação.

19 19 Entrevistar o Usuário Durante o Sistema em Operação  Intuito – Obter a idéia inicial da funcionalidade do sistema observando-o em operação.  Problema – Dimensionar os esforços necessários para realizar a engenharia reversa através: Cenários típicos de uso. Funcionalidades do sistema.  Contexto: Variação do uso de cenários entre diferentes usuários. É difícil obter a partir do usuário o que há de errado no sistema. O engenheiro de software tem acesso a pessoas chaves na organização (usuários, gerentes, técnicos).

20 20 Entrevistar o Usuário Durante o Sistema em Operação (cont.)  Solução: Observar o sistema em operação através da sua demonstração e entrevistar o usuário. Produzir um relatório contendo suas constatações:  Alguns cenários típicos.  Características principais (apreciadas ou não).  Componentes (encapsulamento) do sistema e suas responsabilidades.  Padrões relacionados – Dependendo da complexidade do sistema, pode-se exercitar esse padrão antes, depois ou durante o uso dos padrões Ler Todo Código em Uma Hora e Estudar Superficialmente a Documentação.

21 21 Entendimento Inicial  Agrupa os padrões que descrevem como obter um entendimento inicial de um sistema de software documentado, principalmente, com diagramas de classes.  Alguns padrões desta etapa: Presumir prováveis objetos. Examinar o banco de dados. Inspecionar as maiores construções. Explorar possíveis modificações.

22 22 Presumir Prováveis Objetos  Intuito – Refinar, progressivamente um modelo de objetos de acordo com o código fonte.  Problema – Não se sabe como os conceitos de negócio estão mapeados em classes no código.  Contexto: Existem muitos conceitos no sistema, assim há várias maneiras de representá-los na linguagem utilizada. Entende-se a funcionalidade do sistema. Devido a experiência do engenheiro ele pode imaginar como modelar o sistema. Muito das linhas de código não tem relação com a representação dos conceitos do sistema, mas sim com a solução.

23 23 Presumir Prováveis Objetos (cont.)  Solução: Idealizar um modelo hipotético de classes do sistema. Refinar o modelo verificando se os nomes das classes ocorrem no código fonte e adaptando-o. Repita o processo até que o modelo se estabilize.  Modelo de classes que sirva de hipótese inicial.  Relacionar os nomes num diagrama de classes tentando encontrá-los no código fonte.  Anotar nomes que aparecem ou não no código.  Adaptar o modelo de classes baseado nas discordâncias.  Padrões relacionados – Todos os padrões de Iniciação ao Sistema Legado auxiliam na construção deste modelo hipotético de classes.

24 24 Examinar o banco de dados  Intuito – Adequar o modelo de objetos, obtido no padrão anterior, com o banco de dados do sistema.  Problema – Não se conhece quais os objetos que são críticos para a funcionalidade do sistema.  Contexto – Reconstruir o modelo de classes a partir das tabelas do banco de dados relacional.

25 25 Examinar o Banco de Dados (cont.)  Solução: Derivar um modelo de classes representando as entidades que estão armazenadas em tabelas no banco. Os seguintes passos devem ser aplicados;  Construir um modelo de classes (cada tabela = classe)  Selecionar como atributos o nome das colunas da tabela.  Selecionar relacionamentos entre tabelas considerando associação entre classes.  Verificar relacionamentos um-para-um como herança.  Padrões relacionados – Este padrão requer um entendimento inicial do sistema, o qual é obtido com o padrão Presumir Prováveis Objetos.

26 26 Inspecionar as maiores construções  Intuito – Identificar trechos importantes de código inspecionando as maiores construções.  Problema – Não se sabe onde está implementada uma funcionalidade importante em milhares linhas de código.  Contexto: Não é fácil saber o que é mais ou menos importante no código. Muitas linhas de código torna difícil uma avaliação correta. Utilizando ferramentas de determinação de métricas é possível quantificar o tamanho das entidades.

27 27 Inspecionar as Maiores Construções (cont.)  Solução: Usar ferramentas de determinação de métricas para coletar um conjunto limitado de medidas sobre as entidades. Represente os resultados de forma que seja fácil avaliar diferentes medidas para uma mesma entidade.  Padrões relacionados – O padrão Explorar Possíveis Modificações pode ser usado para focar nas partes do sistema que mudaram nas diferentes versões.

28 28 Explorar Possíveis Modificações  Intuito – Reconstruir o processo iterativo da construção do sistema, pela comparação de versões.  Problema – Recuperar o que os desenvolvedores do sistema alteraram no desenvolvimento e manutenções.  Contexto: O sistema tem sido modificado através de novas atualizações de versões. Comparar diversas versões é muito trabalhoso. Algumas ferramentas mostram as alterações realizadas em cada versão, a partir da análise do código. Devido a experiência do engenheiro ele pode inferir porque certas modificações foram aplicadas.

29 29 Explorar Possíveis Modificações (cont.)  Solução – Usar ferramentas de determinação de métricas para comparar medidas das versões (aumentaram ou diminuíram).  Padrões relacionados - O padrão Inspecionar as Maiores Construções pode ser usado para descobrir as partes do sistema que mudaram entre as versões.

30 30 Detalhamento do sistema  Agrupa os padrões que mostram como obter um entendimento detalhado de um determinado componente em seu sistema de software.  Alguns padrões desta etapa: Verificar as Invocações de Métodos. Observar a Execução dos Componentes.

31 31 Verificar as Invocações de Métodos  Intuito – Saber como uma classe está relacionada com outra.  Problema – Obter relacionamento entre classes.  Contexto: Neste estágio tem-se uma visão global da funcionalidade do sistema. Com uma ferramenta adequada pode-se identificar onde o método está definido a partir de sua chamada.  Solução – Através da inspeção de uma chamada do método, encontrar a definição do mesmo.  Padrões relacionados – Os padrões Inspecionar as Maiores Construções e Explorar Possíveis Modificações pode ajudar a descobrir funcionalidades importantes.

32 32 Observar a Execução dos Componentes  Intuito – Obter um entendimento detalhado do comportamento de uma parte do sistema, executando seus componentes.  Problema – É preciso obter um entendimento detalhado sobre uma parte encapsulada do código.  Contexto: Baseado no entendimento do do sistema pode-se selecionar trechos de código para inspeção. Com um depurador é possível se interagir com a execução.

33 33 Observar a Execução dos Componentes (cont.)  Solução: Alimentar a entrada do pedaço de código fonte para se obter uma seqüência normal de operações. Usar um depurador para acompanhar a execução passo a passo.  Inspecionar o estado interno do pedaço de código.  Padrões relacionados – Os padrões Inspecionar as Maiores Construções e Explorar Possíveis Modificações podem ser usados para descobrir funcionalidade importante a ser avaliada.

34 34 Preparação da Reengenharia  Possui um padrão que ajuda a preparar os passos subseqüentes da reengenharia.  Padrão desta etapa: Refazer para entender.

35 35 Refazer Para Entender  Intuito – Obter um melhor entendimento de uma parte específica do código fonte, refazendo-a.  Problema – Compreender um particular trecho de código que aparenta ser importante mas é muito difícil de analisá-lo.  Contexto: Código sem documentação é difícil de se ler. Alterar código se documentação pode causar efeitos colaterais.

36 36 Refazer Para Entender (cont.)  Solução: Renomear interativamente e refazer o código.  Remover código duplicado (criando métodos).  Substituir trechos condicionais por métodos.  Substituir trechos de código longo por métodos.  Renomear atributos com nome significativos.  Renomear métodos com intuitos significativos.  Renomear classes com propósitos significativos.  Padrões relacionados – Para ajudar a entender a funcionalidade, pode-se usar o padrão Observar a Execução dos Componentes.

37 37 FIM