FIPLAC – Faculdades Integradas Do Planalto Central

Engenharia De Software

Prof.ª: Gilene

MANUTENÇÃO
DE SOFTWARE

Alan Pereira Lima

Robson Felix
Turma: C06A
2000

1
ÍNDICE

INTRODUÇÃO 3
DESENVOLVIMENTO
DEFINIÇÃO DE SOFTWARE 4
CARACTERÍSTICAS DA MANUTENÇÃO 5
Manutenção Estruturada versus Não-Estruturada 5
Custo de Manutenção 6
Problemas 6
MANUTENIBILIDADE 7
Fatores Controladores 8
Medidas Quantitativas 8
Revisões 9
TAREFAS DA MANUTENÇÃO 9
Uma Organização para a Manutenção 10
Relatórios 10
Fluxo de Eventos 11
Conservação de Registros 12
Avaliação 13
EFEITOS COLATERAIS NA MANUTENÇÃO 14
Efeitos Colaterais na Codificação 14
Efeitos Colaterais nos Dados 15
Efeitos Colaterais na Documentação 15
MANUTENÇÃO DE CÓDIGO ALIENÍGENA 16
ENGENHARIA REVERSA E REENGENHARIA 17
Manutenção Preventiva 18
Elementos de Engenharia Reversa 18
Uma técnica de Reestruturação P/ Reengenharia 19
CONCLUSÃO 21
ANEXO 22
BIBLIOGRAFIA 23

2
 INTRODUÇÃO

Considerada como a fase cujo a organização desprende maior esforço, a

Manutenção do Software consome mais de 70% da atenção da organização. Essa
percentagem continua aumentando gradativamente a medida que os softwares continuam
sendo produzidos, ou mesmo a manutenção de software de 10 a 15 anos de idade que na
realidade continuam sendo a espinha dorsal de grandes organizações.
As manutenções hoje pensa-se em organizações de manutenção que não podem
produzir softwares, porque estão gastando tempo e dinheiro em manter seus produtos
“rodando”.

3
 DESENVOLVIMENTO

DEFINIÇÃO DE SOFTWARE

Contudo, a manutenção é certamente mais do que concertar o erro que não foi
achado nas fases anteriores a implantação, a manutenção consiste em quatro atividades
que são levadas a efeito somente depois que o programa é liberado para uso. São elas:
• Manutenção Corretiva: pois seria impossível descobrir todos os erros de um
grande software na fase de testes, por isso é feito um diagnóstico e feito um
relatório ao desenvolvedor;
• Manutenção Adaptativa: pois as mudanças na própria plataforma onde o
sistema é aplicado sejam de hardware ou outros softwares dedicados, nos
levam a adaptação do ambiente do sistema;
• Manutenção Perfectiva: por estar rodando tão bem, as vezes o projetista tende
ao perfeccionismo fazendo no ambiente do software novas modificações,
claro que tudo a pedido também do usuário;
• Manutenção Preventiva: toda modificação feita para prevenir a manutenção
problemática no futuro e confiabilidade onde são aplicadas técnicas de
engenharia reversa e reengenharia.
Tarefas como a adaptação a novos ambientes ou novas capacidades bem com a
prevenção de manutenção também são aplicadas nas fases de desenvolvimento do
processo e por se repetirem diversas vezes acabaram tornando-se manutenções. Existem
porém varias outras manutenções, como a manutenção do próprio hardware que
analogamente não se compara com o software, pois a máquina com o passar dos anos
vai a precisar de reparos devido o seu desgaste.

4
 CARACTERISTICAS DA MANUTENÇÃO:

O estudo da manutenção dos sistemas é uma literatura que quase não eram
abordada, comparada as atividades de desenvolvimento do projeto, dai a conclusão por
existirem poucos métodos técnicos ou abordagens.
Antes da descrição das características, existem três pontos de vista a serem
levados em conta:
• Atividades exigidas para que ocorra a manutenção e o impacto nos sistemas
sem a mesma;
• Custos associados à fase de manutenção do sistema;
• Os problemas encontrados quando a manutenção é feita.

