Engenharia Reversa

Universidade Metodista de Piracicaba Faculdade de
Cincias Matemticas, da Natureza e Tecnologia da Informao.

Programa de Ps-Graduao em Cincia da Computao
METODOLOGIA DE AVALIAO PARA AQUISIO DE UMA

FERRAMENTA DE ENGENHARIA REVERSA
ANTONIO MATEUS LOCCI

ORIENTADOR: PROF. DR. LUIZ EDUARDO GALVO
MARTINS
Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao, da Faculdade

de Cincias Matemticas, da Natureza e Tecnologia
da Informao, da Universidade Metodista de
Piracicaba - UNIMEP, como requisito para obteno
do Ttulo de Mestre em Cincia da Computao.
PIRACICABA,SP
2006METODOLOGIA DE AVALIAO PARA AQUISIO DE UMA
AUTOR: ANTONIO MATEUS LOCCI

ORIENTADOR: LUIZ EDUARDO GALVO MARTINS
Profa. Dra. Rogria Cristiane Grato de Souza

UNESP - So Jos do Rio Preto
Profa. Dra. Tereza Gonalves Kirner

UNIMEP
Prof. Dr. Luiz Eduardo Galvo Martins

UNIMEP

Minha noiva Vanessa, pelo apoio e compreenso.
Aos
Meus pais Antonio Carlos e Maria Aparecida.
AGRADECIMENTOS
Ao longo deste perodo de estudos e pesquisas tenho muito a
agradecer. Primeiramente, a DEUS que no me deixou fraquejar e
desistir, em uma fase to importante e singular da minha vida.
Ao professor Dr. Luiz Eduardo Galvo Martins pela orientao,

compreenso, encorajamento e incentivo dedicado ao desenvolvimento
deste trabalho.
Aos meus pais Antonio Carlos e Maria Aparecida, pela educao
concedida, afeto e compreenso nos momentos mais difceis.
As minhas irms Rita de Cssia e Claudia Fernanda, pela disposio,
dedicao e companheirismo em situaes de extrema necessidade.
As minhas tias Aninha e Maria, pelas preces dedicadas, nos momentos
que eu mais necessitava.
A minha noiva Vanessa, pelo amor e carinho nessa fase to importante
da vida.
Ao meu cunhado Julio Csar, pela ateno nos momentos finais da
minha dissertao.
Aos amigos, Andr e Patrcia pelo apoio e disposio na finalizao da
minha dissertao.
As secretrias Solange e Rosa, pela disposio no atendimento junto
secretaria da Universidade, quanto a dvidas acadmicas.
Aos meus colegas de mestrado pela oportunidade de t-los conhecido e
convivido em momentos to diversos.
A minha instituio (ALIE) e amigos de trabalho, pelo apoio e
compreenso no decorrer da minha dissertao.
Eduquem-se os meninos e no ser

preciso castigar os homens."
(Pitgoras)
RESUMO
A maioria dos sistemas j implantados ou em processo de implantao possuem
uma restrita documentao de apoio ao desenvolvimento, e em muitos casos
nenhuma documentao. Isto atribudo aos cronogramas com tempos reduzidos,
que so aplicados para o desenvolvimento do software ou falta de experincia
do desenvolvedor neste processo. A contribuio deste trabalho est voltada
exclusivamente em propor uma metodologia de escolha de uma ferramenta para a
Engenharia Reversa, levando em considerao a intensidade da situao
problema que se encontra a documentao do sistema legado. Os mtodos
estudados foram: Fusion RE, Fusion RE/I, Renaissance, Sneed & Nyry,
Abordagem Genrica De Engenharia Reversa e as ferramentas Case estudas
foram: Dr. Case, Dbmain, Erwin, Case Studio, SA, Rose. O processo de avaliao
proposto na metodologia dividiu-se em trs etapas principais: identificao do
sistema atual, definies das correlaes e a pontuao dos pesos para cada
correlao, permitindo ao desenvolvedor personalizar a metodologia de escolha
com o cenrio atual que se encontra o sistema legado a ser reestruturado. Foi
realizado juntamente com uma Instituio de Ensino, um estudo de caso, para
localizar uma ferramenta CASE de Engenharia Reversa com o intuito de auxiliar o
processo de reestruturao do sistema legado. Os resultados obtidos foram
satisfatrios em relao metodologia e tambm para a Instituio que utilizou a
mesma para sinalizar a melhor ferramenta CASE de Engenharia Reversa de
acordo com o cenrio que se encontrava o sistema atual.
PALAVRAS-CHAVE: Engenharia Reversa, Ferramenta Case, Correlaes,

Mtodos de Engenharia Reversa, Sistemas Legados.
METHODOLOGY OF EVALUATION FOR ACQUISITION OF A

TOOL OF REVERSE ENGINEERING
ABSTRACT
The majority of the implanted systems already or in process of implantation have a
restricted
documentation
for
supporting
development
and
usually
no
documentation. This is due to the reduced time schedules, applied for the software
development or to the lack of experience of the developer in this process. The
contribution of this work is exclusively directed to proposing a methodology for
better choosing a tool for Reverse Engineering, considering the problem situation
intensity of the system legacy documentation. The studied methods were: Fusion
RE, Fusion RE/I, Renaissance, Sneed & Nyry, Generic Boarding of Reverse
Engineering and the studied Case tools were: Dr. Case, Dbmain, Erwin, Case
Studio, SA, Rose. The process of evaluation proposed in such a methodology was
divided into three main stages: identification of the current system, definitions of
the correlations and the evaluation of the weights for each correlation, therefore the
developer personalize the methodology of choice in accordance with the current
situation of the legacy system to be reorganized. It was made together with an
Institution of Education, as a case study, in order to find out a Reverse Engineering
CASE tool focusing the assistance of the legacy system reorganization process.
The results obtained were satisfactory in relation to the methodology and for the
Institution that used it to identify the best Reverse Engineering CASE tool in
accordance with the current system situation.
KEYWORDS: Reverse Engineering, Case Tool, Correlations, Reverse Engineering
Methods, Legacy Systems.
NDICE
RESUMO ...................................................................................................................V
ABSTRACT ...............................................................................................................VI
LISTA DE FIGURAS ...................................................................................................IX
LISTA DE ABREVIATURAS E SIGLAS ...........................................................................X
LISTA DE TABELAS ...................................................................................................XI
LISTA DE QUADROS.................................................................................................XII
1.
INTRODUO .................................................................................................. 1
2.
ENGENHARIA REVERSA ................................................................................... 3
2.1.
2.2.
CONCEITOS DE ENGENHARIA REVERSA ..................................................................... 3

MTODO FUSION / RE.............................................................................................. 8
2.3.
MTODO FUSION RE/I ........................................................................................... 11
2.4.
RECUPERAO DE VISES FUNCIONAIS - ETAPA 1................................................... 12
2.5.
MTODO RENAISSANCE.......................................................................................... 16
2.6.
MTODO SNEED & NYRY ...................................................................................... 19
2.7.
MTODO DE ABORDAGEM GENRICA DE ENGENHARIA REVERSA .............................. 23
3.
FERRAMENTA CASE ...................................................................................... 26
3.1.
3.2.
CONCEITO ............................................................................................................. 26
FERRAMENTA DR. CASE ....................................................................................... 27
3.3.
FERRAMENTA DB-MAIN......................................................................................... 29
3.4.
FERRAMENTA ERWIN............................................................................................ 30
3.5.
FERRAMENTA CASE STUDIO................................................................................ 32
3.6.
FERRAMENTA ROSE............................................................................................. 36
3.7.
FERRAMENTA SYSTEM ARCHITECT .................................................................... 37
4.
METODOLOGIA DE AQUISIO DE UMA FERRAMENTA DE ENGENHARIA REVERSA 39
4.1.
VISO GERAL DA METODOLOGIA DE ESCOLHA DA FERRAMENTA DE ENGENHARIA
2.2.1.
2.2.2.
2.3.1.
2.4.1.
2.5.1.
2.5.2.
2.5.3.
2.6.1.
2.6.2.
2.7.1.
2.7.2.
3.2.1.
3.3.1.
3.4.1.
3.4.2.
3.5.1.
3.6.1.
3.7.1.
OBJETIVOS ...................................................................................................................... 8
PROCEDIMENTOS E RESULTADOS ..................................................................................... 8
OBJETIVO ...................................................................................................................... 11
RECUPERAO DE VISES ESTRUTURAIS - ETAPA 2 ....................................................... 14
OBJETIVOS .................................................................................................................... 16
PROCEDIMENTOS E RESULTADOS ................................................................................... 16
DETALHAMENTO DO MTODO E RESULTADOS .................................................................. 17
OBJETIVOS .................................................................................................................... 19
OBJETIVOS .................................................................................................................... 23
CARACTERSTICAS ......................................................................................................... 27
CARACTERSTICAS ......................................................................................................... 29
CARACTERSTICAS ......................................................................................................... 30
PROJETO INTERATIVO DE SUPORTE COM COMPLETE-COMPARE ....................................... 32
CARACTERSTICAS ......................................................................................................... 33
CARACTERSTICAS ......................................................................................................... 36
CARACTERSTICAS ......................................................................................................... 38
REVERSA .......................................................................................................................... 39
4.2.
DETALHAMENTO DA METODOLOGIA PROPOSTA ....................................................... 41
4.3.
DEFINIES DOS TIPOS DE RELACIONAMENTO REFERENTES A SUAS CORRELAES E
ESCALAS DE VALORES ........................................................................................................ 47
4.3.1.
CORRELAES IDENTIFICADAS PARA O PROCESSO DE ESCOLHA DE UMA FERRAMENTA

DE ENGENHARIA REVERSA ............................................................................................. 48
5.
ESTUDO DE CASO - DADOS DA PESQUISA....................................................... 54
5.1.
5.2.
5.3.
RESULTADOS DAS CORRELAES REFERENTES S RESPOSTAS DAS DIRETRIZES ....... 64

PESOS ATRIBUDOS PARA AS CORRELAES ............................................................ 69
RESULTADO FINAL DAS CORRELAES .................................................................... 69
REFERNCIAS BIBLIOGRFICAS ................................................................................ 73
LISTA DE FIGURAS
FIGURA 2.1 - FASES DA ENGENHARIA REVERSA .................................................... 07

FIGURA 2.2 - MODELO FUSION / RE .................................................................. 10
FIGURA 2.3 - DESENVOLVIMENTO DE UM NOVO SISTEMA ...................................... 19
FIGURA 4.1 - DIAGRAMA DE ESCOLHA DA FERRAMENTA DE ER ............................. 40
FIGURA 5.1 - GRFICO REFERENTE AS RESPOSTAS DA CORRELAO 1.................. 64
FIGURA 5.8 - GRFICO REFERENTE AS RESPOSTAS DA CORRELAO 8................. 68
FIGURA 5.9 - GRFICO REFERENTE A DIRETRIZ SEM CORRELAO ATENDIMENTO
ON-LINE.............................................................................................................. 68
FIGURA 5.10 - RESULTADO FINAL DAS CORRELAES (1 A 8)............................... 70

FIGURA 5.11 - RESULTADO FINAL DAS CORRELAES ACRESCENTANDO OS
INDICATIVOS DE ATENDIMENTO ON-LINE ................................................................. 70
LISTA DE ABREVIATURAS E SIGLAS
ADO
ActiveX Data Objects
BDE
Borland Database Engine
CASE
Computer-Aided Software Engineering
CODASYL
Comitee For Data Systems Language
DBMS
Data Base Manager System
DER
Diagrama de Entidade e Relacionamento
DFD
Diagrama de Fluxo de Dados
DLL
Dynamic Link Library
DTD
Document Type Definitions
ER
Engenharia Reversa
HTML
Hyper Text Markup Language
IDS
Integrated Data Stored
IMS
Information Management System
MASA
Modelo de Anlise do Sistema Atual
MAS
Modelo de Anlise do Sistema
ODBC
Open Database Connectivity
OMT
Object Modeling Technique
RE/I
Engenharia Reversa / Interface
RTF
Rich Text Format
SA
System Architect
SGDB
Sistema de Gerenciamento de Banco de Dados
SGE
Sistema de Gesto Escolar
SQL
Structured Query Language
UML
Unified Modeling Language
XML
Extensible Mankup Language
LISTA DE TABELAS
TABELA 4.1 - ESCALA DE PONTOS DO TIPO RELACIONAMENTO COM ESCALA ........... 47

