Padrões de Reengenharia
Orientada a Objetos
Nome: Gewerton J. Gomes da Cruz Silva
Prof: Fabio Kon
1
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.
2
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.
3
Atividades de manutenção

Geralmente são realizadas quando é necessário:

Adicionar novas funcionalidades:



Adaptar o sistema a novas tecnologias emergentes:




Satisfazer novas regras do negócio.
Adaptar a novas políticas governamentais.
Software
Hardware
Corrigir erros que foram introduzidos em manutenções
anteriores do sistema.
Adicionar melhorias no sistema:


Facilitar manutenções futuras.
Melhorar a confiabilidade.
4
Termos relacionados a Reengenharia de
Software


Engenharia avante
Engenharia reversa




Redocumentação
Recuperação do projeto
Reestruturação
Reengenharia
5
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?
7
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.
8
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.
9
Representação dos conceitos
10
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.
11
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.
12
Mapa de padrões de Reengenharia
13
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.
14
Ler todo código em uma hora

Intuito – Fazer avaliação inicial da condição interna do

Problema – Precisa-se desta avaliação para planejar

Contexto:
sistema.
esforços da engenharia reversa.





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.
15
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.
16
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.
17
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.
18
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).
19
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.
20
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.
21
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.
22
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.
23
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.
24
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.
25
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.
26
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.
27
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.
28
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.
29
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.
30
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.
31
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.
32
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.
33
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.
34
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.
35
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.
36
FIM
37