1

Padrões de Reengenharia Orientada a Objetos

Nome: Gewerton J. Gomes da Cruz SilvaProf: Fabio Kon

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

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

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

Termos relacionados a Reengenharia de Software

Engenharia avante Engenharia reversa

Redocumentação Recuperação do projeto

Reestruturação Reengenharia

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

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

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

Representação dos conceitos

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

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

Mapa de padrões de Reengenharia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FIM