TABELA 4.2 - ESCALA DE PONTOS DO TIPO RELACIONAMENTO SEM ESCALA ............ 47
TABELA 4.3 - PESOS DAS CORRELAES DA METODOLOGIA DE ER........................ 53
TABELA 5.1 - PESOS INDICADOS PELO DESENVOLVEDOR ........................................ 69
LISTA DE QUADROS
QUADRO 2.1 - EXEMPLOS DAS RELAES - FUSION / RE......................................... 9

QUADRO 2.2 - ETAPA DO MTODO FUSION RE/I ................................................... 11
QUADRO 5.1 - RESPOSTAS DA CORRELAO 1 ..................................................... 55
QUADRO 5.5 - RESPOSTAS DA CORRELAO 5 .................................................... 59
QUADRO 5.9 - RESPOSTAS DA DIRETRIZ SEM CORRELAO ATENDIMENTO ON-LINE 63
CAPTULO 1
Introduo
1. INTRODUO
A Engenharia Reversa surgiu como uma metodologia, que estuda a construo de

ferramentas, para extrair informaes referentes anlise e projeto a partir de
programas j implementados. Tem como vantagem principal permitir a
documentao e o entendimento de sistemas que possuem pouca ou nenhuma
documentao.
O processo de Engenharia Reversa, no considerado uma tarefa muito simples,
exigindo um alto custo benefcio (pessoa / tempo) para a realizao da mesma.
Isso acontece, devido ao grande volume de informaes inseridas no processo de
revitalizao do sistema que est sendo analisado, onde a complexidade maior
est em manter a coerncia dos relacionamentos juntamente com as suas
respectivas informaes (regras de negcio) contidas no sistema legado para o
novo sistema.
Sendo assim, o objetivo deste trabalho foi desenvolver um mtodo para escolha
de uma ferramenta de Engenharia Reversa, que permita maior preciso ao ser
aplicado no processo de reestruturao de um sistema legado. Neste momento
muito importante a anlise de todas as informaes disponveis para a definio
da ferramenta de Engenharia Reversa a ser adquirida.
Este trabalho permitir que o processo de escolha seja amparado por uma
metodologia, cuja concepo vem das correlaes pr-definidas e tambm com a
possibilidade de permitir a criao de novas correlaes, visando facilitar, agilizar
e personalizar a metodologia, com os cenrios diversificados que possuem os
sistemas legados.
Outro ponto relevante a possibilidade que o desenvolvedor responsvel pela
escolha da ferramenta de Engenharia Reversa ter com a utilizao dos pesos
para cada correlao, j propostos na metodologia, permitindo assim, minimizar
ou maximizar a importncia das correlaes de acordo com a situao- problema
do sistema legado que est sendo analisado.
Este trabalho est organizado como segue:
No captulo 2 so relatados os conceitos e mtodos utilizados no processo de
Engenharia Reversa. No captulo 3 so descritos os conceitos e as caractersticas
das ferramentas do tipo CASE, que so utilizadas como apoio ao processo de
recuperao do sistema legado. No captulo 4 ser apresentada a metodologia de
escolha de uma ferramenta de Engenharia Reversa, levando sempre em
considerao a complexidade da situao-problema em que se encontra a
documentao e a adaptao da metodologia em cenrios diversificados. No
captulo 5 apresentado um estudo de caso, com intuito de validar a metodologia
proposta. O captulo 6 apresenta as concluses finais, sugerindo tambm o
desenvolvimento de uma ferramenta para facilitar e agilizar os resultados gerados
atravs da metodologia proposta.
CAPTULO 2
Mtodos de Engenharia Reversa
Neste captulo so apresentados os conceitos e mtodos da Engenharia Reversa,

justificando a importncia e os procedimentos para a realizao da reestruturao
de um sistema legado para um novo sistema, possibilitando a criao da
documentao do sistema que ser reestruturado.
2. ENGENHARIA REVERSA
2.1.
CONCEITOS DE ENGENHARIA REVERSA
Com o aumento da utilizao de programas para o gerenciamento de grandes

informaes, fazendo com que a informtica se torne to necessria, at mesmo
para a estabilidade de empresas dos mais diversos portes, vem causando uma
demanda de sistemas sem documentaes.
Devido as constantes modificaes e inseres de novas caractersticas
(funcionalidades) ao sistema, podero surgir complicaes inesperadas, que no
esto presentes na documentao. Diante disso, quando realizada a
manuteno do produto, o engenheiro de software depara-se com uma
documentao incompleta, diferente da existente. Dessa forma o valor da
manuteno de um sistema pode atingir um custo de propores acima do
esperado, tornando-se invivel a realizao da mesma.
Segundo Schneidewind (1987), citado por Feltrim (1999), Para a realizao de
uma manuteno de um sistema, necessrio concretizao de trs etapas
fundamentais: entendimento, modificao e a revalidao do sistema. Sendo que

as duas primeiras etapas (entendimento, modificao) esto ligadas diretamente
com a disponibilidade das informaes contidas no software.
Segundo Gall (1994), a Engenharia Reversa um processo de refazer a
documentao de um sistema, com o objetivo de conseguir as informaes
necessrias para a definio do novo projeto.
Segundo Shneiderman (1979), citados por Braga (1998), O coeficiente de
abstrao de um programa, pode ser varivel, devido ao tipo de conhecimento que
o analista ir obter, atravs da anlise do sistema em questo. importante
ressaltar que a maneira mais prtica de se obter as informaes necessrias,
seria a leitura do cdigo fonte, a dificuldade est no grande volume de dados
contidos no mesmo (Robson, 1991).
Segundo Muhammad (2005), a Engenharia Reversa de software consiste em
analisar o cdigo do sistema, as documentaes disponveis e as regras de
negcio existentes. Com isto ser possvel criar uma abstrao do mesmo,
possibilitando a gerao das informaes necessrias para o processo de
Engenharia Reversa.
Segundo Abdelwahab e Timothy (2004), manter um sistema com pouca
documentao uma tarefa difcil. As ferramentas de Engenharia Reversa so
utilizadas como meio de manuteno, tais como, explorao do cdigo fonte,
anlise de fluxo de dados, possibilitando, a restaurao da arquitetura do projeto.
Com isto, possvel gerar uma abstrao do sistema legado com alto nvel de
complexidade, facilitando a compreenso do mesmo.
Segundo Anquetil (2002), a Engenharia Reversa de software muito utilizada
para:
adaptar o software a novos computadores;
atualizar o software (novas bibliotecas, novas linguagens de
programao, novas ferramentas);
adaptar o software a novas regras;
disponibilizar novas funcionalidades e corrigir bugs.
Segundo Pressman (1994), o termo Engenharia Reversa se refere a um processo

de analisar e representar um programa em um nvel de abstrao mais elevado do
que o cdigo fonte. A Engenharia Reversa um processo de recuperao do
projeto, utilizando ferramentas para extrair informaes sobre o projeto
procedimental, arquitetural e de dados de um programa existente.
Segundo Chikofsky e Cross II (1990), citados por Braga (1998), a Engenharia
Reversa originou-se da anlise de hardware, onde o hbito de explicar os projetos
de produtos j desenvolvidos so considerados comuns. O mesmo conceito pode
ser aplicado a software, pois a Engenharia Reversa de hardware tem o objetivo de
reproduzir o sistema, enquanto a Engenharia Reversa de Software tem como foco
principal a criao de vises do sistema em vrios nveis de abstrao, fazendo
com que haja facilidade em seu entendimento, e, principalmente, oferecendo
apoio manuteno do sistema.
Rugaber (1992), citado por Feltrim (1999), assegura que a maior parte do esforo
de desenvolvimento de software dedicado manuteno de sistemas j
implantados, e no ao desenvolvimento de novos sistemas; o processo concentrase na compreenso do sistema em manuteno. Para isso, necessrio facilitar o
processo de compreenso de sistemas legados, para que haja uma melhora no
desenvolvimento de novos sistemas.
Segundo Saleh e Boujarwah (1996), citados por Feltrim (1999), o crescimento do
mercado de software e a constante utilizao de novas tcnicas sem
documentao formal, vm causando uma dificuldade para realizar a manuteno
desses softwares, pois na maioria dos casos a documentao no est de acordo
com o cdigo implementado.
Alm disso, efeitos colaterais inesperados que no esto presentes na

documentao so gerados devido s constantes modificaes
impostas ao
software.
Segundo Beneduzi (1992), citado por Braga (1998), a Engenharia Reversa deve
produzir documentos para facilitar de uma forma geral o conhecimento do sistema
implantado, facilitando assim o reuso, manuteno, teste e controle da qualidade
do software. Alm disso, a Engenharia Reversa est concentrada diretamente na
necessidade de conhecer as funcionalidades existentes em softwares antigos
(implantados), na produo de novos softwares e de proporcionar uma maior
facildade nas realizaes de futuras manutenes.
Segundo Chikofsky (1990), citado por Braga (1998), a Engenharia Reversa o
processo de anlise de um sistema existente cujo objetivo principal verificar
seus componentes e seus inter-relacionamentos, com o intuito de atingir uma
representao do sistema de outra forma ou em um nvel mais alto de abstrao.
A Figura 2.1 representa as fases da Engenharia Reversa. A etapa inicial extrair
informaes do sistema a partir do cdigo fonte ou at mesmo da interface. Em
seguida comea a fase do projeto, ou seja, da modelagem dos dados extrados.
Nesta etapa a utilizao de ferramentas CASE fundamental. Com as
informaes j modeladas, tem incio a fase de organizao dos requisitos, que
permite um nvel mais alto de abstrao em relao ao cdigo fonte. A terceira
fase o processo de Reengenharia de Software, cuja funo est na
recodificao do fonte sobre os requisitos levantados.
FIGURA 2.1 - FASES DA ENGENHARIA REVERSA (BASEADO EM CHIKOFSKY,1990, CITADO

POR BRAGA,1998)
2.2.
MTODO FUSION / RE
2.2.1. OBJETIVOS
Segundo Penteado (1996), para implementar um sistema orientado a objetos a

partir de um sistema legado orientado a procedimentos, so dadas duas razes:
1) Para satisfazer a maioria das necessidades dos usurios, os sistemas legados
atendem quase a totalidade de suas necessidades, sendo a melhoria da
programao de sua interface essencial no atendimento ou padronizao de suas
funes.
2) O Fusion / RE, possui como foco principal, viabilizar a migrao de um sistema
procedimental para um sistema orientado a objetos, cujo objetivo, est na
recuperao do projeto de sistemas legados. O processo de Engenharia Reversa
no est voltado simplesmente na documentao do sistema. A viabilidade da
recuperao do projeto est na utilizao do cdigo fonte e das entrevistas com os
usurios.
2.2.2. PROCEDIMENTOS E RESULTADOS
A reconstruo do sistema feita manualmente atravs das informaes
existentes no cdigo fonte, utilizando os recursos de pesquisa disponveis em
editores de texto. Assim, faz-se a documentao dos procedimentos pertencentes
aos mdulos do sistema e da relao CHAMA / CHAMADO POR. O quadro 2.1
apresenta as relaes:
QUADRO 2.1 - EXEMPLOS DAS RELAES - FUSION / RE
Mdulo
Mdulo X
Nome_procedimento_mdulo
Descrio
CHAMA: Nome_procedimento (mdulo_a

que_pertence). CHAMADO POR:
Nome_procedimento (mdulo_a que_pertence)
Com base nas informaes anteriormente expostas, o mtodo est dividido

em quatro etapas:
1 Etapa: A realizao de pesquisas no sistema identificando quais documentos
esto relacionados ao sistema legado, o principal objetivo nessa etapa. No
existindo nenhuma documentao, a pesquisa dever ser realizada atravs do
cdigo fonte, sendo a mesma efetuada sem nenhum recurso computacional.
2 Etapa: Nesta etapa ser criado o modelo de anlise do sistema atual (MASA),
para a identificao das classes juntamente com seus relacionamentos, atributos e
procedimentos. A partir do cdigo fonte este modelo pode ser desenvolvido,
visando um melhor conhecimento das funcionalidades do sistema legado,
facilitando e proporcionando possveis sugestes para eventuais alteraes.
3 Etapa: Nesta etapa, ser desenvolvido o modelo de anlise do sistema (MAS),
no relacionado diretamente implementao e sim ao domnio da aplicao,
solucionando
problemas
relacionados
ambigidade
de
informaes,
nomenclaturas de campos com dificuldade de compreenso e a realizao da

