Em se tratando de reengenharia, há várias situações de desenvolvimento, segundo Coleman et al. (1996, p. 287) que podem ser: o acréscimo de novas funcionalidades com uma nova tecnologia de implementação, até mesmo a introdução completa de uma nova tecnologia.
Continuando a citação anterior, eles consideram que a reengenharia deva ser usada em casos em que haja a necessidade de alteração de alguma ou total funcionalidade do
software. Na sequência, é descrito o processo em que é realizada uma implementação parcial
com alterações na funcionalidade:
1. identificar partes do sistema – se faz necessário a identificação da parte do sistema a ser reimplementado e suas interações;
2. preparar o modelo de análise – partindo da documentação do sistema existente, cabe aqui a produção de modelos de análise para o sistema ou parte dele que será submetido a reengenharia;
3. mapear o modelo de análise para o sistema existente – esse mapeamento está sujeito às seguintes restrições: mapear cada componente da análise e o relacionamento existente no modelo de análise. Um documento deve conter um elemento consistente com o código fonte;
4. importar novos requisitos – os modelos sofreram mudanças de acordo com novos requisitos;
5. avaliar a interface do novo componente – nessa etapa, a interface deve ser completamente definida, partindo da parte que será trocada e considerando a parte do sistema restante;
6. projetar um novo subsistema – contempla o projeto do novo componente e a sua interface para o sistema antigo;
7. modificar o sistema antigo – finalmente, com a adição de uma interface no sistema antigo, permitindo, assim, que os agentes interajam com os componentes do novo sistema.
2.4.1 Reengenharia de Software
Com a crescente evolução da tecnologia, a informática atua na linha de frente dessa metamorfose tecnológica que o mundo globalizado vem sofrendo. Um software robusto que atue numa área como, por exemplo: um sistema de controle de tráfegos aéreos em que centenas de software operam em conjunto, são extremamente complexos e caros. (SOMMERVILLE, 2007, p. 331).
Continuando com a linha de raciocínio, o autor citado sustenta que, com o passar dos anos esses produtos acabam obsoletos devido a mudanças de tecnologia. Surge a
necessidade de implementação de alguma função que por terem sido projetados por uma metodologia ultrapassada ou uma linguagem de programação em desuso não comportam as mudanças necessárias.
Sommerville (2007, p. 331) destaca que, no projeto, a partir de um sistema legado, a reengenharia desse sistema tem vantagens em relação à construção de um novo projeto, partindo do zero, principalmente, pela redução de riscos devido ao desenvolvimento desse tipo de software tender a erros de especificação ou problemas no desenvolvimento.
Conforme o raciocínio descrito, no parágrafo acima, o projeto tende a atrasos na entrega, onerando os custos de desenvolvimento, podendo ocorrer inclusive a perda do negócio. A reengenharia tem um custo reduzido em relação ao desenvolvimento de um novo
software, por buscar, principalmente, os requisitos no software existente.
Conforme o exposto nessa seção, se torna evidente que a reengenharia deve ser usada quando da existência de um software legado.
Sommerville (2007, p. 331) enfatiza que a reengenharia de software aplicada, em sistemas legados, torna sua manutenção fácil.
Seguindo a mesma linha de raciocínio, ele comenta que a reengenharia pode produzir nova documentação, organização e reestruturação do sistema, convertendo o sistema legado em uma linguagem de programação moderna com a modificação e atualização da estrutura existente. O sistema continua a desenvolver suas atividades, com uma interface atualizada mais moderna.
Jacobson e Lidström (1991, apud PENTEADO, 1996, p. 52) “definem reengenharia como sendo composta de engenharia reversa + ∆ + engenharia avante”. Mencionam que o processo seja iniciado com:
• na engenharia reversa, é feita uma definição abstrata do sistema;
• o ∆ é um representativo das modificações de funcionalidades do sistema e da sua implementação;
• a engenharia avante é o desenvolvimento normal do sistema, criando o aplicativo propriamente dito em uma linguagem de programação orientada a objetos.
Segundo Chikofsky e Cross (1990, apud MORAIS, 2003), a reengenharia de
software é uma análise para a alteração de um sistema e reconstruí-lo em outra linguagem de
programação, podendo alterar funcionalidades e adicionar outras, empregando a engenharia reversa, para identificar o maior número possível de artefatos do sistema e seus interrelacionamentos.
Penteado (1996) destaca três cenários para a reengenharia, relacionados abaixo: 1. trocar a implementação sem perda da funcionalidade;
2. troca parcial da implementação sem perda da funcionalidade; 3. troca da funcionalidade.
Yourdon e Constantine (1978, apud PENTEADO, 1996, p. 52) definem engenharia reversa como um conjunto de teorias, métodos e tecnologias de apoio ao projeto, implementando um processo de extração de informações de um software existente, produzindo a documentação necessária de acordo com o código existente.
Chikofsky e Cross (1990 apud BOSSONARO) definem a engenharia reversa como sendo um processo para analisar um sistema, identificando seus componentes e interrelacionamentos, para criação de representações desse sistema em outra forma ou em um nível mais alto de abstração.
Para Morais (2003), a engenharia reversa, orientada a objetos, possibilita a recuperação de um modelo de análise, partindo do código fonte do sistema antigo. Esse modelo será usado na engenharia avante como complemento no processo de reengenharia orientada a objetos.
Ré (2002) declara, em sua tese, que “um processo de engenharia reversa baseada, na interface Web, é conduzido para esses sistemas-base, visando a produzir a especificação de requisitos e, por intermédio dessa especificação, criar um modelo de classe do domínio”. A Figura 11 representa o processo de engenharia avante x engenharia reversa.
Figura 11 – Engenharia Avante x Engenharia Reversa. Fonte: Adaptado de Schneider (2009).
Para Penteado (1996), a engenharia avante pode ser definida como: “processo tradicional que se inicia com abstrações de alto nível, lógicas e projetos independentes da implementação para se chegar à implementação física do sistema, ou seja, o processo de ir do projeto lógico para o projeto físico do sistema”.
Já para Morais (2003), a engenharia avante é definida como sendo as etapas de: projeto, implementação e testes, em que foi realizada a engenharia reversa e o modelo conceitual desse sistema foi obtido.
Os autores pesquisados referem-se ao termo engenharia avante como sendo: o processo utilizado na engenharia de software que parte de um alto nível para um baixo nível de abstração, que envolve o domínio do sistema de informação.
2.4.1.1 Avaliação da Reengenharia
Coleman et al. (1996, p. 287) enfatizam que os projetos de desenvolvimento orientados a objetos enfrentaram o problema da reengenharia. É evidente que o desenvolvimento de sistemas, partindo do zero, são raros. Também acrescentam que um sistema legado não sofrerá reengenharia em sua totalidade de uma única vez.
O processo de desenvolvimento, decorrente da reengenharia descrito na seção anterior, considera que os modelos de análise orientados a objetos podem ser usados para caracterizar um sistema que não foi originalmente criado com orientação a objetos e que o Método Fusion fornece um processo de desenvolvimento sistemático de engenharia direta.
Coleman et al. (1996, p. 288), reconhecem que, apesar de ter a publicação de vários relatórios sobre a experiência de reengenharia, somente estruturas provisórias de processos foram propostas.