METODOLOGIA DE AVALIAÇÃO PARA AQUISIÇÃO DE UMA FERRAMENTA DE ENGENHARIA REVERSA ANTONIO MATEUS LOCCI ORIENTADOR: PROF. DR. LUIZ EDUARDO GALVÃO MARTINS

Transcrição

1 Universidade Metodista de Piracicaba Faculdade de Ciências Matemáticas, da Natureza e Tecnologia da Informação. Programa de Pós-Graduação em Ciência da Computação METODOLOGIA DE AVALIAÇÃO PARA AQUISIÇÃO DE UMA FERRAMENTA DE ENGENHARIA REVERSA ANTONIO MATEUS LOCCI ORIENTADOR: PROF. DR. LUIZ EDUARDO GALVÃO MARTINS Dissertação apresentada ao Programa de Pós- Graduação em Ciência da Computação, da Faculdade de Ciências Matemáticas, da Natureza e Tecnologia da Informação, da Universidade Metodista de Piracicaba - UNIMEP, como requisito para obtenção do Título de Mestre em Ciência da Computação. PIRACICABA,SP 2006METODOLOGIA DE AVALIAÇÃO PARA AQUISIÇÃO DE UMA FERRAMENTA DE ENGENHARIA REVERSA

2 AUTOR: ANTONIO MATEUS LOCCI ORIENTADOR: LUIZ EDUARDO GALVÃO MARTINS Profa. Dra. Rogéria Cristiane Gratão de Souza UNESP - São José do Rio Preto Profa. Dra. Tereza Gonçalves Kirner UNIMEP Prof. Dr. Luiz Eduardo Galvão Martins UNIMEP

3 À Minha noiva Vanessa, pelo apoio e compreensão. Aos Meus pais Antonio Carlos e Maria Aparecida. AGRADECIMENTOS Ao longo deste período de estudos e pesquisas tenho muito a agradecer. Primeiramente, a DEUS que não me deixou fraquejar e desistir, em uma fase tão importante e singular da minha vida.

4 Ao professor Dr. Luiz Eduardo Galvão Martins pela orientação, compreensão, encorajamento e incentivo dedicado ao desenvolvimento deste trabalho. Aos meus pais Antonio Carlos e Maria Aparecida, pela educação concedida, afeto e compreensão nos momentos mais difíceis. As minhas irmãs Rita de Cássia e Claudia Fernanda, pela disposição, dedicação e companheirismo em situações 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 tão importante da vida. Ao meu cunhado Julio César, pela atenção nos momentos finais da minha dissertação. Aos amigos, André e Patrícia pelo apoio e disposição na finalização da minha dissertação. As secretárias Solange e Rosa, pela disposição no atendimento junto à secretaria da Universidade, quanto a dúvidas acadêmicas. Aos meus colegas de mestrado pela oportunidade de tê-los conhecido e convivido em momentos tão diversos. A minha instituição (ALIE) e amigos de trabalho, pelo apoio e compreensão no decorrer da minha dissertação.

5 Eduquem-se os meninos e não será preciso castigar os homens." (Pitágoras)

6 RESUMO A maioria dos sistemas já implantados ou em processo de implantação possuem uma restrita documentação de apoio ao desenvolvimento, e em muitos casos nenhuma documentação. Isto é atribuído aos cronogramas com tempos reduzidos, que são aplicados para o desenvolvimento do software ou à falta de experiência do desenvolvedor neste processo. A contribuição deste trabalho está voltada exclusivamente em propor uma metodologia de escolha de uma ferramenta para a Engenharia Reversa, levando em consideração a intensidade da situação problema que se encontra a documentação do sistema legado. Os métodos estudados foram: Fusion RE, Fusion RE/I, Renaissance, Sneed & Nyáry, Abordagem Genérica De Engenharia Reversa e as ferramentas Case estudas foram: Dr. Case, Dbmain, Erwin, Case Studio, SA, Rose. O processo de avaliação proposto na metodologia dividiu-se em três etapas principais: identificação do sistema atual, definições das correlações e a pontuação dos pesos para cada correlação, permitindo ao desenvolvedor personalizar a metodologia de escolha com o cenário atual que se encontra o sistema legado a ser reestruturado. Foi realizado juntamente com uma Instituição de Ensino, um estudo de caso, para localizar uma ferramenta CASE de Engenharia Reversa com o intuito de auxiliar o processo de reestruturação do sistema legado. Os resultados obtidos foram satisfatórios em relação à metodologia e também para a Instituição que utilizou a mesma para sinalizar a melhor ferramenta CASE de Engenharia Reversa de acordo com o cenário que se encontrava o sistema atual. PALAVRAS-CHAVE: Engenharia Reversa, Ferramenta Case, Correlações, Métodos de Engenharia Reversa, Sistemas Legados.