anlise para a reduo de classes utilizando os conceitos de Especializaes /
Generalizao, Encapsulamento e outros.
4 Etapa: Aps a definio dos modelos de anlise do sistema atual (MASA) e do
modelo de anlise do sistema novo (MAS), com o objetivo de identificar o que foi
includo ou excludo no sistema legado, deve-se realizar a comparao entre os
modelos MASA e MAS. Esta etapa extremamente importante, j que possui
como funo principal a documentao das alteraes realizadas no sistema
legado, possibilitando a realizao de futuras manutenes do sistema em
questo, como mostra a Figura 2.2
Documentao
Existente
Passos
1.Revitalizar a
Arquitetura
Outros Documentos
Relevantes
1 Passo
D
Estrutura do
Programa
Entradas/Sadas
Listadas
I
C
I
2.Recuperar o
Modelo de
Anlise do
Sistema Atual
2 Passo
N
Temas
Modelo de Ciclo
de Vida
Modelo de
Objetos
3.Criar o Modelo
de Anlise do
Sistema
Modelo de
Operaes
I
O
3 Passo
E
Modelo de
Objetos
Modelo de Ciclo
de Vida
D
Modelo de
Operaes
A
D
O
4.Mapear o Modelo
de Anlise do
Sistema para o
Modelo de Anlise
do Sistema Atual
4 Passo
Objetos
Atributos/
Elementos de
Dados
S
Mtodos/
Procedimentos
FIGURA 2.2 - MODELO FUSION / RE (PENTEADO, 1996)

2.3.
MTODO FUSION RE/I
2.3.1. OBJETIVO
Segundo Costa (1997), citado por Feltrim (1999), o mtodo Fusion-RE/I forma um
mtodo de Engenharia Reversa que visa facilitar todo o processo de recuperao
dos dados, partindo da interface do sistema para a recuperao de informaes
teis compreenso do software. Por meio desta metodologia possibilita-se a
recuperao das partes funcionais e estruturais do sistema, obtendo-se as
consideraes lgicas atravs da anlise da interface para a recuperao de
partes funcionais do sistema. O Fusion RE/I baseado na utilizao dos modelos
das fases de anlise, do mtodo de desenvolvimento de software orientado a
objetos Fusion.
O mtodo Fusion RE/I derivado de outro mtodo de Engenharia Reversa, o
Fusion/RE. Os dois mtodos visam recuperar os modelos de anlise do mtodo
Fusion, mas apresentam diferenas em relao ordem das etapas a serem
cumpridas. O processo do Fusion RE/I inicia-se com a anlise da interface do
sistema para a recuperao das vises. O quadro 2.2 apresenta a etapa que o
mtodo Fusion RE/I utiliza para recuperar as vises Funcionais e Estruturais.
QUADRO 2.2 - ETAPAS
DO MTODO FUSION RE/I
Etapa 1. Recuperar vises Funcionais
a. Obter informaes existentes sobre o

sistema b. Recuperar o modelo de anlise b.1.
Elaborao do modelo de ciclo de vida b.2.
Elaborao do modelo de operaes b.3.
Elaborao do modelo de objetos
2.4.
(COSTA,1997)
Etapa 2. Recuperar Vises Estruturais
a. Elaborao do quadro de procedimentos de

implementao a.1. Elaborao do quadro de
chamadas a.2. Elaborao do quadro de ndice
de procedimentos b. Elaborao do quadro de
operaes - procedimentos de implementaes
RECUPERAO DE VISES FUNCIONAIS - ETAPA 1
A primeira etapa do mtodo Fusion-RE/I constituda por duas etapas: obteno

das informaes j existentes do sistema e recuperao do modelo de anlise.
Segue-se a descrio das etapas:
1 Etapa (a):
A obteno de informaes sobre o sistema: procuram-se todas as informaes
existentes no sistema, at mesmo a documentao (manuais, listagem de
cdigos, etc.) do software e tambm todo tipo de informao considerada
importante (relevante) neste processo, como linguagem de implementao, entre
outras (Costa,1997).
As documentaes devero ser agrupadas e analisadas, com o intuito de
identificar as informaes consideradas necessrias para os requisitos do sistema,
ao projeto arquitetural e procedimental de dados.
A entrevista com o usurio considerada muito importante, pois as informaes
cruciais do sistema podem no constar na documentao.
1 Etapa (b):
Recuperar Modelo de Anlise do Sistema: nesta etapa so obtidas informaes a
partir da anlise da interface do sistema (Costa,1997).
Neste momento compreendido a execuo de modelos da fase de anlise do
mtodo Fusion, sendo eles:
ciclo de vida,
operaes;
objetos.
1 Etapa (b-1):
Elaborar o Modelo de Ciclo de Vida do Sistema: a partir da utilizao do sistema,
da anlise da documentao existente e das entrevistas com os usurios, so
definidos a seqncia de operaes permitidas e os eventos de entrada e sada
aceitos pelo sistema.
As opes existentes no menu principal do sistema identificam a expresso

principal do modelo de ciclo de vida. As opes ali listadas so construdas
novas expresses, uma para cada opo, sinalizando as seqncias de
operaes permitidas a partir daquele ponto. Para cada operao citada, escrita
uma nova expresso, identificando a seqncia permitida de eventos de entrada
(elementos da operao) e os respectivos eventos de sada, que aparecem
precedidos pelo smbolo #.
1 Etapa (b-2):
Elaborar o Modelo de Operaes do Sistema: nesta etapa o objetivo est em
mostrar uma viso geral da funcionalidade das operaes realizadas pelo sistema.
Para a elaborao do modelo de operaes deve-se utilizar constantemente o
sistema, para que as operaes se tornem amplamente detalhadas.
O mtodo Fusion-RE/I considera desde as operaes geradas por meio da
interface at as oprees e eventos visveis em tela, como a criao e
manipulao de arquivos. A verificao realizada atravs de diretrios de
trabalho do sistema.
1 Etapa (b-3):
Elaborar o Modelo de Objetos do Sistema: a princpio, definem-se os temas
relacionados funcionalidade do sistema. Para que se possam definir os temas,
uma anlise das informaes recuperadas nos passos nas etapas anteriores
necessria, alm das abstraes registradas nos modelos de ciclo de vida e de
operaes. Esta uma das tarefas mais subjetivas e de fundamental importncia
do mtodo Fusion RE/I. Definidos os temas, realizado um agrupamento das
operaes de acordo com os temas a que se referem. Ao final tem-se uma lista de
temas com suas respectivas operaes.
Temas so constitudos de outros temas, ao deparar-se com assuntos que se
relacionam em um nvel de abstrao mais alto. Cada tema definido criado um
modelo de objetos. Neste momento as operaes so analisadas novamente com
o intuito de localizar componentes que constituem o modelo de objetos (classes,

relacionamentos, atributos, agregaes, especializaes e generalizaes)
Os componentes do modelo de objetos muitas vezes incluem componentes que
no esto explcitos nas operaes, mas simplesmente identificados pela
abstrao e entendimento da funcionalidade de cada elemento e operao.
A construo do modelo de objetos funo amplamente subjetiva, mesmo no
constando no mtodo, e provavelmente requerer um feedback aps a
recuperao das vises estruturais (visualizao do cdigo). A necessidade do
feedback evidente durante a utilizao do Fusion-RE/I, uma vez que as mais
notveis referncias sobre este mtodo de Engenharia Reversa no emitem
diretrizes nicas voltadas elaborao deste modelo de objetos (Costa,1997).
2.4.1. RECUPERAO DE VISES ESTRUTURAIS - ETAPA 2
Nesta etapa o foco est em trabalhar com o cdigo fonte do sistema, cujo o
objetivo est em identificar os procedimentos que implementam as operaes do
sistema descritas nas etapas anteriores.
2 Etapa (a):
Elaborar Quadro de Procedimentos de Implementao: Tem como objetivo
identificar os procedimentos, suas funcionalidades e a seqncia de chamadas
desses procedimentos. Sendo assim, so utilizados dois quadros: um quadro de
chamadas para cada arquivo de programa do sistema e um ndice geral de
procedimentos (Costa,1997).
2 Etapa (a-1):
Elaborar o Quadro de Chamadas: este quadro utilizado para cada arquivo do
cdigo fonte do sistema, indicando os procedimentos armazenados no arquivo,
suas respectivas funcionalidades e os procedimentos utilizados (chamados) e
utilizadores (chamado por).
As funcionalidades podem ser identificadas atravs de comentrios registrados no

cdigo fonte. J os procedimentos (chamados) so definidos pela anlise do
cdigo e os procedimentos (chamados por) so obtidos atravs das elaboraes
dos quadros.
Para finalizar, os procedimentos de cada quadro so reorganizados em ordem
alfabtica.
2 Etapa (a-2):
Elaborar o Quadro ndice de Procedimentos: este quadro ir apresentar os
procedimentos da implementao do sistema em ordem alfabtica, com as
localizaes (arquivo e diretrio). Na elaborao deste quadro utilizam-se os
quadros de chamadas obtidos anteriormente.
2 Etapa (b):
Elaborar Quadro das Operaes - Procedimentos de Implementao: Neste
momento identificam-se os procedimentos que implementam as operaes da
interface e, funcionalmente, os procedimentos so acoplados interface ou a um
dos temas definidos anteriormente, sendo identificados os links entre os
documentos Quadro de Operaes, da primeira etapa do mtodo, com os
cdigos que os implementam (Costa,1997).
2.5.
MTODO RENAISSANCE
2.5.1. OBJETIVOS
Segundo Battaglia et al. (1998), o mtodo Renaissance foi desenvolvido como um
suporte para a reengenharia de software de sistemas legados, criando diferentes
vises do projeto do sistema antigo e novo, por meio de modelos da UML
(Diagrama de Interao, Diagrama de Casos de Uso, Diagrama de Estados e
Diagrama de Componentes). Fornece diretrizes de como transformar uma
arquitetura legada em uma arquitetura cliente / servidor.

O mtodo estruturado em duas etapas principais:
1 Etapa:
Consiste em avaliar a empresa (organizao), verificando a estrutura do sistema
legado e identificando a melhor estratgia a ser adotada para o processo de
revitalizao do sistema que est sendo analisado.
2 Etapa:
Esta etapa tem como foco principal migrao de um sistema legado para um
sistema novo.
Um sistema legado pode ser definido informalmente como um grande sistema,

praticamente impossvel de ser entendido e alterado, mas que de vital
importncia para a organizao.
Muitos desses sistemas legados esto desempenhando um trabalho crucial e de
extrema importncia para a suas empresas, contendo anos de experincias e
conhecimentos (regras de negcios) acumulados.
Desenvolver um novo sistema pode ser, s vezes, melhor do que continuar
alterando e fazendo pequenas modificaes no sistema antigo. Um novo sistema
ser mais simples de ser operado e qualquer alterao ser rpida e bem menos
trabalhosa.
A reengenharia de software tambm pode ser definida como uma transformao
sistemtica de um sistema existente para um novo, compreendendo melhorias de
qualidade na operao, capacidade, funcionalidade, performance, ou capacidade
de evoluo com um custo reduzido, e pouco risco para o programador. No geral,

isto pode ser muito mais conveniente do que refazer um sistema, um
investimento menos pesado financeiramente. A reengenharia parece ser uma
aproximao promissora para a reprogramao de sistemas legados existentes.
Mas isto pode no ser o bastante, uma vez que recuperado o sistema legado,
preciso tomar cuidado para que o sistema desenvolvido no se torne um futuro
sistema legado. exatamente nessa fase que entra do mtodo Renaissance.
2.5.3. DETALHAMENTO DO MTODO E RESULTADOS
A reengenharia comea com um segmento do sistema atual. O mtodo

Renaissance foi projetado para controlar os altos custos potenciais de
um projeto, porque primeiramente estreita para um conjunto mnimo de
componentes necessrios, e, secundariamente, abrange aqueles
componentes que podem realmente se beneficiar com a reengenharia.
Combinaes particulares do valor de negcios e qualidade tcnica

podem determinar que componentes deveriam tornar-se candidatos
evoluo. Componentes com uma boa qualidade tcnica e pouco uso
podem ser deixados de lado. Componentes com qualidade tcnica
baixa, mas com alto valor ao sistema, so considerados como fortes
candidatos para a evoluo.
O mtodo Renaissance fornece um conjunto compreensivo de tcnicas

de custo / beneficio para a anlise dos componentes, assim como uma
anlise custo / risco, onde o custo e risco so fatores com vrias
alternativas que devem ser examinadas para que as melhores
combinaes sejam escolhidas.
Entende-se como fase final da evoluo planejada, o desenvolvimento

estratgico da evoluo do sistema global, juntamente com o projeto da
arquitetura do sistema que ser desenvolvido.
O mtodo Renaissance possui um conjunto significativo de tecnologia

para o desenvolvimento de vrias vises do sistema novo e antigo,
utilizando padro UML.
Tcnicas de implementaes especiais so elaboradas para serem