Manutenção Estruturada versus Não-Estruturada

Ao atender a um pedido de manutenção de um sistema, a prestadora deste

serviço, seja a desenvolvedora ou não, poderá encontrar dois tipos de manutenção a ser
feita: - A primeira cujo o custo será bastante elevado trata-se de um software
desenvolvido sem metodologia bem-definida e que acarretará sérios problemas até
mesmo para a prestadora. Resultara numa manutenção feita com base por exemplo, no
código-fonte ou numa documentação interna ruim que a trará modificações difíceis de
ser avaliadas, falhas antigas não seram detectadas pois não há registros delas e etc.
Fazendo assim um esforço perdido e uma frustração humana é a Manutenção Não-
Estruturada. - A Segunda cujo o custo e menor e os recursos com garantia de aplicação
apoiam-se em um software com uma configuração completa, em que a documentação do
projeto existe, todas a modificações ou correções exigidas são avaliadas e planejadas. O
projeto é modificado, revisado e testado e liberado novamente sem problemas é a
Manutenção Estruturada.

5
 Custo de Manutenção

Como a maior parte do esforço é gasto na fase de manutenção, não poderia ser
diferente que as organizações também gastassem quase que 80% do orçamento ao faze-
la, índice que só veio a aumentar durante as décadas. A preocupação dos projetistas é
que nem sempre o que e pedido pelo usuário e tão simples quanto parece ser dito. As
mudanças estão ficando mais longas para que possamos implementa-las nos custos
iniciais previstos.
Um custo intangível da manutenção de software é a oportunidade de
desenvolvimento que é postergada ou perdida porque os recursos disponíveis devem ser
canalizados para tarefas de manutenção. Outros custos intangíveis incluem:
(PRESSMAN95)
• Insatisfação do cliente quando solicitações aparentemente legítimas de reparo
ou modificação não podem ser encaminhadas oportunamente quanto ao
tempo;
• Redução da qualidade global do software como resultado de mudanças que
introduzem erros latentes no software mantido;
• Sublevações causadas durante os esforços de desenvolvimento quando o
pessoal precisa ser “empurrado” para trabalhar numa tarefa de manutenção.
O custo final da manutenção de software é uma drástica diminuição de
produtividade que é encontrada quando a manutenção da programas antigos é iniciada.
Reduções de produtividade de 40:1 ou um desenvolvimento que custe 25 dólares por
linha de código passe a custar 1000 dólares por linha de código.(PRESSMAN95)

Problemas

Os problemas que venham a acontecer com o sistema tem por origem as

deficiências na maneira de como foi planejado e desenvolvido, a frase “o barato, quase

6
sempre sai caro” adequa-se muito bem a estes problemas também e por fim a falta de
controle e disciplina nas atividades desenvolvimento da engenharia de software.
Dentre os problemas clássicos que podem estar associados a manutenção de
software estão: (PRESSMAN95)

• Difícil e/ou impossível acompanhamento da evolução do software, quase

sempre sem documentação;
• Difícil e/ou impossível acompanhamento do processo de criação do software;
• Dificuldade na interpretação de programas elaborados por outra “pessoas”;
• Pela não existência da documentação as outras “pessoas” não se dispõem a
colaborar com a manutenção do software desenvolvidos por eles;
• A maioria do software não é projetado para receber as
mudanças(“curativos”);
• A manutenção é assim tida como um trabalho desgastante e pouco
reconhecido. (PRESSMAN95)
Os problemas acima descritos poderiam em parte ser minimizados ou mesmo
nem terem existido, se fossem aplicados a todos os programas em fase de
desenvolvimento a engenharia de software, que traria uma metodologia ou
padronização das formas de desenvolvimento e ainda com ela poderia ser
encontradas soluções para os problemas.
Existem outras questões técnicas a serem avaliadas além das características da
manutenção do software, questões que envolvem a parte administrativa com relação ao
problemas associados a manutenção; é possível desenvolver um software que seja bem
projetado e fácil de ser mantido?, e como ficaria a integridade de um programa após
varias manutenções? e será que existem abordagens que podem ser aplicadas a
manutenção de software? o que fazer para solucionar estes e outros problemas?.
Veremos a seguir.