7 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 & Nyáry, 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

8 RESUMO...V ABSTRACT...VI LISTA DE FIGURAS...IX LISTA DE ABREVIATURAS E SIGLAS...X LISTA DE TABELAS...XI LISTA DE QUADROS...XII 1. INTRODUÇÃO ENGENHARIA REVERSA CONCEITOS DE ENGENHARIA REVERSA MÉTODO FUSION / RE OBJETIVOS PROCEDIMENTOS E RESULTADOS MÉTODO FUSION RE/I OBJETIVO RECUPERAÇÃO DE VISÕES FUNCIONAIS - ETAPA RECUPERAÇÃO DE VISÕES ESTRUTURAIS - ETAPA MÉTODO RENAISSANCE OBJETIVOS PROCEDIMENTOS E RESULTADOS DETALHAMENTO DO MÉTODO E RESULTADOS MÉTODO SNEED & NYÁRY OBJETIVOS PROCEDIMENTOS E RESULTADOS MÉTODO DE ABORDAGEM GENÉRICA DE ENGENHARIA REVERSA OBJETIVOS PROCEDIMENTOS E RESULTADOS FERRAMENTA CASE CONCEITO FERRAMENTA DR. CASE CARACTERÍSTICAS FERRAMENTA DB-MAIN CARACTERÍSTICAS FERRAMENTA ERWIN CARACTERÍSTICAS PROJETO INTERATIVO DE SUPORTE COM COMPLETE-COMPARE FERRAMENTA CASE STUDIO CARACTERÍSTICAS FERRAMENTA ROSE CARACTERÍSTICAS FERRAMENTA SYSTEM ARCHITECT CARACTERÍSTICAS METODOLOGIA DE AQUISIÇÃO DE UMA FERRAMENTA DE ENGENHARIA REVERSA VISÃO GERAL DA METODOLOGIA DE ESCOLHA DA FERRAMENTA DE ENGENHARIA

9 REVERSA DETALHAMENTO DA METODOLOGIA PROPOSTA DEFINIÇÕES DOS TIPOS DE RELACIONAMENTO REFERENTES A SUAS CORRELAÇÕES E ESCALAS DE VALORES CORRELAÇÕES IDENTIFICADAS PARA O PROCESSO DE ESCOLHA DE UMA FERRAMENTA DE ENGENHARIA REVERSA ESTUDO DE CASO - DADOS DA PESQUISA RESULTADOS DAS CORRELAÇÕES REFERENTES ÀS RESPOSTAS DAS DIRETRIZES PESOS ATRIBUÍDOS PARA AS CORRELAÇÕES RESULTADO FINAL DAS CORRELAÇÕES REFERÊNCIAS BIBLIOGRÁFICAS... 73

10 LISTA DE FIGURAS FIGURA FASES DA ENGENHARIA REVERSA FIGURA MODELO FUSION / RE FIGURA DESENVOLVIMENTO DE UM NOVO SISTEMA FIGURA DIAGRAMA DE ESCOLHA DA FERRAMENTA DE ER FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE AS RESPOSTAS DA CORRELAÇÃO FIGURA GRÁFICO REFERENTE A DIRETRIZ SEM CORRELAÇÃO ATENDIMENTO ON-LINE FIGURA RESULTADO FINAL DAS CORRELAÇÕES (1 A 8) FIGURA RESULTADO FINAL DAS CORRELAÇÕES ACRESCENTANDO OS INDICATIVOS DE ATENDIMENTO ON-LINE... 70