utilizadas em projetos de evoluo. Os grupos de componentes so
identificados, e com isso podem ser migrados junto ao sistema novo.
Debaixo de um controle contnuo de testes, os grupos de componentes
so integrados um de cada vez no sistema novo, de acordo com o
cenrio da integrao.
de extrema importncia a superviso dos usurios, na fase de

migrao dos dados (regras de negcio)
para o novo sistema,
garantindo uma maior segurana na integridade dos dados.
As aplicaes dedicadas do mtodo, que vai alm de uma evoluo nica, entram
realmente na vida de um sistema, at mesmo durante seu funcionamento. A
experincia adquirida e as metas de negcios so avaliadas, assim como sua
performance e os requisitos de um futuro sistema. Baseado em novas
experincias, o mtodo Renaissance pode ser novamente utilizado para uma nova
modificao do sistema, como mostra a Figura 2.3.
FIGURA 2.3 - DESENVOLVIMENTO DE UM NOVO SISTEMA (BATTAGLIA ,1998)
2.6.
MTODO SNEED & NYRY
2.6.1. OBJETIVOS
Segundo Sneed et. al (1995), os usurios, a cada dia que passa, esto tomando a
deciso de migrar suas aplicaes de mainframes para arquiteturas cliente /
servidor.
A melhor maneira de alcanar esta meta extrair as estruturas, interfaces e
algoritmos dos cdigos do sistema legado e criar um programa em outra
linguagem, com outra arquitetura, mas com a mesma funcionalidade. A vantagem
que a funcionalidade do sistema legado preservada, mas sem as suas
restries. A desvantagem que o cdigo tem de ser reescrito e os testes de
dados regenerados; ainda que a soluo de negcios continue a mesma, a
soluo tcnica pode estar completamente diferente.
Objetos existentes podem ser identificados e classificados da seguinte forma:
Mapas ou painis para comunicao com o usurio;
Bancos de dados para armazenamento de dados persistentes;
Procedimento de controle de trabalho e programas.
Com a utilizao deste mtodo possvel identificar os objetos de interface. Como

regra, um painel equivalente a um objeto. Entretanto, se o painel contm
tabelas ou grupos repetidos ento cada entrada ou item de linha um objeto. Tais
objetos so identificados por seu fator de ocorrncia. Os atributos de objeto so os
campos de dados subordinados.
Quando se examinam as descries de banco de dados possvel identificar os
objetos de informao. No caso de bancos de dados relacionais, os objetos so as
linhas da tabela, enquanto os atributos so as colunas.
possvel identificar nos programas no unicamente os arquivos de trabalho, mas
tambm as vises dos programas nos bancos de dados. Assim, os programas so
derivados por quatro tipos diferentes de objetivos:
Arquivos;
Vises de banco de dados;
Estruturas de dados de trabalho;
Parmetros de ligao de programa.
Um objeto pode ser qualquer um destes tipos diferentes de conjuntos de dados

declarados dentro dos programas. Os atributos de objeto so os membros
daqueles conjuntos e os campos subordinados.
O prximo passo do processo de anlise consiste em localizar e extrair operaes
sobre os objetos, o que alcanado examinando as referncias em cruzamentos.
Primeiramente os procedimentos de programa devem ser segmentados. Se os
programas so estruturados, ento operaes elementares esto relacionadas
para vrios ramos, e a seqncia de cdigo entre duas estruturas de controle no
so consideradas operaes elementares, so qualquer bloco de cdigo
referenciado por um rtulo. Tendo identificado as operaes elementares fica mais
simples chec-las para ver suas referncias com os objetos predefinidos. Para
que sejam resolvidos os problemas prticos, o mesmo atributo pode ter rtulos
diferentes.
Tendo extrado as operaes desempenhadas sobre cada objeto, o prximo passo
est em descrever suas conexes. Operaes perguntam ou atualizam os
atributos dos objetos para que eles sejam anexados. Entretanto, na operao, eles
tambm solicitam dados de outros objetos estrangeiros (parmetros). Os
parmetros ou interfaces so o que conectam os objetos.
Para reespecificar as conexes de objeto, necessrio examinar todas as
operaes pertencentes a um objeto especfico, para capturar as variveis
estrangeiras. Variveis estrangeiras so todas as variveis utilizadas por uma
operao que no so atribudas no objeto. Para cada objeto que deriva de dados
de uma operao, uma interface especificada. As interfaces contm o nome do
objeto do fonte, o nome da operao recebida, o nome do objeto do alvo, e os
nomes de todas variveis obtidas do objeto do fonte.
Reespecificando a seqncia de operao, o passo de anlise final est em
capturar e documentar a seqncia em que as operaes so executadas. A
seqncia determinada separando-se o programa que controla o fluxo das
operaes.
Esta fase de controle contm unicamente uma varivel. Este atributo global est
atribudo em cada operao, antes que seja apontado o seu sucessor. Depois da
chamada de cada operao, o controle contesta perguntas varivel para
determinar que operao deveria ser a prxima. Assim, o objeto de controle
parecido com o crebro de um organismo que manda mensagens aos outros
rgos. Cada rgo tem a possibilidade de mudar o fluxo subseqente de controle
por uma varivel.
Toda operao em cada objeto pode ser sucessor potencial de um objeto, isto
necessrio para analisar cada operao, para indagar os possveis sucessores.
Os sucessores esto juntos para documentar os caminhos atravs das operaes.
Cada caminho uma seqncia nica de operaes ou mtodos. Por alterar-se
em qualquer uma das operaes, o caminho pode ser mudado. Entretanto, para
propsitos de documentao, os possveis caminhos podem ser selecionados, e
destes, os caminhos padronizados podem ser realados.
Cada seqncia nica de operaes ou clusula deveria ser um caso de teste
com uma pr-condio, prescrevendo o estado dos objetos afetados antes da
execuo, e uma ps-condio, prescrevendo o estado dos objetos afetados
depois da execuo do caso. Em adio, deveria ser uma afirmao prescrevendo
os estados que permanecem inalterados.
2.7.
MTODO DE ABORDAGEM GENRICA DE ENGENHARIA REVERSA
2.7.1. OBJETIVOS
Segundo Ghannouchi et al. (1998), este mtodo
d suporte Engenharia
Reversa, sendo classificado como genrico, porque utiliza vrios procedimentos

de outros mtodos de Engenharia Reversa. Utilizando as melhores partes de
outros mtodos, o processo Genrico pode se tornar uma das melhores formas de
conduzir o processo de Engenharia Reversa.
Um processo de Engenharia Reversa est diretamente ligado a uma linguagem
de programao. A troca de uma abstrao para outra, pode ser sempre
acompanhada por perdas de informao. Neste processo exclui-se um nmero
considervel de situaes onde o usurio deve intervir para contribuir com um
nmero baixo de perda. A freqncia de tais situaes e a importncia das

decises implicadas na realizao do processo de Engenharia Reversa podem ser
explicadas por um meta modelo.
O meta modelo pressupe em quatro conceitos:
Uma situao uma parte do produto sobre o desenvolvimento ou

uma parte do programa para Engenharia Reversa;
Uma deciso reflete uma escolha que um analista faz em um dado

ponto durante o processo;
Uma ao desempenha a transformao no produto;
Um argumento uma declarao que suporta ou contesta uma

deciso dentro de um contexto informado.
Neste modelo, um contexto definido como sendo uma associao entre uma
situao e uma deciso. Esses contextos esto divididos em trs tipos:
Executivo baseado no contexto: afeta os modelos recuperados,

gerando novas situaes que podem ser assunto para novas
decises.
Escolha baseada no contexto: este contexto no modifica o produto,

mas permite fazer progresso no processo de decises de
desenvolvimento, o que d algum refinamento entre o contexto inicial
e suas alternativas diferentes na rede de contextos. Cada alternativa
caracterizada por um critrio de escolha que uma combinao de
argumentos suportando ou contestando a escolha.
Plano baseado no contexto: permite satisfazer as intenes

complexas que vm de um mecanismo de decomposio.
A execuo dos componentes definida em um grfico de dependncia. Os ns

do grfico de dependncia so contextos e os arcos so elos de dependncia
representando pedidos ou transies paralelas entre os contextos. As condies
anexadas aos elos permitem prescrever as condies de ocorrncia de uma
transio.
A linguagem do cdigo fonte reconhecida por sua gramtica. A definio de
gramtica acompanha aes semnticas ligadas aos dados no procedimento de
Engenharia Reversa e associadas com o processo utilizado. Assim, todo
programa escrito em uma linguagem de programao deve ser analisado segundo
a gramtica desta linguagem, e as aes semnticas habilitaro a gerao de um
conjunto de fatos. Este conjunto de fatos corresponde s situaes no cdigo
fonte.
Algumas aes semnticas da gramtica da linguagem considerada podem
aparecer no modelo-alvo. Igualmente, o conjunto de situaes derivadas do
programa habilita um gatilho com um conjunto de aes que podem gerar
conceitos diferentes do modelo-alvo.
O processo de Engenharia Reversa aplicado em programas pertencentes a
vrios domnios de aplicao. Cada um desses domnios caracterizado por um
conjunto de conhecimentos especficos. Assim, o processo de Engenharia
Reversa conta com um domnio de aplicaes em que o mesmo inserido.
Normalmente, as informaes requeridas no domnio da aplicao so fornecidas
pelo analista.
Domnio de Aplicao e seus sub-domnios tm partes especficas que poderiam
ser exploradas, juntamente com o que extrado das aplicaes do cdigo fonte.
Assim, isto se torna necessrio para ter um conhecimento baseado no que poderia
ser uma estrutura de domnios de aplicao. A estrutura desta base de
conhecimento deve melhorar a resoluo de problemas que so especficos para
domnios de aplicao particulares e ajudam a obter melhores dados.
O trao de um processo definido como uma descrio de sua execuo, dando

as informao sobre as aes utilizadas, sinalizando
por que e quando os
processos esto sendo alterados.

O trao na Engenharia Reversa processa o comeo do cdigo fonte, vai atravs
de modelos intermedirios e representaes, e d detalhes das diferentes
situaes encontradas e das escolhas feitas pelo usurio at o modelo final. Ele
possibilitar um profundo conhecimento nos processos.
CAPTULO 3
Ferramentas de Engenharia Reversa
Nesse captulo so apresentadas
algumas ferramentas do tipo CASE,
consideradas primordiais na hora de se executar a Engenharia Reversa.

As ferramentas CASE podem ser teis
para se fazer a Engenharia Reversa,
possibilitando a gerao de uma nova modelagem de dados e at mesmo a

emisso das documentaes para o novo sistema.
3. FERRAMENTA CASE
3.1.
CONCEITO
Segundo Fiss (2001), O termo CASE Computer-Aided Software Engineering

(Engenharia de Software Auxiliada por Computador), empregado para nomear
as novas tecnologias de desenvolvimento de software, que proporcionam maior
agilidade e facilidade para os desenvolvedores de sistemas.
Um produto pode ser identificado como uma ferramenta CASE quando o mesmo
oferece documentao, automao e racionalizao de projetos de softwares
agregados com suas respectivas implementaes.
Possui vrias facilidades e vantagens na utilizao de ferramentas CASE, tanto
para a Engenharia de Software ou para a Reengenharia de Software, as principais
so:
3.2.
Maior qualidade dos produtos finais;
Produtividade;
Eliminao de trabalho montono;
Mais tempo para a tomada de deciso;
Flexibilidade para mudanas;
Melhor documentao;
Manuteno mais fcil e gil.
FERRAMENTA DR. CASE
Segundo o fornecedor (Squadra Tecnologia, 2004), a ferramenta Dr. CASE um

conjunto de ferramentas para modelagem de sistemas e projetos conceituais,
lgico e fsico de banco de dados. Utilizando tcnicas de Engenharia de Software,
esta ferramenta facilita a situao de projetar e documentar sistemas de uma
forma mais produtiva.
3.2.1. CARACTERSTICAS
Possui ferramentas grficas para anlise e modelagem funcional atravs

de Diagramas de Fluxo de Dados (DFD);
Ferramentas de verificao de consistncia e documentao (relatrios)

de projeto;
Ferramentas de Engenharia Reversa:
Permite interpretar estruturas de banco de dados existentes e

abstrair o Modelo Lgico (Dicionrio de Dados) e o Modelo
Conceitual (DER) de forma automtica.
A ferramenta Smart Linking, auxilia a identificao e definio

de chaves estrangeiras num projeto lgico. Muito til aps a
Engenharia Reversa de um Banco de Dados que no possui
integridade referencial (chaves estrangeiras) implementada.
Ferramentas grficas para anlise e modelagem de dados atravs de

