A engenharia reversa de software tenta fazer o oposto da engenharia progressiva, pois a partir de um código existente, ela tenta recriar modelos que foram perdidos, nunca foram criados ou não acompanharam as modificações feitas no código [MOREIRA & RODRIGUES,2001].

Figura 2.1 - Processo de Engenharia Progressiva versus Engenharia Reversa [FELTRIM,1999]

A engenharia reversa parte de um baixo nível de abstração para um nível mais alto, ao contrário da engenharia progressiva.

Com a engenharia reversa é possível abstrair informações do código fonte existente, do conhecimento e experiência dos usuários, produzindo documentos consistentes, melhorando o desenvolvimento subseqüente, facilitando a manutenção e possibilitando a reengenharia. Entretanto, re-projetar e documentar um sistema já existente é tarefa bem mais difícil do que realizar um projeto inicial [LEMOS & PENTEADO, 1996].

Várias ferramentas CASE (Computer Aided Software Engineering) dão suporte ao processo de engenharia reversa de diversas formas. Algumas recebem como entrada o código fonte do programa e a partir dele podem extrair diversas informações como a arquitetura do programa, a estrutura de controle, o fluxo lógico, as estruturas de dados, o fluxo de dados e análise de dependências entre as estruturas [LONZETTI,2001].

Como exemplos deste tipo de ferramenta podemos citar o FUJABA e o ArgoUML. Estas ferramentas são capazes de gerar diagramas de classe a partir de programas escritos na linguagem Java. Outras ferramentas monitoram o software estudado durante sua execução e constróem um modelo comportamental do programa. Este é um tipo mais raro de ferramenta[MOREIRA & RODRIGUES,2001].

Há também as ferramentas que produzem métricas de software. As métricas podem ser orientadas a tamanho, orientadas a função ou voltadas para orientação a objetos. A medição é algo comum no mundo da engenharia, porém a engenharia de software está longe de ter uma medição padrão amplamente aceita e com resultados sem nenhum fator subjetivo.

As métricas orientadas a tamanho têm como medida básica a quantidade de linhas de código (LOC) utilizadas no desenvolvimento do software. Este tipo de métrica é bastante utilizada, porém existe uma polêmica quanto a sua utilização pois apesar das LOC serem a base de todos os programas, serem fáceis de contar e haver literatura a respeito, elas não levam em conta a linguagem de programação utilizada, a forma de programação e não se adequam bem a linguagens não procedurais[GOMES,2003].

As métricas orientadas a função medem o tamanho e a complexidade de um software sob o ponto de vista do usuário. A métrica orientada à função concentra-se na funcionalidade provida pelo programa. Este tipo de métrica não varia em função da linguagem de programação utilizada. [GOMES,2003]

Métricas voltadas à orientação a objetos levam em consideração vários fatores. Dentre estes fatores pode-se citar: o número de classes, número de métodos por classe, número de linhas por método, relação existente entre métodos públicos e privados, entre outros. [GOMES,2003]

Durante a realização de engenharia reversa nos módulos do CACIC não foram utilizadas ferramentas para geração dos modelos e diagramas UML. Estas ferramentas, em geral, são destinadas a analisar códigos orientados a objetos geralmente em Java ou C++. Não foi encontrada uma ferramenta livre que permitisse engenharia reversa para códigos-fonte em Delphi.

A ferramenta utilizada para extrair métricas de quantidade de linhas de código foi o Code Counter Pro [CODECOUNTER]. Foi adquirida uma versão shareware deste software que é capaz de analisar diversos tipos de extensões de arquivos e informar o número de LOC, número de linhas de comentário e número de linhas em branco. As informações geradas pelo Code Counter Pro nem sempre estavam corretas em relação ao número de linhas de comentário ou brancas e linhas de código. Por esta razão estas informações foram desconsideradas e só é apresentado o número total de linhas de cada arquivo fonte.