11 LISTA DE ABREVIATURAS E SIGLAS ADO BDE CASE CODASYL DBMS DER DFD DLL DTD ER HTML IDS IMS MASA MAS ODBC OMT RE/I RTF SA SGDB SGE SQL UML XML 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 Engenharia Reversa Hyper Text Markup Language Integrated Data Stored Information Management System Modelo de Análise do Sistema Atual Modelo de Análise do Sistema Open Database Connectivity Object Modeling Technique Engenharia Reversa / Interface Rich Text Format System Architect Sistema de Gerenciamento de Banco de Dados Sistema de Gestão Escolar Structured Query Language Unified Modeling Language Extensible Mankup Language

12 LISTA DE TABELAS TABELA ESCALA DE PONTOS DO TIPO RELACIONAMENTO COM ESCALA TABELA ESCALA DE PONTOS DO TIPO RELACIONAMENTO SEM ESCALA TABELA PESOS DAS CORRELAÇÕES DA METODOLOGIA DE ER TABELA PESOS INDICADOS PELO DESENVOLVEDOR LISTA DE QUADROS

13 QUADRO EXEMPLOS DAS RELAÇÕES - FUSION / RE... 9 QUADRO ETAPA DO MÉTODO FUSION RE/I QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA CORRELAÇÃO QUADRO RESPOSTAS DA DIRETRIZ SEM CORRELAÇÃO ATENDIMENTO ON-LINE 63 CAPÍTULO 1 Introdução 1. INTRODUÇÃO A Engenharia Reversa surgiu como uma metodologia, que estuda a construção de ferramentas, para extrair informações referentes à análise e projeto a partir de programas já implementados. Tem como vantagem principal permitir a documentação e o entendimento de sistemas que possuem pouca ou nenhuma documentação. O processo de Engenharia Reversa, não é considerado uma tarefa muito simples, exigindo um alto custo benefício (pessoa / tempo) para a realização da mesma. Isso acontece, devido ao grande volume de informações inseridas no processo de revitalização do sistema que está sendo analisado, onde a complexidade maior está em manter a coerência dos relacionamentos juntamente com as suas respectivas informações (regras de negócio) contidas no sistema legado para o

14 novo sistema. Sendo assim, o objetivo deste trabalho foi desenvolver um método para escolha de uma ferramenta de Engenharia Reversa, que permita maior precisão ao ser aplicado no processo de reestruturação de um sistema legado. Neste momento é muito importante a análise de todas as informações disponíveis para a definição da ferramenta de Engenharia Reversa a ser adquirida. Este trabalho permitirá que o processo de escolha seja amparado por uma metodologia, cuja concepção vem das correlações pré-definidas e também com a possibilidade de permitir a criação de novas correlações, visando facilitar, agilizar e personalizar a metodologia, com os cenários diversificados que possuem os sistemas legados. Outro ponto relevante é a possibilidade que o desenvolvedor responsável pela escolha da ferramenta de Engenharia Reversa terá com a utilização dos pesos para cada correlação, já propostos na metodologia, permitindo assim, minimizar ou maximizar a importância das correlações de acordo com a situação- problema do sistema legado que está sendo analisado. Este trabalho está organizado como segue: No capítulo 2 são relatados os conceitos e métodos utilizados no processo de Engenharia Reversa. No capítulo 3 são descritos os conceitos e as características das ferramentas do tipo CASE, que são utilizadas como apoio ao processo de recuperação do sistema legado. No capítulo 4 será apresentada a metodologia de escolha de uma ferramenta de Engenharia Reversa, levando sempre em consideração a complexidade da situação-problema em que se encontra a documentação e a adaptação da metodologia em cenários diversificados. No capítulo 5 é apresentado um estudo de caso, com intuito de validar a metodologia proposta. O capítulo 6 apresenta as conclusões finais, sugerindo também o desenvolvimento de uma ferramenta para facilitar e agilizar os resultados gerados através da metodologia proposta.