MANUTENIBILIDADE

7
 A manutenibilidade diz respeito a facilidade com que um software pode ser
entendido, corrigido, adaptado e/ou aumentado. Logo verificamos que nada mais é do
que senão a orientação a ser seguida passo a passo pela engenharia de software para
elaboração bem definida de um projeto.

Fatores Controladores

A manutenibilidade influe sobre vários aspectos como a negligência no projeto,

na codificação e no teste que resultam em um impacto negativo sobre a capacidade de
manter o software resultante, então se a configuração de um software é um, mesmo
utilizando de todos os passos técnicos isso resultará em uma manutenção “ineficiente”.
Além dos fatores dependentes da metodologia de desenvolvimento outros fatores
podem contribuir com relação ao ambiente de desenvolvimento, isto é contribuindo para
a melhor manutenibilidade. São eles: (PRESSMAN95)
• Disponibilidade de um pessoal de software qualificado;
• Estrutura de sistema compreensível;
• Facilidade de manuseio do sistema;
• Uso de linguagens de programação padronizadas;
• Estrutura de documentação padronizada;
• Disponibilidade de casos de teste;
• Facilidades de depuração embutidas;
• Disponibilidade de um computador adequado para realizar a manutenção.
As pessoas que participaram da implantação inicial do projeto também são
indispensáveis .

Medidas Quantitativas

Elementos como a qualidade, confiabilidade e a própria manutenibilidade são

termos difíceis de se quantificar, isto é existe segurança ou não, de que adianta uma
manutenção que não dá, como resultados benefícios aos usuários, mas indiretamente

8
podem ser avaliados uma série de métricas da manutenibilidade que relacionam o tempo
e os esforços despendidos durante a manutenção. São eles:
• Tempo de reconhecimento do problema;
• Tempo de retardo administrativo;
• Tempo de coleta de ferramentas de manutenção;
• Tempo de análise do problema;

• Tempo de especificação das mudanças;

• Tempo de correções (ou modificações) ativas;
• Tempo de testes locais;
• Tempo de testes globais;
• Tempo de revisão de manutenção;
• Tempo de recuperação total.
Estas métricas não são difíceis de serem registradas e podem compreender com
uma importante ferramenta de análise técnica e administrativa. Além do tempo
desprendido e esforço, podem contar para as métricas da manutenibilidade a medida das
estruturas do projeto e a complexidade do software.

Revisões

Durante a revisão dos requisitos, as áreas de futuros acréscimos e potencial de

revisão são anotados , as questões de portabilidade do software são discutidas e as
interfaces do sistema que poderiam causar um impacto sobre a manutenção do software
são consideradas e todas as características de manutenibilidade devem ser observadas.
Todas as revisões desde a do projeto até o projeto de interfaces são avaliados a facilidade
de modificação e qualidade do projeto como o todo.
A revisão de manutenção mais formal ocorre durante a conclusão da atividade de
testes e é denominada revisão de configuração que assegura que todos os elementos da
configuração do software estejam completos, compreensíveis e arquivados para ter
controle das modificações. (PRESSMAN95)

9
 TAREFAS DE MANUTENÇÃO

Antes que o pedido de manutenção seja feito, algumas tarefas precisam estar
estabelecidas como procedimento de avaliação, relatórios devem ser descritos e uma
seqüência de eventos padronizada deve ser definida para cada pedido de manutenção.
Além disso devem constar o registro das atividades de manutenção, critérios de
avaliação e revisão.

Uma Organização para a Manutenção

Para cada estrutura organizacional existe uma organização de software, isto é

para cada “criatura” existe o seu “criador”, porém na manutenção as organizações foram
evitadas, claro com raras exceções a manutenção é executada à base de livre
concorrência.
Muito embora, existem estruturas internas as organizações, no qual estão
incumbidas responsabilidades para execução das tarefas. Todas as manutenções são
repassadas a um controlador de manutenção que por sua vez repassa ao supervisor de
sistemas logo após fazer um breve rateio nos pedidos. O supervisor de sistemas como
sua função examina quais os pedidos tem realmente nexo e acompanha na manutenção
deste todas as ações tomadas.
Neste esquema, a organização ganha em melhora do fluxo de atividade de
manutenção. Uma vez que a atividade de avaliação fica emcubida por profissionais que
avaliaram a necessidade ou não da manutenção.