diagramas Entidade-Relacionamento (DERs);
Dicionrio de dados em nvel conceitual e fsico;
Transposio dos DERs (projeto conceitual) para tabelas (projeto

lgico);
Gerao fsica de banco de dados, a partir do projeto, prevista para as

plataformas:
MS Access (2, 95 e 97);
Paradox ( 4.x, 5.x e 7);
FoxPro ( 2.5 e 2.6);
dBase (III, IV, 5 e 7);
Gerao de Scripts SQL, para as seguintes plataformas:

MS SQL Server;
Sybase SQL Server;
Borland Interbase;
Oracle, Paradox;
MS Visual FoxPro;
IBM DB2;
IBM SQL/DS e os padres ANSI 86 e ANSI 92.
3.3.
FERRAMENTA DB-MAIN
Segundo o autor (Jean Hainaut, 2005), esta ferramenta oferece recursos tanto
para Engenharia de Software quanto para Engenharia Reversa. Incluindo a
maioria das funes bsicas, freqentemente encontradas em outras ferramentas
CASE e tambm funes mais complexas que normalmente no so to fceis de
serem encontradas.
Administrar sistemas de banco de dados fsico, lgico e conceitual;
Administrar processos de sistemas ao processar unidades, relaes de

chamada, decomposio, entrada e sada de dados;
Visualizar sistemas atravs de 7 formatos : 4 hipertextos e 3 grficos;
Criar sistemas lgicos dos sistemas conceituais (Engenharia),
Criar sistemas conceituais de sistemas lgicos (Engenharia Reversa);
Transformar
sistemas
(normalizando,
otimizando,
reestruturando,
implementando, fazendo engenharia reversa, etc), graas a um toolset

com mais de 25 operadores;
Fazer resoluo de problemas atravs de um assistente de transformao

intuitivo e simples;
Automatizar a aplicao de algumas transformaes em um esquema

atravs de um assistente de transformao global avanado;
Integrar projetos, sistemas ou tipos de entidade;
Analisar sistemas e pesquisar modelos estruturais mais complexos;
Pode ser facilmente usado para localizar chaves estrangeiras;
Gerar relatrios;
Extrair informaes a partir de vrios modelos de banco de dados: SQL,

COBOL, IMS, RPG, IDS/II DDL e XML (DTD);
3.4.
Processar uma sofisticada anlise do programa;
Atualizar um esquema lgico de um cdigo fonte;
Registrar aes do usurio dentro da histria do projeto;
Criar vises com uma propagao de atualizao automtica;
Importar e exportar especificaes externas.
FERRAMENTA ERWIN
Segundo o fornecedor (Computer Associates, 2003), a ferramenta ERwin

considerada de fcil utilizao, para o planejamento de banco de dados. Possui
uma grande produtividade na gerao e manuteno de aplicativos relacionados a
banco de dados.
O Erwin possibilita uma visualizao da estrutura dos principais projetos
otimizados de banco de dados, comeando desde o modelo lgico dos requisitos
de informaes e regras empresariais que defininem o banco de dados at o
modelo fsico otimizado, respeitando as caractersticas particulares do banco de
dados destino. A ferramenta Erwin adaptvel a toda empresa quando houver
integrao ao modelo ModelMart. Esse modelo permite desde o desenvolvedor
at o usurio final compartilhem as informaes dos modelos do Erwin,
melhorando a produtividade e at mesmo proporcionando a criao de padres
corporativos.
O ERwin capaz de trabalhar com diversos tipos de banco de dados, entre eles:
O ERwin
Ingres II;
CA-Clipper;
DB2;
dBASE;
FoxPro;
Microsoft Access;
Microsoft SQL Server;
ODBC 2.0 & 3.0;
Oracle;
Paradox;
SQL Anywhere;
SQLBase.
possui como destaque a automatizao inteligente do processo do
projeto, ou seja, as visualizaes do banco de dados so cultivada como

componentes de modelos integrados, possibilitando que as modificaes nas
tabelas base se reflitam automaticamente na definio da visualizao. Um ponto
bastante relevante a migrao automtica das chaves garantindo uma maior
segurana e integridade ao banco de dados.
O ERwin
mantm os projetos lgicos e fsicos sincronizados, transformando
tambm relaes com construes lgicas do tipo muitos-para-muitos, em

implementaes fsicas. Permite a gerao automtica de tabelas, views, ndices,
normas de integridade referencial (chave primria, chave estrangeira), defaults e
restries de domnio/coluna.
3.4.2. PROJETO INTERATIVO DE SUPORTE COM COMPLETE-COMPARE
O Complete-Compare uma tecnologia que possibilita uma comparao entre os

modelos, quando alguma alterao realizada no modelo ou no banco de dados,
o recurso Complete-Compare disponibiliza uma abrangente visualizao de todas
as modificaes (diferenas) efetuadas. Gerando automaticamente um script para
permitir a atualizao de qualquer banco de dados sem alterar os dados
existentes. Podendo migrar as inconsistncias do modelo para banco de dados ou
vice - versa. O Complete-Compare sempre mantm o modelo sincronizado com o
banco de dados.
3.5.
FERRAMENTA CASE STUDIO
Segundo o fornecedor (CHARONWARE, 2005) a Engenharia Reversa extrai