15 CAPÍTULO 2 Métodos de Engenharia Reversa Neste capítulo são apresentados os conceitos e métodos da Engenharia Reversa, justificando a importância e os procedimentos para a realização da reestruturação de um sistema legado para um novo sistema, possibilitando a criação da documentação do sistema que será reestruturado. 2. ENGENHARIA REVERSA 2.1. CONCEITOS DE ENGENHARIA REVERSA Com o aumento da utilização de programas para o gerenciamento de grandes informações, fazendo com que a informática se torne tão necessária, até mesmo para a estabilidade de empresas dos mais diversos portes, vem causando uma demanda de sistemas sem documentações. Devido as constantes modificações e inserções de novas características (funcionalidades) ao sistema, poderão surgir complicações inesperadas, que não estão presentes na documentação. Diante disso, quando é realizada a manutenção do produto, o engenheiro de software depara-se com uma documentação incompleta, diferente da existente. Dessa forma o valor da manutenção de um sistema pode atingir um custo de proporções acima do esperado, tornando-se inviável a realização da mesma. Segundo Schneidewind (1987), citado por Feltrim (1999), Para a realização de uma manutenção de um sistema, é necessário à concretização de três etapas

16 fundamentais: entendimento, modificação e a revalidação do sistema. Sendo que as duas primeiras etapas (entendimento, modificação) estão ligadas diretamente com a disponibilidade das informações contidas no software. Segundo Gall (1994), a Engenharia Reversa é um processo de refazer a documentação de um sistema, com o objetivo de conseguir as informações necessárias para a definição do novo projeto. Segundo Shneiderman (1979), citados por Braga (1998), O coeficiente de abstração de um programa, pode ser variável, devido ao tipo de conhecimento que o analista irá obter, através da análise do sistema em questão. É importante ressaltar que a maneira mais prática de se obter as informações necessárias, seria a leitura do código 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 código do sistema, as documentações disponíveis e as regras de negócio existentes. Com isto será possível criar uma abstração do mesmo, possibilitando a geração das informações necessárias para o processo de Engenharia Reversa. Segundo Abdelwahab e Timothy (2004), manter um sistema com pouca documentação é uma tarefa difícil. As ferramentas de Engenharia Reversa são utilizadas como meio de manutenção, tais como, exploração do código fonte, análise de fluxo de dados, possibilitando, a restauração da arquitetura do projeto. Com isto, é possível gerar uma abstração do sistema legado com alto nível de complexidade, facilitando a compreensão 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

17 programação, 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 nível de abstração mais elevado do que o código fonte. A Engenharia Reversa é um processo de recuperação do projeto, utilizando ferramentas para extrair informações 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 análise de hardware, onde o hábito de explicar os projetos de produtos já desenvolvidos são 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 criação de visões do sistema em vários níveis de abstração, fazendo com que haja facilidade em seu entendimento, e, principalmente, oferecendo apoio à manutenção do sistema. Rugaber (1992), citado por Feltrim (1999), assegura que a maior parte do esforço de desenvolvimento de software é dedicado à manutenção de sistemas já implantados, e não ao desenvolvimento de novos sistemas; o processo concentrase na compreensão do sistema em manutenção. Para isso, é necessário facilitar o processo de compreensão 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 utilização de novas técnicas sem documentação formal, vêm causando uma dificuldade para realizar a manutenção desses softwares, pois na maioria dos casos a documentação não está de acordo com o código implementado.

18 Além disso, efeitos colaterais inesperados que não estão presentes na documentação são gerados devido às constantes modificações 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, manutenção, teste e controle da qualidade do software. Além disso, a Engenharia Reversa está concentrada diretamente na necessidade de conhecer as funcionalidades existentes em softwares antigos (implantados), na produção de novos softwares e de proporcionar uma maior facildade nas realizações de futuras manutenções. Segundo Chikofsky (1990), citado por Braga (1998), a Engenharia Reversa é o processo de análise de um sistema existente cujo objetivo principal é verificar seus componentes e seus inter-relacionamentos, com o intuito de atingir uma representação do sistema de outra forma ou em um nível mais alto de abstração. A Figura 2.1 representa as fases da Engenharia Reversa. A etapa inicial é extrair informações do sistema a partir do código fonte ou até mesmo da interface. Em seguida começa a fase do projeto, ou seja, da modelagem dos dados extraídos. Nesta etapa a utilização de ferramentas CASE é fundamental. Com as informações já modeladas, tem início a fase de organização dos requisitos, que permite um nível mais alto de abstração em relação ao código fonte. A terceira fase é o processo de Reengenharia de Software, cuja função está na recodificação do fonte sobre os requisitos levantados.