Relatórios

Todos os pedidos de manutenção devem ser apresentados na forma de

formulários de pedido de manutenção, pois isso gera uma documentação para
posteriores manutenções onde ficam guardados os erros antigos do software e testes.
Mais conhecido como relatório de problemas de software ele deve ser preenchido pelo
usuário solicitante do pedido, e que deveram constar todas a informações a respeito do

10
erro, inclusive entradas, listagens e materiais de apoio. Para pedidos de manutenção
Adaptativa ou Perfectiva basta que sejam descritos as mudanças com especificação
abreviada das funções. Todos os relatórios são encaminhados ao controlador de
manutenção e repassados ao supervisor de sistemas para análise. O formulário ou
relatório é para uso externo da organização, para uso interno é destinado um outro
relatório chamado de relatório de mudanças de software onde são destacados aspectos
como esforço exigido na modificação, natureza da modificação, prioridade do pedido e
dados posteriores ao fato sobre a modificação. Este relatório também é avaliado pelo
supervisor de sistemas. (PRESSMAN95)

Fluxo De Eventos

A seqüência de eventos que ocorre como resultado de um pedido de manutenção

encontra-se no gráfico (Vide Anexo). O primeiro requisito consiste em determinar o tipo
de manutenção que deve ser realizado. Em muitos casos, um usuário pode ver um
pedido como indicação de erro de software (manutenção corretiva) enquanto um
desenvolvedor pode ver o mesmo pedido como uma adaptação ou acréscimo. Se existir
uma diferença de opinião pode ser negociado. (PRESSMAN95)
Em relação ao fluxo mostrado na figura, um pedido de manutenção corretiva
(caminho erro) inicia-se com uma avaliação da gravidade do erro. se existir um erro
grave (por exemplo, um sistema crítico não pode funcionar), é designada uma equipe
sob a direção do supervisor de sistemas e análise do problema inicia-se imediatamente.
Erros menos graves, o pedido de manutenção corretiva é avaliado e caracterizado, e
depois programado em conjunto com outras tarefas que exijam recursos de
desenvolvimento de software.
Em alguns casos ,um erro pode ser tão grave que os controles normais de
manutenção devem ser abandonados temporariamente. O código deve ser imediatamente
modificado, sem uma correspondente avaliação dos efeitos colaterais e uma apropriada
atualização da documentação. O modo “apaga incêndio” para a manutenção corretiva é
reservado somente para situações de “crise” e deve representar uma porcentagem muito
pequena de todas as atividades de manutenção. Nota-se que o “apaga incêndio” adia,

11
mas não elimina, a necessidade de ter controles e avaliações. Depois que a crise tiver
sido resolvida, essas atividades devem ser realizadas a fim de garantir que os reparos
atuais não prorrogarão problemas mais graves.
Os pedidos de manutenção adaptativa e perfectiva seguem um caminho diferente.
As adaptações são avaliadas e categorizadas (priorizadas) antes de serem colocadas
numa fila para sofrer manutenção. Os acréscimos passam pela mesma avaliação. No
entanto, nem todos os pedidos de acréscimo são levados a efeito e os acréscimos que
devem ser feitos também são colocados na fila de manutenção. A prioridade de cada
pedido é estabelecida e o trabalho exigido é programado como se fosse outro esforço de

desenvolvimento. Se uma prioridade extremamente elevada for estabelecida, o trabalho