entidades do banco de dados, atributos, relacionamentos, ndices, triggers,
procedimentos, e outros objetos dependendo do banco de dados. Alm de
possibilitar a facilidade de trabalhar com um nmero grande de bancos de dados,
a Ferramenta Case Studio oferece vrios tipos de mtodos de comunicao, entre
eles:
ODBC;
ADO;
BDE;
Conexes nativas diretas;
Detalhes do Case Studio.
A ferramenta Case Studio permite com que o usurio gere um cdigo detalhado
em HTML e a documentao do RTF. possvel redesenhar a estrutura do banco
de dados, inserir modelos dentro do Version Manager ou gerar um novo SQL
(DDL) scripts para a criao fsica de um novo banco de dados. Durante o
processo de Engenharia Reversa, a ferramenta Case Studio pode carregar vrios
objetos de bancos de dados selecionados.
Benefcios:
Desenvolvimento rpido e profissional;
Melhor produtividade;
Manuteno mais eficiente;
Execuo de Engenharia Reversa de diversos bancos de dados;
Verificao da consistncia e validade dos modelos criados;
Gerao detalhada de HTML e documentao RTF.
Recursos Principais:
Criao visual de diagramas ERD's;
Edio grfica de Data Flow diagrams (DFD's);
Gerao de scripts SQL databases, incluindo triggers;
Suporte permisso de grupos e usurios;
Integridade Referencial (Declarada ou via triggers);
Dicionrio de Dados;
Suporte a JScript e VBScript.
Suporta diversos tipos de Bancos de Dados, entre eles:
ACCESS 2000: Integridade Referencial; ndices; Queries
ACCESS 97: Integridade Refencial; ndices; Queries
DB2 UDB v. 8.1: Tablespace para tabelas; Checa restries; Restries

nicas;
ndices;
Triggers;
Procedimentos;
Vises;
Seqncias;
Permisses para Usurios e Grupos;
DB2 UDB v. 7: Checa restries; Restries nicas; ndices; Triggers;

Procedimentos; Vises; Usurios e Grupos; Permisses
DBIsam 3: Encrypted tables; Senhas de Tabelas; ndices
INFORMIX 9: Tipos de usurios utilizados; Integridade Referencial;

Checa restries; Restries nicas; ndices; Triggers; Procedimentos;
Funes;
Vises;
Aggregates;
Synonyms;
Usurios
Grupos;
Permisses.
INTERBASE 7: Integridade Referencial; Checa restries; Restries

nicas; ndices; Collations e conjuntos de Caracteres; Triggers;
Procedimentos; Funes Externas; Vises; Excees; Geradores; Blob
filters; Roles, Usurios e Permisses; descries
INTERBASE 6 SQL 1: Integridade Referencial; Checa restries;

Restries nicas; ndices; Collations e conjuntos de Caracteres;
Triggers, Procedimentos; Funes Externas;
Vises; Exceptions;
Geradores; Filtrares de Glbulo; Roles; Usurios e Permisses
MS SQL 2000: Filegroup para tabelas; ordena e reprime; Integridade

Referencial; Checa restries; Restries nicas; ndices; descries
para tabelas e colunas; Triggers; Procedimentos; Funes; Vises,
Usurios e Grupos; Permisses
MySQL 4: ndices; ndices nicos como chaves Alternadas; Integridade

Referencial, Usurios; Permisses.
MySQL 3.23: ndices; ndices nicos como chaves alternadas; Usurios;

Permisses
ORACLE 9I: Procedimentos, funes, vises, empacota no esquema
selecionado; tipos de usurios utilizados, ordena parmetros de

armazenamento de restries para tabelas; Checa restries; Restries
nicas; Ordena parmetros de Armazenamento para ndices; Triggers;
Procedimentos e Funes; Vises; Synonyms; Seqncias; Usurios, e
Permisses.
ORACLE 8: Procedimentos, funes, vises, empacota no esquema

selecionado; tipos de usurios utilizados, ordena parmetros de
armazenamento de restries para tabelas; Checa restries; Restries
nicas; Ordena parmetros de Armazenamento para ndices; Triggers;
Procedimentos e Funes; Vises; Synonyms; Seqncias; Usurios, e
Permisses.
PERVASIVE V8: Carrega integridade Referencial; Carrega restries

nicas e ndices; Carrega restries nicas em atributos; Carrega nomes
de restrio NO NULOS; Carrega Triggers; procedimentos; vises;
usurios e grupos; permisses
POSTGRESQL 7.3: Checa restries; Restries nicas; Integridade

Referencial; ndices; Triggers; Procedimentos e Funes; Vises;
Seqncias; Usurios, Agrupa Permisses; descries.
POSTGRESQL 7: Checa restries; Restries nicas; Integridade

Referencial; ndices; Triggers; Procedimentos e Funes; Vises;
Usurios, Grupos e Permisses; descries.
SYBASEASE1
2.5:
Integridade
Referencial;
Checa
restries;
Restries nicas; ndices; Triggers; Procedimentos; Funes; Vises;

Seqncias; Usurios e Grupos; Permisses.
3.6.
FERRAMENTA ROSE
Segundo o fornecedor (Rational, 2003), a ferramenta ROSE suporta a anlise e
projetos de sistemas orientados a objetos atravs da modelagem de dados na

linguagem UML. O Rose tambm fornece recursos para gerao de cdigo e
Engenharia Reversa de sistemas em vrias linguagens de programao,
integrao com bancos de dados, entre outros.
A ferramenta divida em trs verses:
Rose Modeler;
Rose Professional;
Rose Enterprise: Suporta Mltiplas Linguagens (VC++,VB, JAVA,

CORBA).
Diagramas disponveis na Ferramenta Rational ROSE:
Diagrama de Classes: Este diagrama ajuda a ter uma viso estrutural

ou esttica de um sistema, demonstrando os relacionamentos de cada
classe descrita.
Diagrama de Casos de Uso: utilizado no processo de anlise com o

intuito de capturar os requisitos do sistema, obtendo um maior
conhecimento de como o sistema dever se comportar.
Diagrama de Seqncia: Tem como funo mostrar todos os passos e

procedimentos dentro de um Caso de Uso.
Diagrama de Colaborao: Este diagrama possibilita uma viso das

interfaces dos relacionamentos estruturais entre os objetos.
Diagrama de Atividades: Modela o fluxo de um processo de negcio e

a seqncia das atividades do processo, utilizado para fazer a
modelagem do aspecto dinmico do sistema.
Diagrama de Componentes: Modela o aspecto fsico de um sistema

orientado a objetos enquanto fornece uma viso fsica do Modelo.
Diagrama de Implementao: Cada modelo possui apenas um nico

diagrama de implementao, tendo como objetivo principal mapear os
processos para o hardware; utilizado para a modelagem de uma viso
esttica da implantao de um sistema.
Diagrama de Transio de Estados: Este diagrama, mostra a

seqncias dos estados que um objeto pode passar, utilizado para
modelar comportamento dinmico de um sistema de classes ou objetos
de uma forma individual.
3.7.
FERRAMENTA SYSTEM ARCHITECT
Segundo o fornecedor (Choose, 2004), o System Architect uma ferramenta

Case, que suporta desde a fase inicial de anlise do software at as eventuais
manutenes que podero ocorrer aps a implantao do mesmo. Esta
ferramenta Case possui como recurso a gerao de scripts a partir de diagramas
vinculados ao banco de dados, dando suporte tambm para a Engenharia
Reversa.
O System Architect, abrange
o que se chama de Modelagem Corporativa,
incorporando Mapeamento e Modelagem do Negcio dos seus Processos,

Tecnologia, Organizao, Componentes e Objetos, Dados, Aplicaes e
Localizao. Acompanha todo o ciclo de desenvolvimento, desde levantamento de

requisitos at a fase de implementao, pois gera cdigo para diversas linguagens
e scripts para vrios banco de dados.
Algumas
das
metodologias
disponibilizadas na ferramenta System Architect segue abaixo:

Modelagem de Processos de Negcios: Os modelos disponveis na ferramenta
so os Modelos de Empresa, Modelos de Funes e Modelos de Fluxos de
Processos.
Modelagem Orientada a Objetos: A ferramenta d suporte aos padres
UML,
OMT e BOOCH e tambm disponibiliza os diagramas DFD (Diagrama de Fluxo

de Dados), Diagrama de Estrutura e Diagrama de Transio de Estados.
J na Modelagem de Dados, esto disponveis os Diagramas
Relacionamento (DER) e o Modelo Fsico de Dados.
Entidade
CAPTULO 4
Metodologia de Avaliao para Aquisio de
uma Ferramenta de Engenharia Reversa
Neste captulo ser apresentada uma metodologia para avaliar e selecionar
ferramentas de Engenharia Reversa, levando em considerao a intensidade da
situao - problema em que se encontra a documentao e a integridade dos
dados do sistema legado a ser analisado.
4. METODOLOGIA DE AQUISIO DE UMA FERRAMENTA DE ENGENHARIA

REVERSA
4.1.
VISO GERAL DA METODOLOGIA DE ESCOLHA DA FERRAMENTA DE ENGENHARIA
REVERSA
A Figura 4.1 representa os processos que sero adotados para a escolha de uma
ferramenta de Engenharia Reversa, desde o processo da identificao do sistema
atual, correlaes e pesos que sero adotados como diretrizes para definio da
ferramenta a ser adquirida na fase de reestruturao do sistema legado.
77
FIGURA 4.1 - DIAGRAMA DE ESCOLHA DA FERRAMENTA DE ER.

4.2.
DETALHAMENTO DA METODOLOGIA PROPOSTA
Esta primeira etapa ser dividida em trs fases: A primeira fase visa identificar
como se encontra o sistema atual em relao a sua documentao, plataforma e
habilidades que a equipe de desenvolvimento possui. Na segunda fase busca-se
saber quais documentos so considerados necessrios para a reestruturao do
sistema legado. A terceira fase tem como objetivo verificar as facilidades, recursos
e restries que cada ferramenta CASE possui.
A. Anlise do Sistema atual

A.1 Anlise do sistema legado
A.1.1 Identificar o Sistema Operacional: com esta opo

identificaremos
qual sistema operacional foi utilizado como plataforma de
execuo do sistema legado.
Definir o sistema operacional utilizado;
Definir a verso do sistema operacional utilizado.
A.1.2 Identificar a Linguagem do Sistema Legado: nesta etapa

ser identificada a linguagem que foi utilizada no desenvolvimento do sistema
legado.
A.1.3 Identificar o Banco de Dados do Sistema Legado: nesta
etapa ser identificado o Banco de Dados que foi utilizado no sistema legado.
A.2 Anlise da Equipe de desenvolvimento
A.2.1 Levantamento do Conhecimento tcnico da Equipe em
relao ferramenta de Engenharia Reversa: nesta etapa sero identificados os

nveis de conhecimento e a especializao de cada desenvolvedor em relao
ferramenta de Engenharia Reversa, visando documentar o grau de conhecimento
que a equipe possui para o desenvolvimento do novo sistema. Os itens citados
abaixo documentaro cada informao conseguida nesta diretriz.
Identificar os membros da equipe, com o nome completo;

Definir o tipo de conhecimento que possui em relao
ferramenta que est sendo analisada;
A.2.2 Levantamento do conhecimento de idiomas da equipe: nesta

etapa sero identificados os conhecimentos de lngua estrangeira que a equipe
possui, analisando-se o nvel de aprofundamento em cada idioma. Os itens
citados abaixo documentaro cada informao conseguida nesta diretriz.
Identificar o membro da equipe com o nome completo;
Definir
idioma
em
que
cada
desenvolvedor
possui
conhecimento.
A.3 Anlise do custo que ser investido
A.3.1 Estudar a viabilidade financeira para a aquisio da

ferramenta de Engenharia Reversa: nesta etapa ser feito um levantamento de
custos, visando projetar os valores que sero investidos no desenvolvimento do
novo projeto. Os itens citados abaixo documentaro cada informao conseguida
nesta diretriz.
Identificar o investimento que ser utilizado no processo de
desenvolvimento do novo sistema;
Definir o valor que ser investido.
A.3.2 Analisar a configurao das mquinas envolvidas na escolha

da ferramenta de Engenharia Reversa: Nesta etapa ser verificado o parque de
mquinas do setor de desenvolvimento administrativo, com o intuito de identificar
possveis atualizaes que se faam necessrias para o desenvolvimento do novo
sistema.
Identificar o departamento que utilizar a ferramenta;
Identificar a configurao dos equipamentos.
B. Anlise do tipo de Documentao desejada para o novo

Sistema
B.1
Definio dos tipos de Documentos desejados no
processo de reestruturao
B.1.1 Definir o tipo de documentao desejada para o processo de

levantamento dos dados: nesta etapa sero identificados os documentos que
devero ser criados para o novo sistema, visando documentar todas as fases do
processo de desenvolvimento do sistema legado e novo.
C. Anlise da Ferramenta de Engenharia Reversa

C.1 Definio de recursos que a Ferramenta suporta:
C.1.1 Recursos que a Ferramenta de Engenharia Reversa suporta:

nesta etapa identificaremos as funcionalidades, ou seja, os documentos
disponveis na ferramenta em questo, visando levantar os recursos agregados
mesma, que sero de extrema importncia na fase de desenvolvimento do novo
sistema. Os itens citados abaixo documentaro cada informao conseguida nesta
diretriz..
Identificar a ferramenta a ser analisada;
Descrever os tipos de recursos (documentao) disponveis na
ferramenta.
C.1.2 Verificar em quais idiomas a ferramenta de Engenharia

Reversa est disponvel: nesta etapa sero analisadas as opes de traduo
disponveis
na
ferramenta
estudada,
visando
documentar
uma
possvel
preferncia em um determinado idioma.
Listar os idiomas disponveis na ferramenta.
C.1.3 Descrever a configurao mnima exigida para a instalao

da ferramenta de Engenharia Reversa: nesta etapa sero informadas as
configuraes mnimas de hardware necessrios para um bom desempenho da
ferramenta.
Descrever a configurao mnima necessria para a utilizao
da ferramenta.
C.1.4 Linguagens disponveis na Ferramenta de Engenharia
Reversa: nesta etapa sero relacionadas s linguagens de programao que a

ferramenta a ser analisada disponibiliza para a realizao do processo de
Engenharia Reversa.
Identificar as linguagens de programao;
Descrever as verses das respectivas linguagens.
C.1.5 Banco de Dados disponveis na Ferramenta de Engenharia

Reversa: nesta etapa sero relacionados os bancos de dados que a ferramenta a
ser analisada disponibiliza para a realizao do processo de Engenharia Reversa.
Identificar os bancos de dados;
Descrever as verses dos respectivos bancos.
C.1.6
Sistema
Operacional
disponvel
na
ferramenta
de
Engenharia Reversa: nesta etapa sero relacionados quais sistemas operacionais

que a ferramenta de Engenharia Reversa suporta.
Identificar o tipo de sistema operacional;
Descrever as verses dos respectivos sistemas operacionais.
C.1.7 Custo para aquisio da Ferramenta de Engenharia

Reversa: nesta etapa sero analisados o custo da instalao da ferramenta e o
valor das licenas de uso para outras mquinas. Os itens citados abaixo
documentaro cada informao conseguida nesta diretriz.
Identificar as opes de investimento que a ferramenta de
Engenharia Reversa possui, para a aquisio do programa;
Definir o valor do investimento.
C.1.8 Descrever o tipo de atendimento on-line: nesta etapa sero

analisados os tipos de atendimento que a empresa responsvel pela ferramenta
CASE possui em relao aos seus clientes, visando qualidade, preo do suporte,
horrio do atendimento e a possibilidade de treinamentos aos adquirentes da
mesma. Os itens citados abaixo documentaro cada informao conseguida nesta
diretriz.
Identificar os tipos de atendimento ao usurio, disponibilizados
pela empresa.
4.3.
DEFINIES DOS TIPOS DE RELACIONAMENTO REFERENTES A SUAS CORRELAES
E ESCALAS DE VALORES
Devido s particularidades de cada correlao, o tipo de relacionamento ser

dividido em dois grupos:
Relacionamento com Escala: este tipo de relacionamento acontece

quando a correlao possui uma variao de impacto para quantificar a
resposta do desenvolvedor. As pontuaes que sero utilizadas no
relacionamento com escala esto identificadas na tabela 4.1.
TABELA 4.1 - ESCALA DE PONTOS DO TIPO RELACIONAMENTO COM ESCALA

Pontuao
3
2
1
0
Descrio
Altamente Recomendado
Recomendado
Fracamente Recomendado
No Recomendado
Relacionamento sem Escala: este tipo de relacionamento acontece

quando a correlao pontua o impacto da resposta do desenvolvedor de
uma forma objetiva, tendo como opo
somente duas variaes de
respostas. As pontuaes que sero utilizadas no relacionamento sem

escala esto identificadas na tabela 4.2.
TABELA 4.2 - ESCALA DE PONTOS DO TIPO RELACIONAMENTO SEM ESCALA
Pontuao Descrio
1
Recomendado
0
No Recomendado
4.3.1. CORRELAES IDENTIFICADAS PARA O PROCESSO DE ESCOLHA DE UMA
As diretrizes definidas na primeira etapa precisam ser correlacionadas na segunda

etapa, com o intuito de criar as informaes necessrias para sinalizar qual ou
quais ferramentas de Engenharia Reversa ser utilizada no processo de
reestruturao do sistema legado.
D. Diretrizes com Correlao

Correlao 1
Identificar o Sistema Operacional atual X Sistema Operacional disponvel na
ferramenta de Engenharia Reversa
Tipo de Relacionamento: Sem Escala
Indicativos:
Recomendado: Esta categoria indicada quando o sistema operacional e
sua verso forem compatveis ou iguais ao sistema operacional que a ferramenta
de Engenharia Reversa analisada suporta.
No Recomendado: Esta categoria indicada quando o sistema
operacional e a verso no forem compatveis com a ferramenta de Engenharia
Reversa analisada.
Correlao 2
Tipo de Documentao desejada para o processo de levantamento de dados X
Recursos que a Ferramenta de Engenharia Reversa suporta
Tipo do Relacionamento: Com Escala
Indicativos:
Altamente Recomendado: Esta categoria indicada quando o nmero de
documentos desejado para a fase de Engenharia Reversa for superior ou igual a
90% da documentao disponvel na ferramenta de Engenharia Reversa
analisada.
Recomendado: Esta categoria indicada quando o nmero de documentos
desejado para a fase de Engenharia Reversa for superior ou igual a 50% e inferior
de 90% da documentao disponvel na ferramenta de Engenharia Reversa
analisada.
Fracamente Recomendado: Esta categoria indicada quando o nmero de
documentos desejado para a fase de Engenharia Reversa for inferior ou igual a
49,9% e superior a 10% da documentao disponvel na ferramenta de
Engenharia Reversa analisada.
No Recomendado: Esta categoria indicada quando o nmero de
documentos desejado para a fase de Engenharia Reversa for inferior ou igual a
10% da documentao disponvel na ferramenta de Engenharia Reversa
analisada.
Correlao 3
Identificar a Linguagem do Sistema Legado X Linguagens disponveis na
Ferramenta de Engenharia Reversa
Tipo do Relacionamento: Sem Escala
Indicativos:
Recomendado: Esta categoria indicada quando a linguagem do sistema e
suas respectivas verses forem totalmente compatveis com a linguagem
disponvel na ferramenta de Engenharia Reversa analisada.
No Recomendado: Esta categoria indicada quando a linguagem do
sistema
e suas respectivas verses forem totalmente incompatveis com a
linguagem disponvel na ferramenta de Engenharia Reversa analisada.

Correlao 4
Identificar o Banco de Dados do Sistema Legado X Banco de Dados disponveis
na Ferramenta de Engenharia Reversa
Tipo do Relacionamento: Sem Escala
Indicativos:
Recomendado: Esta categoria indicada quando a base de dados e suas
respectivas verses forem compatveis com a linguagem disponvel na ferramenta
de Engenharia Reversa analisada.
No Recomendado: Esta categoria indicada quando a base de dados e
suas respectivas verses forem incompatveis com a base de dados disponvel na
ferramenta de Engenharia Reversa analisada.
Correlao 5
Conhecimento Tcnico da Equipe em relao Ferramenta de Engenharia
Reversa X Ferramenta de Engenharia Reversa analisada

Tipo do Relacionamento: Com Escala
Indicativos:
Altamente Recomendado: Esta categoria indicada quando a equipe de
desenvolvimento possui um conhecimento pleno da ferramenta de Engenharia
Reversa analisada.
Recomendado:
Esta
categoria
indicada
quando
equipe
de
desenvolvimento possui um conhecimento satisfatrio na ferramenta de

Engenharia Reversa analisada.
Fracamente Recomendado: Esta categoria indicada quando a equipe de
desenvolvimento possui um conhecimento restrito na ferramenta de Engenharia
Reversa analisada.
No Recomendado: Esta categoria indicada quando a equipe de
desenvolvimento no possui nenhum conhecimento na ferramenta de Engenharia
Reversa analisada.
Correlao 6
Conhecimento de Idiomas da Equipe de Desenvolvimento X Tradues
disponveis na Ferramenta de Engenharia Reversa analisada
Tipo de Relacionamento: Com Escala
Indicativos:
Altamente Recomendado:
Esta categoria indicada quando o idioma
disponvel para a ferramenta for considerado fluente para leitura. para a equipe de
desenvolvimento.
Recomendado: Esta categoria indicada quando o idioma disponvel para a
ferramenta for considerado interpretvel para leitura, para a equipe de
desenvolvimento.
Fracamente Recomendado: Esta categoria indicada quando o idioma
disponvel para a ferramenta for considerado pouco interpretvel para leitura, para
a equipe de desenvolvimento.
No Recomendado: Esta categoria indicada quando o idioma disponvel
para a ferramenta for considerado sem interpretao para leitura para a equipe de
desenvolvimento .
Correlao 7
Viabilidade financeira para a aquisio da Ferramenta de Engenharia Reversa X
Custo para aquisio da Ferramenta de Engenharia Reversa
Relacionamento: Com Escala
Indicativos:
Altamente Recomendado: Esta categoria indicada quando o valor da
ferramenta for inferior ao valor estimado para a aquisio da mesma.
Recomendado: Esta categoria indicada quando o valor da ferramenta for
igual ao valor estimado para a aquisio da mesma.
Fracamente Recomendado: Esta categoria indicada quando o valor da
ferramenta for maior do que 20% do valor estimado para a aquisio da mesma.
No Recomendado: Esta categoria indicada quando o valor da ferramenta
for maior do que 50% do valor estimado para a aquisio da mesma.
Correlao 8
Configurao da mquina da equipe de desenvolvimento X Configurao mnima
exigida para a instalao da Ferramenta de Engenharia Reversa
Relacionamento: Sem Escala
Indicativos:
Recomendado: Esta categoria indicada quando a configurao da
mquina for compatvel com as configuraes mnimas exigidas para a instalao
da ferramenta de Engenharia Reversa analisada.

No Recomendado: Esta categoria indicada quando a configurao da
mquina for incompatvel com as configuraes mnimas exigidas para a
instalao da ferramenta de Engenharia Reversa e tambm quando existir a
impossibilidade de realizar os upgrades necessrios para que seja viabilizada a
instalao da ferramenta de Engenharia Reversa analisada.
E. Diretriz sem correlao

A diretriz Anlise de Suporte on-line resultar em um grfico de qualidade
especificando o tipo de atendimento que cada ferramenta possui disponvel em
seu processo de suporte ao usurio (desenvolvedor).
F. Pesos para as correlaes

A terceira etapa definir as correlaes que devero ser pontuadas com seus
respectivos pesos j propostos na metodologia de escolha da ferramenta de
Engenharia Reversa, visando minimizar ou maximizar a importncia de cada
correlao de acordo com a situao-problema em que se encontra o sistema
legado a ser reestruturado. Os pesos que sero utilizados nas correlaes esto
identificados na tabela 4.3.
TABELA 4.3 - PESOS DAS CORRELAES DA METODOLOGIA DE ER
Tipos
Prioridade Baixa
Prioridade Mdia
Prioridade Alta
Pesos
1
2
3
CAPTULO 5
Estudo de Caso
O estudo de caso realizado baseia-se no Sistema de Gesto Escolar (SGE)
verso 2.0, desenvolvido pela Coordenadoria de Informtica Administrativa, que
tem como funo atender a secretaria e a tesouraria da instituio. O sistema
(SGE) possui como funcionalidade o controle dos alunos, desde o momento da
inscrio para o processo seletivo at o final de sua vida acadmica e financeira
na instituio. O sistema citado possua um legado em Delphi com banco de
dados em SQL, no possuindo nenhuma documentao para a interpretao dos
campos, integridades e restries que o mesmo poderia ter. A metodologia
proposta neste trabalho, ajudar identificar qual ferramenta de Engenharia
Reversa ir se adequar com o cenrio problema da Instituio em questo.
5. ESTUDO DE CASO - DADOS DA PESQUISA
Sistema Analisado: Sistema Acadmico e Financeiro

Data da Pesquisa : 10 de Fevereiro de 2005
Entrevistado
: Analista Chefe - Setor Desenvolvimento
Os dados da primeira etapa, no foram entregues pela Instituio analisada, pelo

motivo de serem considerados confidenciais. Os resultados obtidos nos quadros
abaixo representam as informaes geradas pelas respostas das etapas
posteriores, j correlacionadas com suas respectivas diretrizes.

QUADRO 5.1 - RESPOSTAS DA CORRELAO 1
Ferramentas
ERWIN
DR. CASE
STUDIO
DB MAIN
ROSE
SA
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
1
X
1
X
1
X
1
X
1
X
1

Ferramenta
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
3
x
2
X
2
X
2
X
0
X
2

Ferramentas
ERWIN
DR. CASE
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
1
X
1
CASE STUDIO
DB MAIN
ROSE
SA
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
X
1
X
1
X
0
X
1

Ferramentas
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
1
X
1
X
1
X
1
X
1
X
1

Ferramenta
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
3
X
2
X
1
X
0
X
0
X
0

Ferramenta
ERWIN
Relacionamento
Recomendado
No Recomendado
Respostas
X
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
1
X
3
X
1
X
1
X
1
X
1

Ferramenta
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
Respostas
X
3
X
3
X
3
X
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
ROSE
SA
3
X
1
X
1

Ferramentas
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
1
X
1
X
1
X
1
X
1
X
1
Tipo de atendimento on-line em relao s ferramentas de Engenharia Reversa

analisada.
QUADRO 5.9 - RESPOSTAS DA DIRETRIZ SEM CORRELAO ATENDIMENTO ON-LINE
Ferramenta
ERWIN
DR. CASE
CASE STUDIO
DB MAIN
ROSE
SA
5.1.
Relacionamento
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Recomendado
No Recomendado
Total
Respostas
X
3
X
3
X
1
X
1
X
2
X
2
RESULTADOS DAS CORRELAES REFERENTES S RESPOSTAS DAS DIRETRIZES
A figura 5.1 representa os resultados referentes s respostas das correlaes e os

indicativos correspondentes pesquisa realizada para a escolha da ferramenta de
Engenharia Reversa, neste momento ainda no est sendo levado em
considerao o peso que definem o grau de importncia de cada correlao, de
acordo com o cenrio problema da Instituio que est sendo analisada.

Correlao 1
1
0,8
Pontos 0,6
Recebidos 0,4
0,2
0
ERWIN
DR. STUDIO MAIN

CASE
Ferramentas
ROSE
FIGURA 5.1 - GRFICO REFERENTE S RESPOSTAS DA CORRELAO 1

Correlao 2
3
2,5
2
Pontos
1,5
Recebidos
1
0,5
0
ERWIN DR. STUDIO MAIN ROSE

CASE
Ferramentas

Correlao 3
1
0,8
Pontos 0,6
Recebidos 0,4
0,2
0
ERWIN
DR. STUDIO MAIN

CASE
Ferramentas
ROSE

Correlao 4
1
0,8
Pontos 0,6
Recebidos 0,4
0,2
0
ERWIN
DR. STUDIO MAIN

CASE
Ferramentas
ROSE

Correlao 5
3
2,5
2
Pontos
1,5
Recebidos
1
0,5
0
ERWIN
DR. STUDIO MAIN

CASE
Ferramentas
ROSE

Correlao 6
3
2,5
2
Pontos
1,5
Recebidos
1
0,5
0
ERWIN
DR. STUDIO MAIN

CASE
Ferramentas
ROSE
SA

Correlao 7
3
2,5
2
Pontos
1,5
Recebidos
1
0,5
0
ERWIN
DR. STUDIO MAIN

CASE
ROSE
SA
Ferramenta

Correlao 8
1
0,8
Pontos 0,6
Recebidos 0,4
0,2
0
ERWIN
DR. STUDIO MAIN

CASE
ROSE
SA
Ferramentas
Atendimento on-line
3
2,5
2
1,5
1
0,5
0
ERWIN
DR. STUDIO
CASE
MAIN
ROSE
SA
Tipo de atendimento on-line em relao s ferramentas de Engenharia Reversa

analisada.
FIGURA 5.9 - GRFICO REFERENTE DIRETRIZ SEM CORRELAO ATENDIMENTO ON-LINE
5.2.
PESOS ATRIBUDOS PARA AS CORRELAES
Os pesos descritos na tabela 5.1, foram preenchidos de acordo com a

necessidade do responsvel pela escolha da ferramenta de Engenharia Reversa,
levando em considerao o cenrio pertinente a sua situao.
TABELA 5.1 - PESOS INDICADOS PELO DESENVOLVEDOR

Correlaes
Correlao 1
Correlao 2
Correlao 3
Correlao 4
Correlao 5
Correlao 6
Correlao 7
Correlao 8
Indicativo (Atendimento
on-line)
5.3.
Pesos
3
3
3
3
2
1
2
1
2
RESULTADO FINAL DAS CORRELAES
Analisando a Figura 5.10, podemos concluir que as ferramentas mais prximas do

cenrio parametrizado pelo avaliador, foram as ferramentas ERWIN e DR.CASE,
atingindo assim, o foco principal da metodologia proposta, que sinalizar qual ou
quais ferramentas se aproximam da situao problema que se encontra a
empresa em relao ao seu sistema legado.
Total Geral das Correlaes (1 a 8)

40
30
Pontos
Recebidos 20
(Geral)
10
0
Total Geral
ERWIN
32
DR.CASE STUDIO
29
25
MAIN
ROSE
SA
23
10
19
Ferramentas
FIGURA 5.10 - RESULTADO FINAL DAS CORRELAES (1 A 8)

Analisando a Figura 5.11, podemos verificar que aps a insero dos valores
referente diretriz atendimento on-line, os resultados foram alterados, mas as
ferramentas indicadas na Figura 5.10, continuam na mesma ordem de coeso
com o cenrio parametrizado pelo avaliador.
Total Geral das Correlaes (1 a 8) com os Indicativos

de Atendimento on-line
40
30
Pontos
Recebidos 20
(Geral)
10
0
Total Geral
ERWIN
38
DR.CAS STUDIO
35
27
MAIN
ROSE
SA
25
14
23
Ferramentas
FIGURA 5.11 - RESULTADO FINAL DAS CORRELAES ACRESCENTANDO

INDICATIVOS DE ATENDIMENTO ON-LINE
OS
CAPTULO 6
Concluso
Aps vrias pesquisas dentro da comunidade de Engenharia Reversa
com o
objetivo de localizar uma metodologia de escolha de uma ferramenta para ajudar a

reestruturar o sistema atual, no foi encontrado nenhum trabalho que propusesse
ao desenvolvedor diretrizes parametrizadas de acordo com o cenrio- problema
em que se encontra o sistema legado. Ento, foi proposta nesta dissertao uma
metodologia para escolha de uma ferramenta de Engenharia Reversa, com o
intuito de minimizar as possibilidades de erro existentes nesta fase, considerada
crucial para a reestruturao de um sistema legado.
A estratgia proposta para o processo de escolha da ferramenta de Engenharia
Reversa
abrange trs etapas: a primeira etapa auxilia o desenvolvedor a
conhecer dificuldades e facilidades que possui em relao ao sistema legado. Na

segunda etapa analisado cada item da etapa anterior, com o intuito de verificar
possveis correlaes que possam gerar as informaes necessrias para a
escolha da ferramenta mais indicada. Aps o estudo, foram identificadas oito
correlaes diferentes e uma diretriz sem correlao.
Identificou-se, atravs do estudo de caso realizado com a Instituio de Ensino, a
necessidade de priorizar algumas correlaes de acordo com o cenrio em
questo. Com isto, foi definida a terceira etapa, que permite ao responsvel pelo
projeto de reestruturao do sistema legado
a indicao da correlao mais
importante, dando-lhe a possibilidade de personalizar a sua situao problema na

metodologia proposta neste trabalho.
Aps a concluso das trs etapas, foi detectada,
na empresa que utilizou a
metodologia proposta, uma posio favorvel em relao aos resultados,

contribuindo de uma forma segura e clara no processo da escolha da ferramenta
de Engenharia Reversa.
A metodologia foi desenvolvida em um perodo de treze meses, devido ao grande

nmero de informaes iniciais necessrias para sua concepo, portanto foi
necessrio estudar vrias ferramentas e mtodos de Engenharia Reversa com o
intuito de definir quais itens e quais caminhos seriam considerados importantes
para sinalizar a melhor ferramenta.
As diretrizes foram definidas, mas o problema encontrado nesta etapa estava na
individualizao de cada diretriz elicitada, no proporcionando ao desenvolvedor
as informaes necessrias. A soluo encontrada foi s correlaes entre as
diretrizes (dados), com a inteno de proporcionar a definio dos indicativos para
a escolha da melhor ferramenta de Engenharia Reversa no
processo de
reestruturao do sistema atual.

O objetivo foi alcanado, mas foi detectada uma nova dificuldade: a necessidade
da personalizao de cada informao (correlao) em relao ao grau de
importncia da situao problema do sistema legado. O caminho encontrado foi a
definio de pesos que permitisse ao desenvolvedor indicar qual correlao era
considerada mais importante de acordo com o cenrio em questo.
Como trabalho futuro indica-se a necessidade da criao de um aplicativo, cuja
funo seria proporcionar maior facilidade nas inseres dos dados e uma maior
agilidade nas concluses dos resultados gerados atravs desta metodologia.
REFERNCIAS BIBLIOGRFICAS
ABDELWAHAB. H.; LETHBRIDGE, T. A survey of trace exploration tools and

techniques. IBM Centre for Advanced Studies Conference, 2004
ANQUETIL, Nicolas. COS 826 - Tpicos especiais em engenharia de software VII
(Engenharia Reversa). Disponvel em: < http://www.cos.ufrj.br/~nicolas/RevEng/
index.html >. Acesso em: 10 abr. 2002.
BATTAGLIA M.; SAVOIA, G.; FAVARO, J. Renaissance: A method to migrate from
legacy to immortal software systems. In: EUROMICRO CONFERENCE ON
SOFTWARE MAINTENANCE AND REENGINEERING, CSMR98, 1998, 2.,
Florence, Italy, 1998. p.197-200.
BENEDUSI, P. ; CIMILETE, A; CARLINI, U. Reverse engineering processes,
Design Document Production and Structure Charts J. Systems Software. 1992.
v.19, p. 225-45.
BRAGA, R.T.V. Padres de softwares a partir da engenharia reversa de sistemas
Legados. So Carlos: USP, 1998. 144 p.
CHARONWARE, S.R.O. Case estudio technical support web site. Disponvel em: <
<http://www.casestudio.com> >. Acesso 06 out. 2003.
CHARONWARE, S.R.O. Case studio. Disponvel em:< http://www.casestudio.com
>. Acesso 10 fev. 2005.
CHIKOFSKY, Eliot J.; CROSS, James H. Reverse engineering and design
recovery: a Taxonomy. IEEE Software: v.7, n., p. 13-17, jan. 1990. Disponvel
em: < http://reengineer.org/tcse/revengr/Chik%20Cross.pdf >. Acesso em: 6 out.
2004.
CHOOSE
technologies.
System
Architect.
Disponvel
http://www.choose.com.br >. Acesso em: 20 Fev. 2004.
em:
<
COSTA, R. M. Fusion-RE/I: Um mtodo de engenharia reversa para auxiliar

manuteno de software. 1997. 112 f. Instituto de Cincias Matemticas e de
Computao - ICMC -USP, So Carlos, 1997.
FELTRIM, V.D. Apoio a documentao de engenharia reversa de software por
meio de hipertextos. So Carlos: USP, 1999. 120 p.
FISS, Leandro. Definio de uma base de dados para o novo sistema da biblioteca
setorial de cincias e tecnologia. Pelotas: UFPel, 2001.
GALL, Harald C.; KLSH, Ren R.; MITTERMEIR, Roland T. Application patterns
in re-engineering: Identifying and Using Reusable Concepts. In:
INTERNATIONAL CONFERENCE ON INFORMATION PROCESSING AND
MANAGEMENT OF UNCERTAINTY IN KNOWLEDGE-BASED SYSTEMS, 6.,
1996.Granada: 1996. p. 1099-106. v.3.
GALL, H., Klsch R.; Kofler E.; Wrfl L. (1994). Balancing in Reverse Engineering
and in Object-Oriented Systems Engineering to Improve Reusability and
Maintainability. In: COMPUTER SOFTWARE AND APPLICATIONS
CONFERENCE, COMPSAC94, 18, 1994, IEEE. 1994.
GHANNOUCHI, S.A.; GHEZALA, H. H.; KAMOUN, F. A Generic approach for
data reverse engineering taking into account application domain knowledge. In:
EUROMICRO CONFERENCE ON SOFTWARE MAINTENANCE AND
REENGINEERING, CSMR98, 2., 1998. Florence, Italy. 1998. p. 21-8.
HAINAUT, Jean-Luc. DB-MAIN project - Head: the DB-MAIN Case tool
presentation.
Disponvel
em:<
http://www.info.fundp.ac.be
/~dbm/informations.html <http://www.info.fundp.ac.be/~dbm/informations.html>
>. Acesso em: 10 Jan. 2005.
MUHAMMAD R. A. Why Teach Reverse Engineering?. Communication of the
ACM, July 2005. Disponvel em: < https://portal.acm.org/poplogin.cfm>. Acesso
em: 26 out. 2004.
MLLER, H ; JAHNKE, J ; SMITH, D; STOREY, M, TILLEY, S ; WONG, K.
Reverse Engineering: A Roadmap: ACM , 2000. Disponvel em: <
https://portal.acm.org/poplogin.cfm>. Acesso em: 25 out. 2004.
PENTEADO, R. A. D. Um Mtodo para Engenharia Reversa Orientada a
Objetos.1996. 237 f. Dissertao (Doutorado em Fsica Computacional)Instituto de Fsica de So Carlos, Universidade de So Paulo, So Carlos,
1996.
PENTEADO, R. D; BRAGA, R. T .V; CAGNIN, M. I; MASIERO, P. C.
Reengineering using design patterns. In: WORKING CONFERENCE ON
REVERSE ENGINEERING, 7., 2000, Brisbane-Australia: IEEE, 2000. p. 118-27.
PRESSMAN, R.S. Engenharia de software. So Paulo: Makron, 1994.
RATIONAL Corporation. Disponvel em: < http://www.rational.com >. Acesso em
19 set. 2003.
ROBSON, D.J.; BENNET, K. H.;CORNELIUS, B.J; MUNRO, M. Approaches to
program comprehension. Journal of Systems and Software, .v. 14, fev. p.79-84,
fev. 1991.
RUGABER, S. Program comprehension for reverse engineering. In: AAAI
WORKSHOP ON AI AND AUTOMATED PROGRAM UNDERSTANDING. San
Jose, California, 1992. p. 106-10. Disponvel em: < http://www.cc.gatech.edu/
reverse/repository/aaai.pospap.ps+RUGABER,+S.++Program+comprehension+
for+reverse+engineering%22 >. Acesso em: 01 set. 2004
SALEH, K; BOUJARWAH, A. Comunications software reverse engineering: a semi
automatic approach. Information and software technology. Oxford, v.38, n.6, p.
379-90, 1996.
SANTOS, Ana Claudia Miguel dos. Tutorial ERWIN. Disponvel em:<
http://www.anaclaudiamsantos.hpg.ig.com.br/TURORIAL%20ERWIN.htm
>.
Acesso em: 8 out. 2003.
SCHNEIDEWIND, N.F. The state of software maintenance. IEEE Transactions on
Software Engineering. v.13, n.3, p.303-10, mar. 1987.
SHNEIDERMAN, Ben; MAYER, Richard. Syntatic/ Semantic Interactions in
Programmer Behavior. A model and experimental results. International Journal
of Computer and Information Sciences, v.8, p. 219 - 38, 1979.
SNEED, H. M.; NYRY, E. Extracting object-oriented specification from
procedurally oriented programs. In: WORKING CONFERENCE ON REVERSE
ENGINEERING, WCRE95, 2., 1995, Toronto USA: IEEE Computer Society
Press, 1995. p. 217-26.
SQUADRA tecnologia. Web site. Ajuda on-line sobre Dr. Case. Disponvel em:<
http://www.squadra.com.br >. Acesso em: 7 out. 2004.

Engenharia Reversa

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia Reversa

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Metodista de Piracicaba Faculdade de

Cincias Matemticas, da Natureza e Tecnologia da Informao.

METODOLOGIA DE AVALIAO PARA AQUISIO DE UMA

ANTONIO MATEUS LOCCI

Dissertao apresentada ao Programa de PsGraduao em Cincia da Computao, da Faculdade

FERRAMENTA DE ENGENHARIA REVERSA

AUTOR: ANTONIO MATEUS LOCCI

Profa. Dra. Rogria Cristiane Grato de Souza

Profa. Dra. Tereza Gonalves Kirner

Prof. Dr. Luiz Eduardo Galvo Martins

Ao professor Dr. Luiz Eduardo Galvo Martins pela orientao,

Eduquem-se os meninos e no ser

PALAVRAS-CHAVE: Engenharia Reversa, Ferramenta Case, Correlaes,

METHODOLOGY OF EVALUATION FOR ACQUISITION OF A

ENGENHARIA REVERSA ................................................................................... 3

CONCEITOS DE ENGENHARIA REVERSA ..................................................................... 3

MTODO FUSION RE/I ........................................................................................... 11

RECUPERAO DE VISES FUNCIONAIS - ETAPA 1................................................... 12

MTODO SNEED & NYRY ...................................................................................... 19

MTODO DE ABORDAGEM GENRICA DE ENGENHARIA REVERSA .............................. 23

FERRAMENTA CASE ...................................................................................... 26

FERRAMENTA CASE STUDIO................................................................................ 32

FERRAMENTA SYSTEM ARCHITECT .................................................................... 37

METODOLOGIA DE AQUISIO DE UMA FERRAMENTA DE ENGENHARIA REVERSA 39

VISO GERAL DA METODOLOGIA DE ESCOLHA DA FERRAMENTA DE ENGENHARIA

CORRELAES IDENTIFICADAS PARA O PROCESSO DE ESCOLHA DE UMA FERRAMENTA

ESTUDO DE CASO - DADOS DA PESQUISA....................................................... 54

RESULTADOS DAS CORRELAES REFERENTES S RESPOSTAS DAS DIRETRIZES ....... 64

REFERNCIAS BIBLIOGRFICAS ................................................................................ 73

FIGURA 2.1 - FASES DA ENGENHARIA REVERSA .................................................... 07

FIGURA 5.10 - RESULTADO FINAL DAS CORRELAES (1 A 8)............................... 70

LISTA DE ABREVIATURAS E SIGLAS

ActiveX Data Objects

Borland Database Engine

Computer-Aided Software Engineering

Comitee For Data Systems Language

Data Base Manager System

Diagrama de Entidade e Relacionamento

Diagrama de Fluxo de Dados

Dynamic Link Library

Document Type Definitions

Hyper Text Markup Language

Integrated Data Stored

Information Management System

Modelo de Anlise do Sistema Atual

Modelo de Anlise do Sistema

Open Database Connectivity

Object Modeling Technique

Engenharia Reversa / Interface

Rich Text Format

Sistema de Gerenciamento de Banco de Dados

Sistema de Gesto Escolar

Structured Query Language

Unified Modeling Language

Extensible Mankup Language

TABELA 4.1 - ESCALA DE PONTOS DO TIPO RELACIONAMENTO COM ESCALA ........... 47

QUADRO 2.1 - EXEMPLOS DAS RELAES - FUSION / RE......................................... 9

A Engenharia Reversa surgiu como uma metodologia, que estuda a construo de

Mtodos de Engenharia Reversa

Neste captulo so apresentados os conceitos e mtodos da Engenharia Reversa,

CONCEITOS DE ENGENHARIA REVERSA

Com o aumento da utilizao de programas para o gerenciamento de grandes

fundamentais: entendimento, modificao e a revalidao do sistema. Sendo que