19 FIGURA FASES DA ENGENHARIA REVERSA (BASEADO EM CHIKOFSKY,1990, CITADO 2.2. POR BRAGA,1998)

20 MÉTODO FUSION / RE OBJETIVOS Segundo Penteado (1996), para implementar um sistema orientado a objetos a partir de um sistema legado orientado a procedimentos, são dadas duas razões: 1) Para satisfazer a maioria das necessidades dos usuários, os sistemas legados atendem à quase a totalidade de suas necessidades, sendo a melhoria da programação de sua interface essencial no atendimento ou padronização de suas funções. 2) O Fusion / RE, possui como foco principal, viabilizar a migração de um sistema procedimental para um sistema orientado a objetos, cujo objetivo, está na recuperação do projeto de sistemas legados. O processo de Engenharia Reversa não está voltado simplesmente na documentação do sistema. A viabilidade da recuperação do projeto está na utilização do código fonte e das entrevistas com os usuários PROCEDIMENTOS E RESULTADOS A reconstrução do sistema é feita manualmente através das informações existentes no código fonte, utilizando os recursos de pesquisa disponíveis em editores de texto. Assim, faz-se a documentação dos procedimentos pertencentes aos módulos do sistema e da relação CHAMA / CHAMADO POR. O quadro 2.1 apresenta as relações: QUADRO EXEMPLOS DAS RELAÇÕES - FUSION / RE

21 Módulo Módulo X Nome_procedimento_módulo Descrição CHAMA: Nome_procedimento (módulo_a que_pertence). CHAMADO POR: Nome_procedimento (módulo_a que_pertence) Com base nas informações anteriormente expostas, o método está dividido em quatro etapas: 1ª Etapa: A realização de pesquisas no sistema identificando quais documentos estão relacionados ao sistema legado, é o principal objetivo nessa etapa. Não existindo nenhuma documentação, a pesquisa deverá ser realizada através do código fonte, sendo a mesma efetuada sem nenhum recurso computacional. 2ª Etapa: Nesta etapa será criado o modelo de análise do sistema atual (MASA), para a identificação das classes juntamente com seus relacionamentos, atributos e procedimentos. A partir do código fonte este modelo pode ser desenvolvido, visando um melhor conhecimento das funcionalidades do sistema legado, facilitando e proporcionando possíveis sugestões para eventuais alterações. 3ª Etapa: Nesta etapa, será desenvolvido o modelo de análise do sistema (MAS), não relacionado diretamente à implementação e sim ao domínio da aplicação, solucionando problemas relacionados à ambigüidade de informações, nomenclaturas de campos com dificuldade de compreensão e a realização da análise para a redução de classes utilizando os conceitos de Especializações / Generalização, Encapsulamento e outros. 4ª Etapa: Após a definição dos modelos de análise do sistema atual (MASA) e do modelo de análise do sistema novo (MAS), com o objetivo de identificar o que foi incluído ou excluído no sistema legado, deve-se realizar a comparação entre os modelos MASA e MAS. Esta etapa é extremamente importante, já que possui como função principal a documentação das alterações realizadas no sistema legado, possibilitando a realização de futuras manutenções do sistema em questão, como mostra a Figura 2.2