pode iniciar-se imediatamente. (PRESSMAN95)
Entre as atividades de manutenção incluem-se modificação do projeto de
software, revisões, modificações necessárias do código, testes unitários e de integração e
testes de validação. A manutenção de Software é uma atividade de engenharia de
software aplicada recursivamente. A cada tipo de manutenção a ênfase será modificada,
mas a bordagem global continuará a mesma. O evento final do fluxo de manutenção é
uma revisão que revalida todos os elementos da configuração do software e garante que
tenha sido de fato, preenchido. (PRESSMAN95)
Ao terminar a tarefa de manutenção do software, é concluído que , muitas vezes
é uma boa idéia realizar uma revisão da situação, pode ter uma importante influência
sobre a realização dos esforços de manutenção futuros e oferecer um feedback que é
importante a para o efetivo gerenciamento de uma organização de software.

Conservação De Registros

A conservação de registros para todas as fases do processo de engenharia de

software tem sido inadequada, porque a conservação de registros sobre a manutenção de
software não esta ocorrendo. Por esse motivo, freqüentemente não podemos avaliar a
efetividade das técnicas de manutenção, somos incapazes de determinar a qualidade de

12
um programa de produção e não temos disposição para determinar quanto custa
realmente a manutenção. (PRESSMAN95)
Um dos problemas encontrados na conservação de registros sobre manutenção
consiste em entender quais dados valem a pena ser guardados. Swanson [SWA76]
apresenta uma lista abrangente:
• Identificação do programa.
• Número de instruções-fonte.
• Número de instruções de código de máquina.
• Linguagem de programação usada.
• Data de instalação do programa.
• Número de execuções do programa desde a instalação.

• Número de falhas de processamento associadas ao item #6.

• Identificação e nível de mudança do programa.
• Número de instruções-fonte adicionadas pela mudança no programa.
• Número de instruções-fonte supridas pela mudança no programa.
• Número de pessoas-hora empregadas por mudança.
• Data de mudança no programa.
• Identificação do engenheiro de software.
• Identificação do MRF.
• Tipo de manutenção.
• Datas de inicio e encerramento da manutenção.
• Número cumulativo de pessoas/hora empregadas em manutenção.
• Benefícios líquidos associados à manutenção realizada.
Os dados acima são compilados em cada esforço de manutenção Swason propõe
esses itens como base para um banco de dados sobre manutenção.

Avaliação

13
 Uma avaliação das atividades de manutenção do software freqüentemente é
complicada pela falta de dados concretos. Se uma conservação de registros for iniciada,
uma série de medidas do desempenho de manutenção pode ser desenvolvida.
Apresentamos uma lista abreviada de medidas em potencial propostas por Swanson
[SWA76]:
• Número médio de falhas de processamento por execução do programa.
• Total de pessoas/hora empregadas em cada categoria de manutenção.
• Número médio de mudanças de programa feitas por programa, por linguagem
e por tipo de manutenção.
• Número médio de pessoas/hora empregadas por instruções-fonte adicionadas
ou suprimidas devido à manutenção.
• Média de pessoas/hora empregadas por linguagem.
• Tempo médio de renovação do MRF.

• Porcentagem de pedidos de manutenção por tipo.

As medidas acima descritas podem proporcionar uma estrutura quantitativa a
partir da qual podem ser tomadas decisões sobre a técnica de desenvolvimento, escolha
da linguagem, projeções sobre o esforço de manutenção, alocação de recursos e muitas
outras questões. Os dados podem ser aplicados para avaliar a tarefa de manutenção.
(PRESSMAN95)

EFEITOS COLATERAIS DA MANUTENÇÃO

A modificação do software é perigosa. A documentação de projeto e cuidadosos

testes de regressão ajudam a eliminar o erro, mas serão encontrados efeitos colaterais da
manutenção. O termo “efeitos colaterais” implica um erro ou outro comportamento
indesejável que ocorra como resultado de uma modificação. Freedman e Weinberg
[FRE90] definem três grandes categorias para os efeitos colaterais, são as seguintes:

14
efeitos colaterais na codificação, efeitos colaterais nos dados e efeitos colaterais na
documentação.

Efeitos Colaterais Na Codificação

Comunicamo-nos com uma máquina usando um código-fonte de linguagem de