22 Passos Documentação Existente Outros Documentos Relevantes 1.Revitalizar a Arquitetura 1º Passo D Entradas/Saídas Listadas Estrutura do Programa I C I 2.Recuperar o Modelo de Análise do Sistema Atual 2º Passo Temas Modelo de Ciclo de Vida O N Á R Modelo de Objetos Modelo de Operações I O 3.Criar o Modelo de Análise do Sistema 3º Passo Modelo de Objetos Modelo de Ciclo de Vida D E Modelo de Operações D A D O 4.Mapear o Modelo de Análise do Sistema para o Modelo de Análise do Sistema Atual 4º Passo Objetos Atributos/ Elementos de Dados Métodos/ Procedimentos S FIGURA MODELO FUSION / RE (PENTEADO, 1996) 2.3. MÉTODO FUSION RE/I

23 OBJETIVO Segundo Costa (1997), citado por Feltrim (1999), o método Fusion-RE/I forma um método de Engenharia Reversa que visa facilitar todo o processo de recuperação dos dados, partindo da interface do sistema para a recuperação de informações úteis à compreensão do software. Por meio desta metodologia possibilita-se a recuperação das partes funcionais e estruturais do sistema, obtendo-se as considerações lógicas através da análise da interface para a recuperação de partes funcionais do sistema. O Fusion RE/I é baseado na utilização dos modelos das fases de análise, do método de desenvolvimento de software orientado a objetos Fusion. O método Fusion RE/I é derivado de outro método de Engenharia Reversa, o Fusion/RE. Os dois métodos visam recuperar os modelos de análise do método Fusion, mas apresentam diferenças em relação à ordem das etapas a serem cumpridas. O processo do Fusion RE/I inicia-se com a análise da interface do sistema para a recuperação das visões. O quadro 2.2 apresenta a etapa que o método Fusion RE/I utiliza para recuperar as visões Funcionais e Estruturais. QUADRO ETAPAS DO MÉTODO FUSION RE/I (COSTA,1997) Etapa 1. Recuperar visões Funcionais a. Obter informações existentes sobre o sistema b. Recuperar o modelo de análise b.1. Elaboração do modelo de ciclo de vida b.2. Elaboração do modelo de operações b.3. Elaboração do modelo de objetos Etapa 2. Recuperar Visões Estruturais a. Elaboração do quadro de procedimentos de implementação a.1. Elaboração do quadro de chamadas a.2. Elaboração do quadro de índice de procedimentos b. Elaboração do quadro de operações - procedimentos de implementações 2.4. RECUPERAÇÃO DE VISÕES FUNCIONAIS - ETAPA 1 A primeira etapa do método Fusion-RE/I é constituída por duas etapas: obtenção das informações já existentes do sistema e recuperação do modelo de análise. Segue-se a descrição das etapas:

24 1ª Etapa (a): A obtenção de informações sobre o sistema: procuram-se todas as informações existentes no sistema, até mesmo a documentação (manuais, listagem de códigos, etc.) do software e também todo tipo de informação considerada importante (relevante) neste processo, como linguagem de implementação, entre outras (Costa,1997). As documentações deverão ser agrupadas e analisadas, com o intuito de identificar as informações consideradas necessárias para os requisitos do sistema, ao projeto arquitetural e procedimental de dados. A entrevista com o usuário é considerada muito importante, pois as informações cruciais do sistema podem não constar na documentação. 1ª Etapa (b): Recuperar Modelo de Análise do Sistema: nesta etapa são obtidas informações a partir da análise da interface do sistema (Costa,1997). Neste momento é compreendido a execução de modelos da fase de análise do método Fusion, sendo eles: ciclo de vida, operações; objetos. 1ª Etapa (b-1): Elaborar o Modelo de Ciclo de Vida do Sistema: a partir da utilização do sistema, da análise da documentação existente e das entrevistas com os usuários, são definidos a seqüência de operações permitidas e os eventos de entrada e saída aceitos pelo sistema.

25 As opções existentes no menu principal do sistema identificam a expressão principal do modelo de ciclo de vida. As opções ali listadas são construídas novas expressões, uma para cada opção, sinalizando as seqüências de operações permitidas a partir daquele ponto. Para cada operação citada, é escrita uma nova expressão, identificando a seqüência permitida de eventos de entrada (elementos da operação) e os respectivos eventos de saída, que aparecem precedidos pelo símbolo #. 1ª Etapa (b-2): Elaborar o Modelo de Operações do Sistema: nesta etapa o objetivo está em mostrar uma visão geral da funcionalidade das operações realizadas pelo sistema. Para a elaboração do modelo de operações deve-se utilizar constantemente o sistema, para que as operações se tornem amplamente detalhadas. O método Fusion-RE/I considera desde as operações geradas por meio da interface até as opreções e eventos visíveis em tela, como a criação e manipulação de arquivos. A verificação é realizada através de diretórios de trabalho do sistema. 1ª Etapa (b-3): Elaborar o Modelo de Objetos do Sistema: a princípio, definem-se os temas relacionados à funcionalidade do sistema. Para que se possam definir os temas, uma análise das informações recuperadas nos passos nas etapas anteriores é necessária, além das abstrações registradas nos modelos de ciclo de vida e de operações. Esta é uma das tarefas mais subjetivas e de fundamental importância do método Fusion RE/I. Definidos os temas, é realizado um agrupamento das operações de acordo com os temas a que se referem. Ao final tem-se uma lista de temas com suas respectivas operações. Temas são constituídos de outros temas, ao deparar-se com assuntos que se relacionam em um nível de abstração mais alto. Cada tema definido é criado um modelo de objetos. Neste momento as operações são analisadas novamente com

26 o intuito de localizar componentes que constituem o modelo de objetos (classes, relacionamentos, atributos, agregações, especializações e generalizações) Os componentes do modelo de objetos muitas vezes incluem componentes que não estão explícitos nas operações, mas simplesmente identificados pela abstração e entendimento da funcionalidade de cada elemento e operação. A construção do modelo de objetos é função amplamente subjetiva, mesmo não constando no método, e provavelmente requererá um feedback após a recuperação das visões estruturais (visualização do código). A necessidade do feedback é evidente durante a utilização do Fusion-RE/I, uma vez que as mais notáveis referências sobre este método de Engenharia Reversa não emitem diretrizes únicas voltadas à elaboração deste modelo de objetos (Costa,1997) RECUPERAÇÃO DE VISÕES ESTRUTURAIS - ETAPA 2 Nesta etapa o foco está em trabalhar com o código fonte do sistema, cujo o objetivo está em identificar os procedimentos que implementam as operações do sistema descritas nas etapas anteriores. 2ª Etapa (a): Elaborar Quadro de Procedimentos de Implementação: Tem como objetivo identificar os procedimentos, suas funcionalidades e a seqüência de chamadas desses procedimentos. Sendo assim, são 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 código fonte do sistema, indicando os procedimentos armazenados no arquivo, suas respectivas funcionalidades e os procedimentos utilizados (chamados) e utilizadores (chamado por).

27 As funcionalidades podem ser identificadas através de comentários registrados no código fonte. Já os procedimentos (chamados) são definidos pela análise do código e os procedimentos (chamados por) são obtidos através das elaborações dos quadros. Para finalizar, os procedimentos de cada quadro são reorganizados em ordem alfabética. 2ª Etapa (a-2): Elaborar o Quadro Índice de Procedimentos: este quadro irá apresentar os procedimentos da implementação do sistema em ordem alfabética, com as localizações (arquivo e diretório). Na elaboração deste quadro utilizam-se os quadros de chamadas obtidos anteriormente. 2ª Etapa (b): Elaborar Quadro das Operações - Procedimentos de Implementação: Neste momento identificam-se os procedimentos que implementam as operações da interface e, funcionalmente, os procedimentos são acoplados à interface ou a um dos temas definidos anteriormente, sendo identificados os links entre os documentos Quadro de Operações, da primeira etapa do método, com os códigos que os implementam (Costa,1997) MÉTODO RENAISSANCE OBJETIVOS Segundo Battaglia et al. (1998), o método Renaissance foi desenvolvido como um suporte para a reengenharia de software de sistemas legados, criando diferentes visões do projeto do sistema antigo e novo, por meio de modelos da UML (Diagrama de Interação, Diagrama de Casos de Uso, Diagrama de Estados e Diagrama de Componentes). Fornece diretrizes de como transformar uma