programação. As oportunidades para o acontecimento de efeitos colaterais são
abundantes. Não obstante cada modificação de código tenha um potencial para a
introdução e erros, o seguinte conjunto de mudanças [FRE90] tende a ser mais propenso
a erros do que outros:
• Um subprograma é apagado ou mudado.
• Um label de instrução é apagado ou modificado.
• Um identificador é apagado ou modificado.
• Mudanças são feitas para melhorar o desempenho de execução.
• A abertura ou fechamento de arquivos é modificada.
• Operadores lógicos são modificados.
• Mudanças de projeto são convertidas em grandes mudanças de código.

• Mudanças são feitas nos testes lógicos de condições de fronteira.

Os efeitos colaterais da codificação variam de erros maçantes detectados e

remediados e detectados durante os testes de regressão a problemas que fazem o
software falhar durante a operação.

Efeitos Colaterais Nos Dados

Durante a manutenção, freqüentemente são feitas modificações em elementos

individuais de uma estrutura de dados ou na própria estrutura. Quando dados são
mudados, o projeto do software já não encaixa esses dados, e erros podem ocorrer. Os

15
efeitos colaterais nos dados ocorrem como resultado de modificações feitas na estrutura
de informações do software. (PRESSMAN95)
As seguintes mudanças [FRE90] nos dados freqüentemente resultam em efeitos
colaterais:
• Redefinição de constantes locais e globais.
• Redefinição de formatos de registros ou arquivos.
• Aumento ou diminuição no tamanho de um array ou de uma estrutura de
dados de nível mais alto.
• Modificação em dados globais.
• Reinicialização de sinais de controle ou indicadores.
• Rearranjo de argumentos para E/S ou subprogramas.
Os efeitos colaterais nos dados podem ser limitados mediante uma documentação
de projeto cuidadosa que descreva a estrutura de dados e forneça uma referência cruzada
que associe elementos de dados, registros, arquivos e outras estruturas aos módulos de
software.

Efeitos Colaterais Na Documentação

A manutenção deve concentrar-se em toda a configuração do software e não

somente nas modificações no código-fonte. Os efeitos colaterais da documentação

acontecem quando as mudanças no código-fonte não são refletidas na documentação do

projeto ou nos manuais destinados ao usuário.
Quando é feita alguma mudança no fluxo de dados, na arquitetura do projeto, no
procedimento modular ou em qualquer outra característica relacionada, deve-se atualizar
a documentação técnica de apoio. Os efeitos Colaterais acontecem em subsequentes
esforços de manutenção quando um inocente exame de documentos técnicos leva a uma
avaliação incorreta das características do software. (PRESSMAN95)

16
 Para um usuário, o software é tão bom quanto a documentação (tanto escrita
como interativa) que descreve o seu uso. Se as modificações no software executável não
se refletirem na documentação do usuário, os efeitos colaterais estarão garantidos.
Os efeitos colaterais na documentação podem ser reduzidos substancialmente se
toda a configuração for revista antes do relançamento do software. Alguns pedidos de
manutenção talvez não exijam nenhuma mudança no projeto de software ou no código-
fonte, mas podem indicar uma falta de clareza na documentação do usuário.
(PRESSMAN95)

MANUTENÇÃO DE CÓDIGO ALIENÍGENA

Algumas organizações de software amadurecidas precisam manter programas

que foram desenvolvidos há 15 anos ou mais. Tais programas são às vezes denominados
“ código alienígena” devido a nenhum membro atual do pessoal técnico trabalhou no
desenvolvimento do programa; nenhuma metodologia de projeto foi aplicada e , por
conseguinte . o resultado é um projeto arquitetural e de dados ruim; a documentação é
incompleta e o registro das mudanças passadas é superficial.
Algumas técnicas para o manuseio do código alienígena. Yuurdon [YOU75]:
• Estude o programa antes de entrar no modo de emergência. Tente obter maior
quantidade de informação de background possível.
• Tente familiarizar-se com o fluxo global de controle do programa; ignore
detalhes de codificação a principio.
• Avalie a racionalidade da documentação existente; insira seus próprios
comentários na listagem (fonte) se achar que ajudarão.

• Tenha cuidado a fazer mudanças no programa. Respeite o estilo e formatação

do programa, se possível. Indique na própria listagem quais instruções você
modificou.
• Evite o irracional impulso de jogar o programa e reescrevê-lo.
• Insira verificação de erros.
• outras técnicas.

17
 Cada uma dessas diretrizes ajudará na manutenção de programas antigos.

ENGENHARIA REVERSA E REENGENHARIA

O termo engenharia reversa tem suas origens no mundo do hardware. A

engenharia reversa no software é muito semelhante. Na maioria dos casos, porém, o
programa que passará por engenharia reversa não é o de um concorrente e sim o próprio
trabalho da empresa (freqüentemente feito a anos). Os segredos a serem entendidos são
obscuros, porque nenhuma especificação jamais foi desenvolvida. No entanto, a
engenharia reversa para o software é o processo de analisar um programa, num esforço
para criar uma representação do programa em um nível de abstração maior do que o
código-fonte. (PRESSMAN95)
A engenharia reversa é um processo de recuperação de projeto. As ferramentas
de engenharia reversa extraem informações sobre projeto procedimental, arquitetural e
de dados de um programa existente.
A Reengenharia, também chamada renovação ou recuperação [CHI90], não
somente recupera informações de projeto de um software existente, mas usa essas
informações para alterar ou reconstituir o sistema existente, num esforço para melhorar
sua qualidade global. Na maioria dos casos, o software que sofreu reengenharia
reimplanta a função do sistema existente, mas ao mesmo tempo, o desenvolvedor do
software também adiciona novas funções e/ou melhora o desempenho global.
(PRESSMAN95)

Manutenção Preventiva

Deve ser modificado para acomodar exigências variáveis do usuário. temos

algumas opções:

18
 • Podemos lutar de modificação em modificação, combatendo o projeto
implícito e o código- fonte para implementar as mudanças necessárias.
• Podemos tentar entender o funcionamento interior mais amplo do programa
num esforço para fazer modificações mais efetivas.
• Podemos redesenhar, recodificar e testar aquelas partes do software que
requerem modificação, aplicando a abordagem de engenharia de software a
todos os segmentos revisados.
• Podemos redesenhar, recodificar e testar completamente o programa usando
ferramentas CASE (ferramentas e engenharia reversa e reengenharia) para
nos ajudar a entender o projeto.
Em vez de ficar esperando até que um pedido de manutenção seja recebido, a
organização de desenvolvimento ou manutenção escolhe um programa que permanecerá
em uso durante um número de anos previamente determinado; esteja sendo usado com
sucesso atualmente; e tenha a probabilidade de sofrer grandes modificações ou
ampliações no futuro próximo.

Elementos De Engenharia Reversa

A engenharia reversa em seu nível de abstração e as ferramentas que são usadas

para efetiva-la refere-se à sofisticação das informações de projeto que podem ser
extraídas do código-fonte. O nível de abstração deve ser o mais alto possível. O
processo de reengenharia reversa deve ser capaz de derivar representações de projeto
procedimental (um baixo nível de abstração), informações sobre a estrutura de dados e
de programa (um nível de abstração um pouco mais alto), modelos de fluxo de controle
e de dados (um nível de abstração relativamente elevado) e o modelos entidade-
relacionamento ( um nível de abstração alto). A medida em que o nível de abstração se

eleva, o engenheiro de software recebe novas informações que permitirão uma

compreensão mais fácil do programa. (PRESSMAN95)

19
 Se a direcionalidade do processo de engenharia reversa for unidirecional, todas
as informações extraídas do código-fonte serão oferecidas ao engenheiro de software,
que poderá usa´-las durante qualquer atividade de manutenção. Se a direcionalidade for
bidirecional, as informações serão fornecidas à ferramenta de reengenharia, que tentará
reestruturar ou regenerar o programa antigo.

Uma Técnica De Reestruturação Para Reengenharia

A reengenharia combina as características de extração de analise e de projeto da

engenharia reversa com uma capacidade de reestruturação é levada a efeito para gerar
um projeto que produza a mesma função com uma qualidade mais elevada do que o
programa original.
Consideremos as técnicas de simplificação de Warnier [WAR74]. As técnicas
podem ser usadas para reestruturar a lógica de programa e produzir um projeto
procedimental que se ajuste à filosofia de programação estruturada. Para entender a
reestruturação, devemos examinar primeiro, a própria técnica de simplificação.
Suponhamos que uma ferramenta de engenharia reversa seja aplicada a um programa
que use itens de dados A, B, C e D e ações de processamento(segmentos de código) V,
W, X, Z e ~R (não R). Uma representação dos quatros itens de dados A, B, C, D e as
correspondentes ações de processamento são geradas e mostradas na figura abaixo.

V= Ã . ~B . C. ~D + Ã . ~B . C + Ã . B. C . ~D + Ã . B. C. D + A . ~B . C .
~D + A . ~B . C . ~D + A . B . C . D
onde na notação boolena, indica um AND lógico e + indica um OR lógico.
Aplicando as regras de simplificação lógica, obtemos a equação a seguir:

V = ~A . ~B .C(~ D + D) + ~A . B . C (~D + D) + A . ~B . C(~D + D) + A . B .

C(~D + D)
= ~A . ~B . C + ~A . B. C + A . ~B . C + A . B. C

= ~A . C(~B + B) + A. C (~B + B)

20
 = ~A. C. + A. C = C(~A + A)
=C
e similarmente
X = A. ~B . C . ~D + A . ~B . C . D
= A. ~B . C(~D + D)
= A . ~B . C

Portanto, V será executado sempre que C for encontrado, e X será executado

quando A e C estiverem presentes e B não estiver presente.
A simplificação lógica pode ser usada como técnica de reengenharia para o
software “não-estruturado”. Os seguintes passos podem ser aplicados para executar a
reestruturação:
• Desenvolva um fluxograma para o software.
• Derive uma expressão booleana para cada seqüência de processamento.
• Compile uma tabela verdade.
• Reconstrua o software, usando as técnicas acima descritas; adicione
modificações, quando necessário.
Outras técnicas de reestruturação também têm sido propostas para ser usadas
com ferramentas de reengenharia . Por exemplo Choi e Scacchi [CHO90] sugerem a
criação de um diagrama de intercâmbio de recursos que mapeie cada módulo de
programa e os recursos (tipos de dados, procedimentos e variáveis) que sejam
intercambiados enter ele e outros módulos. ao criarmos representações do fluxo de
recursos, a arquitetura de programa pode ser reestruturada para obtermos mínimo
acoplamento entre os módulos.

21
 CONCLUSÃO

A conclusão que se chega ao elaborar um trabalho como este é que a manutenção

de sistemas poderia ser reduzida, - não poderia acabar, porque nada pode ser tão perfeito
que não precise de alguns ajustes -, com técnicas metodológicas da engenharia de
software: engenharia reversa e reengenharia.
Porém os sistemas existentes não podem simplesmente parar, eles estão velhos e
doentes, precisando assim de um acompanhamento especializado, e nós estaremos lá
para faze-lo, porém procurando não nos esquecer de todos as técnicas aqui neste
trabalho abordadas (conceitos e todas as suas características importantes), procurando
aprender com o erro dos outros colegas e satisfazer o cliente / usuário

22
 ANEXO

Pedido de Manutenção

Outro Erro
Tipo?

Adaptação Acréscimo Muita Não Muita

tipo Gravidade

Avaliar, Avaliar, Atividade de Avaliar,

categorizar e categorizar apaga incêndio categorizar e
colocar na no alto da fila colocar na fila

Anular Fazer
Ação

Informação Priorizar, e
requerida
informar colocar na fila
solicitante

Selecionar próxima
tarefa da fila de
prioridades

Planejar, organizar,
aplicar engenharia
de software

Sim
FLUXO DE EVENTOS DE Faltam
MANUTENÇÃO tarefas?
Aplicar recursos a
Não23
novo
desenvolvimento de
software
 BIBLIOGRAFIA

Pressman, Roger S. “Engenharia de Software” Editora Makron Books. 1995

24