Dissert PDF

Apoio Documentao de
Engenharia Reversa de Software

por meio de Hipertextos
Valria Delisandra Feltrim
Orientao:
Prof . Dr . Renata Pontin de Mattos Fortes
a
Dissertao1 apresentada ao Instituto de Cincias Matemticas e de Computao - USP, como

parte dos requisitos para a obteno do ttulo de Mestre em Cincias - rea de Cincias de
Computao e Matemtica Computacional.
USP - So Carlos
Novembro de 1999
Trabalho realizado com o apoio financeiro da FAPESP, #97/12999-8.
Aos meus pais, Feltrim e Lourdes,

pelo amor e apoio incondicionais
Agradecimentos
Profa. Renata Pontin de Mattos Fortes, minha orientadora, pelo apoio e pela
confiana em mim depositada, e acima de tudo, pela sua amizade.
Ao Joo Caldas, por seu amor e apoio constantes.
Ao meu irmo Ricardo, pela confiana e pelo carinho que, de alguma forma, sempre
existiram.
amiga Gisele, por me ensinar a acreditar em mim.
s minhas companheiras de repblica, Luciana, Tatiana e Thelma, por compartilharem

comigo os bons e os maus momentos.
A todos os amigos do ICMC, pela amizade e pelos momentos de descontrao vividos

ao lado de cada um.
Fapesp, pelo apoio financeiro.
A todos que, direta ou indiretamente, contriburam para a concluso deste trabalho.
Sumrio
Lista de Figuras
Lista de Quadros
Resumo
Abstract
1 Introduo.........................................................................................................1
1.1 Contexto ........................................................................................................................ 1
1.2 Motivao ...................................................................................................................... 3
1.3 Objetivos........................................................................................................................ 4
1.4 Organizao do Trabalho ............................................................................................... 4
2 Engenharia Reversa..........................................................................................7
2.1 Conceitos de Engenharia Reversa................................................................................... 8
2.2 O Mtodo Fusion-RE/I................................................................................................. 11
2.2.1 O Mtodo Fusion: Uma Viso Introdutria ...................................................................................... 12
2.2.2 Recuperao de Vises Funcionais .................................................................................................. 14
2.2.3 Recuperao de Vises Estruturais .................................................................................................. 18
2.3 Por que UML? ............................................................................................................. 19

2.4 Representao dos Modelos do Mtodo Fusion-RE/I em UML..................................... 22
2.4.1 Modelo de Anlise do Mtodo Fusion x UML ................................................................................. 23
2.4.2 Vises Estruturais x UML ............................................................................................................... 32
2.5 Consideraes Finais.................................................................................................... 38
3 O Suporte de Sistemas Hipermdia................................................................41

3.1 O Sistema SASHE ....................................................................................................... 43
3.1.1 Modelo de Contextos Aninhados ..................................................................................................... 47
3.2 O mtodo OOHDM ...................................................................................................... 48

3.3 Modelagem hipermdia do domnio de Engenharia Reversa.......................................... 49
3.3.1 Esquema Conceitual........................................................................................................................ 49
3.3.2 Esquema de Classes Navegacionais .................................................................................................52

3.3.3 Esquema Contextual ........................................................................................................................53
3.4 A hiperbase construda no SASHE................................................................................54

3.5 Proposta de adequao do SASHE para Engenharia Reversa ........................................59
3.6 Consideraes Finais.....................................................................................................64
4 Engenharia Reversa aplicada ao Sistema SASHE ........................................65

4.1 Resumo dos resultados da Engenharia Reversa .............................................................66
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
Modelo de Ciclo de Vida .................................................................................................................66

Modelo de Operaes ......................................................................................................................70
Modelo de Objetos...........................................................................................................................71
Quadro de Chamadas.......................................................................................................................76
Quadro ndice de Procedimentos......................................................................................................79
Quadro de Operaes-Procedimentos de Implementao ..................................................................80
4.2 Mtricas do processo de Engenharia Reversa realizado.................................................81

4.3 Problemas encontrados na realizao da Engenharia Reversa........................................83
4.4 Consideraes Finais ..................................................................................................835
5 Avaliao geral do Fusion-RE/I .....................................................................87

5.1 Discusso dos pontos positivos e crticos da aplicao do mtodo Fusion-RE/I.............87
5.2 Validao dos Resultados obtidos com o Fusion-RE/I...................................................96
5.3 Uma proposta de adequao do Fusion-RE/I a sistemas OO..........................................98
5.4 Consideraes Finais ..................................................................................................100
6 Concluso ...................................................................................................... 101

6.1 Contribuies deste Trabalho......................................................................................102
6.2 Sugestes para Futuras Pesquisas................................................................................103
Referncias Bibliogrficas................................................................................ 105
ii
Lista de Figuras
Figura 2.1 - Processo de Engenharia Progressiva x Engenharia Reversa .................................... 9

Figura 2.2 - Viso Geral do Mtodo Fusion-RE/I .................................................................... 11
Figura 2.3 - Viso Geral do Mtodo Fusion (Masiero, 1995) ................................................... 12
Figura 2.4 - Resumo da notao UML para diagrama de classes e objetos ............................... 24
Figura 2.5 - Modelo de Objetos simplificado para o tema Autoria, em Fusion ......................... 25
Figura 2.6 - Modelo de Objetos simplificado para o tema Autoria, em UML............................ 25
Figura 2.7 - Notao do Diagrama de Estado usado pela UML ................................................ 29
Figura 2.8 - Parte inicial do Modelo de Ciclo de Vida do SASHE............................................ 29
Figura 2.9 - Diagrama de estado representando as sentenas iniciais do ciclo de vida .............. 30
Figura 2.10 - Janela para especificao geral da transio de estado na Rational Rose ............. 31
Figura 2.11 - Janela para especificao detalhada da transio de estado na Rational Rose ...... 31
Figura 2.12 - cone utilizado pela Rational Rose para representar o corpo de um subprograma34
Figura 2.13 - Exemplo de diagrama de componente................................................................. 34
Figura 2.14 - Diagrama de componentes para o arquivo ancora.cpp ........................................ 37
Figura 3.1 - Arquitetura geral dos mdulos funcionais de SASHE. .......................................... 44
Figura 3.2 - Controles de navegao disponveis no sistema SASHE ....................................... 46
Figura 3.3 - Esboo da Metodologia OOHDM (Rossi, 1996) ................................................... 48
Figura 3.4 - Modelo Conceitual do PER .................................................................................. 50
Figura 3.5 - Modelo de Classes Navegacionais ........................................................................ 52
Figura 3.6 - Modelo Contextual............................................................................................... 54
Figura 3.7 - Projeto dos contextos aninhados da hiperbase para documentar a engenharia reversa
segundo o Fusion-RE/I......................................................................................... 55
Figura 3.8 - Esquema contextual adaptado aos ns de contextos criados .................................. 56
Figura 3.9 - Parte do ndice principal da hiperbase juntamente com o ndice de operaes....... 57
Figura 3.10 - Item de implementao Avana Histrico........................................................... 58
Figura 3.11 - Janela apresentando a descrio da operao Ativar Janela n........................... 59
Figura 3.12 - Janela do SASHE para a criao de um n terminal............................................ 60
Figura 3.13 - Possvel modificao de interface para a janela de criao de n ........................ 61
Figura 3.14 - Possvel modificao dos controles de navegao............................................... 62
Figura 4.1 - Parte inicial do Modelo de Ciclo de Vida do SASHE............................................ 67
iii
Figura 4.2 - Refinamento da opo Hiperbase e da operao Abrir....................................68

Figura 4.3 - Diagrama de transio de estado para a operao Abrir Hiperbase.....................69
Figura 4.4 - Primeira tentativa de defini7o de Temas para o SASHE ....................................72
Figura 4.5 - Temas propostos para o SASHE ...........................................................................72
Figura 4.6 - Modelo de Objetos para o tema Autoria ................................................................74
Figura 4.7 - Modelo de Objetos para o tema Navegao...........................................................75
Figura 4.8 - Modelo de Objetos recuperado a partir do cdigo fonte do SASHE.......................76
Figura 5.1 - Aplicao do Fusion-RE/I a sistemas procedimentais............................................88
Figura 5.2 - Aplicao do Fusion-RE/I a sistemas orientados a objetos ....................................94
Figura 5.3a - O ambiente SASHE proposto (Nunes et al., 1996) ..............................................96
Figura 5.3b - Arquitetura bsica do Hip (Nunes et al., 1996)....................................................96
Figura 5.4a - Arquitetura recuperada do ambiente SASHE.......................................................97
Figura 5.4b - Arquitetura recuperada do Hip/Windows ............................................................97
iv
Lista de Quadros
Quadro 2.1 - Representao do esquema para descrio das operaes.................................... 14

Quadro 2.2 - Descrio da operao Criar Hiperbase ........................................................... 30
Quadro 2.3 - Modelo de anlise Fusion x UML....................................................................... 32
Quadro 2.4 - Quadro de Chamadas recuperado do arquivo ancora.cpp.................................... 35
Quadro 2.5 - Vises Estruturais Fusion-RE/I x UML............................................................... 38
Quadro 2.6 - Ordem das tarefas prescritas pelo Fusion-RE/I.................................................... 39
Quadro 3.1 - Parte do Modelo Operaes-Procedimentos de Implementao........................... 57
Quadro 4.1 - Esquema descrevendo a operao Abrir do menu Hiperbase ........................ 71
Quadro 4.2 - Quadro de Chamadas recuperado do arquivo elo.cpp .......................................... 78
Quadro 4.3 - Parte do Quadro ndice para os procedimentos C++............................................ 79
Quadro 4.4 - Parte do Quadro de Operaes-Procedimentos de Implementao ...................... 81
Quadro 4.5 - Resumo dos produtos obtidos, em totais ............................................................. 81
Quadro 5.1 - Informaes sobre os estudos de caso realizados com o Fusion-RE/I .................. 90
Quadro 5.2 - Vantagens e desvantagens do Fusion-RE/I aplicado a sistemas OO..................... 91
Quadro 5.3 - Modificaes propostas para o Fusion-RE/I........................................................ 99
Resumo
O crescimento do mercado de software a cada dia acarreta o aumento do uso de
tcnicas de desenvolvimento, muitas vezes informais. A manuteno de tais
softwares torna-se problemtica, uma vez que a documentao associada ao
software, na maioria das vezes, no est de acordo com o cdigo implementado.
Dessa forma, quando diante da manuteno do produto, o engenheiro de software
encontra uma documentao informal e incompleta, que no reflete o software
existente. Nesse contexto que se encontra a Engenharia Reversa de Software, com
o propsito de recuperar as informaes de projeto perdidas durante a fase de
desenvolvimento, e de documentar o real estado do software. O principal objetivo
deste trabalho de mestrado foi a investigao de uma estrutura adequada de
hiperdocumento para apoiar a documentao requerida durante o processo de
engenharia reversa de software. A partir de um levantamento dos requisitos
desejveis em um hiperdocumento, para que possua as habilidades de suporte
documentao de engenharia de reversa de software, um conjunto de links e estrutura
de ns foi definido. Os requisitos, para a composio de tal hiperdocumento, foram
investigados por meio de uma experincia: a autodocumentao do sistema
hipermdia denominado SASHE (Sistema de Autoria e Suporte Hipermdia para
Ensino), que j possui suporte ao tratamento de ns aninhados e outras caractersticas
de aplicativo para ensino. A engenharia reversa foi desenvolvida baseando-se no
mtodo de engenharia reversa Fusion-RE/I, e os produtos obtidos foram inseridos em
uma hiperbase no SASHE.
vi
Abstract
The growth of the software market has leading to an increasing use of development
techniques, which are, sometimes, informal ones. The maintenance of such software
is problematic, since its documentation rarely reflects the implemented code. In this
context Reverse Engineering of Software can help by means of recovering the
project information lost during the development phase and documenting the current
software state. The main objective of this work was the investigation of an
appropriate hypertext structure for supporting the documentation required through
the software reverse engineering process. Starting from the survey of the desired
requirements in a hyperdocument that has the abilities to support reverse engineering
documents, we defined a set of links and nodes structures. The requirements for such
hyperdocument were inquired by an experiment: the system SASHEs selfdocumentation that already treats nested contexts and has other educational
characteristics. The reverse engineering process was developed based on the FusionRE/I method, and the resulting products were inserted in a hyperbase in the system
SASHE.
vii
Captulo 1
Introduo
Este captulo apresenta o contexto no qual este trabalho est inserido, bem como as motivaes
que nos levaram ao seu desenvolvimento. Posteriormente tambm so descritos os objetivos do
trabalho, assim como sua organizao.
1.1 Contexto
A Engenharia de Software tipicamente uma das reas da Cincia de Computao que envolve,
alm de um grande volume de documentos, uma grande diversidade de tipos de documentos
(diagramas, textos, cdigos-fonte, executveis, etc.). Tal caracterstica, aliada ao fato de que tais
documentos contm informaes bastante relacionadas, sugere naturalmente a utilizao de
hiperdocumentos (com ns e links) como meio adequado para o armazenamento e recuperao
dessas informaes (Bigelow, 1988), (Garg; Scacchi, 1989), (Meira; Cabral, 1994).
Dentro da engenharia de software, uma fase reconhecidamente problemtica se refere
manuteno de software, responsvel por custos de propores superiores aos das demais fases
do ciclo de vida de sistemas (Schach, 1994). A atividade de manuteno consiste de trs etapas:
entendimento, modificao e revalidao do sistema (Schneidewind, 1987). Notadamente, as
etapas de entendimento e modificao esto muito relacionadas com a disponibilizao das
informaes do software, ou seja, se apiam na existncia, consistncia, completitude e
atualizao correta dos documentos que o compem. A Engenharia Reversa uma tcnica
1
Captulo 1 - Introduo
utilizada para recuperar informaes a partir dos documentos do software relativos ao produto ou
cdigo-fonte, visando a obteno de sua representao em um nvel mais alto de abstrao.
Dessa forma, visa facilitar o entendimento de sistemas de software.
Por sua vez, a tecnologia de hipermdia, servindo como um meio mais flexvel para tornar
disponvel as informaes aos usurios de aplicativos, est evoluindo rapidamente e
possibilitando que novas formas de apresentao das informaes tambm sejam investigadas.
De fato, a base da tecnologia de sistemas hipermdia a rede de informaes que possui
interconexes que devem estar facilmente acessveis pelos usurios2. Essa rede de informaes,
onde os ns correspondem s unidades de informao e os links s interconexes entre eles,
compe um hiperdocumento.
Neste trabalho de mestrado, o principal interesse foi o tratamento de hiperdocumentos para
dar o suporte necessrio ao processo de engenharia reversa de software. Dessa forma, os estudos
neste trabalho tiveram como alvo a construo de um hiperdocumento que possibilitasse a
fidelidade do contedo da documentao com relao ao produto de software sendo
documentado. Alm disso, tivemos como meta obter a consistncia entre as partes do
hiperdocumento e os componentes do software com mais facilidade por meio dos links definidos.
Por exemplo, o cdigo-fonte de um programa um documento que, se espera, tenha as
respectivas documentaes relacionadas ao seu projeto, anlise, testes e outros, sendo, sempre
que possvel, consistentes e possuindo ligaes de fcil acesso, a fim de refletir corretamente
suas informaes nos diversos nveis de abstrao.
Deve-se ressaltar, ainda, que os links entre os diversos tipos de documentos devem ser
representativos para que os mantenedores de software conheam as repercusses das alteraes
realizadas e, principalmente, de forma que essas alteraes sejam, sempre que possvel, de fcil
recuperao. Mas para uma definio desses links, de forma que eles atendam e auxiliem os
mantenedores de software a entend-lo, necessrio um estudo sistemtico, pois, alm de no se
tratar de uma atividade simples, geralmente, muitos dos links e dos contedos de informao dos
ns so estabelecidos conforme as premissas preconizadas pela metodologia utilizada.
Nesse contexto, este trabalho prope um conjunto de links referentes ao domnio de
informaes relacionadas documentao do processo de engenharia reversa de software. Para
tanto, um ambiente de hipermdia, SASHE (Sistema de Autoria e Suporte Hipermdia para
2
O usurio de sistemas hipermdia pode ser: leitor e autor.
Ensino), foi submetido engenharia reversa, e tal processo foi suportado pela utilizao do
prprio SASHE para registrar o desenvolvimento das etapas envolvidas. Dessa forma, cada
etapa de recuperao dos nveis de abstrao e das relaes entre os componentes de software
implementados no SASHE, corresponde definio de ns e links que o documentam, de forma
hipertextual, no prprio SASHE.
1.2 Motivao
Com o desenvolvimento do ambiente de hipermdia SASHE em um projeto concludo no ICMC,
e a partir dos primeiros experimentos obtidos com a criao de hiperdocumentos para ensino,
pode-se observar que suas caractersticas constituem um recurso potencialmente utilizvel por
outros tipos de aplicao, que no somente as de ensino (Nunes et al., 1997a), (Nunes; Fortes,
1997). Neste sentido, a possvel generalizao para outro domnio de aplicao, o de Engenharia
Reversa de Software, foi nossa principal motivao para o incio deste trabalho, e foi investigada
como contribuio ao projeto anteriormente realizado.
A experincia da utilizao do SASHE para documentar o prprio SASHE, por meio da
elaborao dos documentos referentes ao processo de engenharia reversa a que foi submetido foi,
ento, o exerccio fundamental para o levantamento de requisitos que um engenheiro de software
necessita para utilizar o SASHE como ferramenta de suporte documentao do processo de
engenharia reversa de software.
Outro ponto motivador das pesquisas deste trabalho de mestrado foi o de utilizar o mtodo
Fusion-RE/I (Costa, 1997) desenvolvido tambm no ICMC, que deve-se, principalmente, do fato
de que a experincia prtica conduzida neste projeto se constitui da aplicao da engenharia
reversa a um ambiente de hipermdia, e esta aplicao foi registrada no prprio ambiente
hipermdia. Como a utilizao do Fusion-RE/I inicialmente considera a operacionalidade da
interface usurio-computador do software, foi possvel uma interao representativa para a
prpria autodocumentao realizada.
Alm disso, a escolha do mtodo Fusion-RE/I se orientou pelo fato de que o mesmo leva
produo das vises do sistema, ou seja, auxilia no entendimento e reconhecimento do seu
modelo abstrato, sob o paradigma de Orientao a Objetos (OO). Deve-se ressaltar ainda que,
mesmo com a escolha prvia por se aplicar o mtodo Fusion-RE/I, este projeto o fez com uma
3
particularidade indita, que foi a de, ao final, produzir o modelos do sistema SASHE, na notao
UML (Unified Modeling Language) (Rational, 1997a). A modelagem em UML possibilita uma
abrangncia de forma a no restringir a utilizao de algum mtodo de OO especfico, como
Fusion (Coleman, 1996) ou OMT (Object Modeling Technique) (Rumbaugh et al., 1991).
1.3 Objetivos
O principal objetivo desta pesquisa de mestrado foi elaborar uma proposta de adequao do
sistema SASHE ao domnio da documentao de engenharia reversa de software, de forma que
os links estabelecidos fossem representativos e proporcionassem agilidade para o acesso da
documentao em questo.
Para tanto, a investigao e os estudos necessrios para essa elaborao resultaram da
anlise de um experimento. Tal experimento consistiu da utilizao e aplicao de engenharia
reversa a um sistema hipermdia prottipo existente: SASHE, que foi desenvolvido no ICMC.
Esse ambiente hipermdia SASHE, particularmente, prov um modelo interno de estruturao de
ns do hiperdocumento que auxilia a organizao dos ns: o MCA (Casanova et al., 1991), o
qual tambm foi estudado de forma a fornecer os subsdios para o processo de entendimento do
SASHE.
Alm disso, para que a documentao atenda ao paradigma OO, a engenharia reversa
orientou-se pela aplicao do mtodo Fusion-RE/I. Finalmente, tambm foram obtidos
conhecimentos sobre uma linguagem padro de modelagem OO, a UML, cuja potencialidade de
ser independente da utilizao de qualquer mtodo sob o paradigma de OO, pde ser
comprovada.
1.4 Organizao do Trabalho

Este trabalho est organizado em seis captulos, sendo que neste primeiro foi discutido o
contexto em que este trabalho se encontra, as motivaes para o seu desenvolvimento, e os
objetivos almejados com sua realizao.
O Captulo 2 apresenta os conceitos de Engenharia Reversa de Software, abordando o
mtodo que foi utilizado para a realizao da engenharia reversa no sistema SASHE, o Fusion4
RE/I. Tambm nesse captulo discutido o porqu do uso da UML e uma breve descrio da sua
notao, seguido da proposta para um mapeamento dos modelos gerados pelo mtodo FusionRE/I para a UML, bem como exemplos de como esse mapeamento foi implementado.
No Captulo 3 abordado o suporte oferecido pelos sistemas hipermdia em vrios domnios
de aplicao, destacando-se a Engenharia de Software e a Engenharia Reversa. Em seguida,
descrito o ambiente hipermdia SASHE, ambiente que foi submetido engenharia reversa, de
forma a dar uma idia geral da sua funcionalidade e das informaes que estavam disponveis no
incio do processo de engenharia reversa. Tambm nesse captulo mostrada a hiperbase
construda com a documentao recuperada durante o processo de engenharia reversa, baseada
em uma modelagem do domnio de engenharia reversa realizada, orientada pelo mtodo
OOHDM. Finalmente, nesse captulo apresentada uma proposta de adequao do sistema
SASHE, a fim de tornar o ambiente mais propcio autoria e navegao de documentos de
software.
Os documentos resultantes da aplicao do Fusion-RE/I ao SASHE so apresentados no
Captulo 4. Essa documentao apresentada de forma resumida, devido ao grande volume de
informaes gerado.
No Captulo 5, tambm como resultado da aplicao do Fusion-RE/I, so abordados os
aspectos gerais que foram avaliados sobre o mtodo. Como esse mtodo ainda no havia sido
aplicado a nenhum sistema com as caractersticas do SASHE, foi possvel avaliar uma srie de
fatores, ressaltando vantagens e pontos crticos da aplicao do mtodo. Encerrando esse
captulo proposto um conjunto de mudanas ao mtodo Fusion-RE/I, visando melhorar o
desempenho do mtodo para sua aplicao a sistemas OO.
Finalmente, as concluses deste trabalho, bem como as possibilidades de trabalhos futuros,
so apresentados no Captulo 6.
Captulo 2
Engenharia Reversa
Segundo Saleh e Boujarwah (1996), o mercado de software vem crescendo a cada dia e com ele
o uso de tcnicas de desenvolvimento, muitas vezes informais. Como resultado, a manuteno de
tais softwares torna-se problemtica, uma vez que a documentao associada ao software, na
maioria das vezes, no est de acordo com o cdigo implementado. Alm disso, as constantes
modificaes e adies de novas caractersticas ao software acarreta efeitos colaterais
inesperados, que no esto presentes na documentao.
Dessa forma, quando diante da manuteno do produto, o engenheiro de software encontra
uma documentao informal e incompleta, que no reflete o software existente, tornando
impossvel o gerenciamento do processo de manuteno (Saleh; Boujarwah, 1996). Neste
contexto, a Engenharia Reversa de Software, com o propsito de recuperar as informaes de
projeto perdidas durante a fase de desenvolvimento, e de documentar o real estado do software
pode auxiliar o processo de gerenciamento da manuteno.
Rugaber (1992) afirma que a maior parte do esforo de desenvolvimento de software gasto
na manuteno de sistemas existentes e no no desenvolvimento de sistemas novos, e que grande
parte do processo de manuteno dirigido ao entendimento do sistema em manuteno. Sendo
assim, se queremos melhorar o desenvolvimento de software, e necessrio facilitar o processo de
compreenso de sistemas existentes. A engenharia reversa ataca diretamente o problema de
compreender o software.
Captulo 2 - Engenharia Reversa
Neste trabalho, a engenharia reversa foi empregada com o objetivo de recuperar informaes
de anlise do sistema SASHE, no registradas durante o desenvolvimento do software. A
documentao recuperada poder ento facilitar a manuteno do sistema, uma vez que foi
arquivada na forma de um hiperdocumento no prprio SASHE, e apoiar uma posterior
reengenharia.
Na Seo 2.1 so discutidos alguns conceitos bsicos sobre engenharia reversa, sendo
apresentado em seguida, na Seo 2.2, o mtodo de engenharia reversa Fusion-RE/I, utilizado
como base para o desenvolvimento do processo de engenharia reversa. Na Seo 2.3 so
apresentados os motivos pelos quais optamos por utilizar a notao UML neste trabalho, para a
representao das informaes recuperadas atravs da aplicao do Fusion-RE/I, bem como uma
breve descrio da notao UML. Na Seo 2.4 apresentada a proposta de mapeamento dos
elementos de modelagem Fusion para a notao UML, seguida de exemplos de como o
mapeamento dos documentos recuperados do sistema SASHE para a UML foi realizado.
2.1 Conceitos de Engenharia Reversa

Segundo Chikofsky e Cross II (1990) o termo engenharia reversa teve sua origem na
anlise de hardware, onde a prtica de decifrar o projeto de produtos prontos comum. O mesmo
conceito pode ser aplicado a software, com uma diferena: enquanto a Engenharia Reversa de
Hardware tem por objetivo reproduzir o sistema, a Engenharia Reversa de Software se destina a
criar vises do sistema em diferentes nveis de abstrao, facilitando seu entendimento com o
principal objetivo de ajudar na manuteno do sistema.
Uma definio de abstrao dada como a habilidade de se ignorar os aspectos de assuntos
no relevantes para o propsito em questo, tornando possvel uma concentrao maior nos
assuntos principais (Oxford, 1986).
O ciclo de vida do software expressa bem a diferena entre nveis de abstrao. Vale ainda
ressaltar a existncia de dois conceitos relativos a abstrao: nvel de abstrao e grau de
abstrao.
Diferentes nveis de abstrao ocorrem entre diferentes etapas do desenvolvimento (por
exemplo, as informaes na etapa de projeto so outras alm das informaes da etapa de
anlise), enquanto diferenas no grau de abstrao ocorrem dentro de uma mesma etapa (pode-se
representar as informaes de uma mesma etapa do desenvolvimento de forma geral ou de forma
mais detalhada) (Chikofsky; Cross II, 1990).
Dessa forma, a engenharia reversa pode ser aplicada em qualquer etapa do ciclo de vida, seja
para recuperar nveis de abstrao ou para fornecer uma nova viso em um grau de abstrao
mais alto ( consenso de que quanto mais alto o grau de abstrao, menos detalhes so
fornecidos).
A engenharia reversa segue o sentido oposto ao da engenharia progressiva. A engenharia
progressiva segue a seqncia que vai desde os requisitos, passa pelo projeto at a
implementao. Na engenharia progressiva, o sistema o resultado do processo de
desenvolvimento. Na engenharia reversa, o sistema geralmente o ponto inicial do processo
(Chikofsky; Cross II, 1990). A Figura 2.1, adaptada de Chikofsky e Cross II (1990), representa
esquematicamente, uma forma comparativa das direes inversas por quais se orientam as
etapas envolvidas em cada uma das engenharias. O processo de engenharia reversa caracteriza-se
pelas atividades retroativas do ciclo de vida, que partem de um baixo nvel de abstrao para um
alto nvel de abstrao.
Requisitos
DOWR
Implementao
Projeto
Eng. Progressiva
Eng. Progressiva
Eng. Reversa
Eng. Reversa
1tYHO GH $EVWUDomR
EDL[R
Figura 2.1 - Processo de Engenharia Progressiva x Engenharia Reversa

Existem vrias definies de Engenharia Reversa. A de Pressman (1995) diz que o
processo de anlise num esforo de criar uma representao do programa em um nvel de
abstrao mais alto que o cdigo fonte. Em Costa (1997) encontramos a definio de
Engenharia Reversa como o processo de exame e compreenso do sistema existente, para
recapturar ou recriar os requisitos atualmente implementados pelo sistema, apresentando-os em
um grau ou nvel mais alto de abstrao. No envolve mudanas no sistema ou criao de um
novo sistema. Segundo Chikofsky e Cross II (1990), Engenharia Reversa de Software um
processo de investigao, no um processo de mudana ou reproduo. Rugaber (1992)
identifica o propsito da engenharia reversa como sendo entender um sistema de software com o
9
objetivo de facilitar atividades como: expanso, correo, documentao, re-projeto ou reprogramao em outra linguagem de programao.
Chikofsky e Cross II (1990) tambm identificam duas importantes categorias da Engenharia
Reversa: a redocumentao (visualizao de cdigo) e a recuperao de projeto (entendimento
de programa).
A categoria redocumentao compreende a criao ou reviso de uma representao
semanticamente equivalente dentro de um mesmo nvel de abstrao. Esse processo visa criar
novas vises do sistema atravs da anlise do cdigo fonte, com o objetivo de melhorar a
compreenso do sistema.
A criao dessas vises adicionais do cdigo, geralmente grficas, tem como objetivo recriar
a documentao que j existiu ou que deveria ter existido sobre o sistema (Costa, 1997). No
entanto, as informaes recuperadas com esse tipo de anlise fornecem apenas vises estruturais,
de forma que informaes como a funo e os propsitos do sistema exigem um maior esforo
de entendimento.
A Engenharia Reversa categorizada como recuperao de projeto um subconjunto da
Engenharia Reversa no qual o domnio de conhecimento, informao externa e deduo so
adicionados s observaes sobre o sistema para identificar abstraes de mais alto nvel que
sejam significativas, alm daquelas obtidas diretamente pelo exame do sistema em si
(Biggerstaff, 1989). Esse tipo de processo de entendimento visa recuperar todas as informaes
necessrias para se compreender melhor o que o sistema faz, como ele o faz e porque ele o faz.
Recuperao de projeto a forma mais crtica de Engenharia Reversa porque tenta recuperar
no s a funcionalidade do sistema, mas o processo no qual ele foi desenvolvido (Costa, 1997).
Esse tipo de anlise recupera mais do que vises estruturais, obtendo vises funcionais e at
mesmo de domnio.
Visando a recuperao de projeto, neste trabalho de mestrado, nos apoiamos no mtodo
Fusion-RE/I, que apresentado a seguir (Seo 2.2). O mtodo de Engenharia Reversa FusionRE/I (Fusion Reverse Engineering / Interface) desenvolvido no ICMC-USP (Costa, 1997),
baseia-se nos conceitos e idias da Engenharia Reversa orientada a objetos, e fornece
mecanismos para abstrair vises funcionais (modelos de anlise de sistemas de acordo com o
mtodo Fusion de Coleman e outros (1996)) e vises estruturais partindo, inicialmente, dos
aspectos operacionais e de dados disponveis na interface usurio-computador.
10
2.2 O Mtodo Fusion-RE/I

O Fusion-RE/I constitui-se de um mtodo de Engenharia Reversa que, visando facilitar o
processo, parte da interface do sistema para a recuperao de informaes teis manuteno de
software. Atravs desse mtodo possvel a recuperao de vises funcionais e vises estruturais
do sistema. Dessa forma, parte-se de consideraes lgicas obtidas via anlise da interface para a
recuperao de vises funcionais do sistema e, posteriormente, parte-se dessas vises
recuperadas e de consideraes fsicas obtidas via anlise do cdigo fonte, para a recuperao de
vises estruturais do sistema (Costa, 1997). A Figura 2.2 mostra uma viso geral do mtodo,
representando os elementos requeridos e os obtidos na realizao do processo.
Cdigo Fonte
Interface
Informaes
existentes sobre
o sistema
1 R Etapa
2 R Etapa
Recuperao de
Vises Funcionais
Recuperao de
Vises Estruturais
Modelo de Ciclo de Vida

Modelo de Operaes
Modelo de Objetos
Quadro de Chamadas
Quadro ndice de Procedimentos
Quadro de Operaes - Procedimentos
de Implementao
Figura 2.2 - Viso Geral do Mtodo Fusion-RE/I

Sendo que o mtodo Fusion-RE/I representa toda a informao recuperada da fase de anlise
do sistema atravs dos modelos de anlise do mtodo Fusion (Coleman et al., 1996), na subseo
seguinte feita uma breve introduo sobre o mtodo, sendo descritos os modelos efetivamente
utilizados pelo Fusion-RE/I.
Nas prximas subsees (2.2.2 e 2.2.3) so ento descritas as duas fases que compem o
Fusion-RE/I: Recuperao de Vises Funcionais e Recuperao de Vises Estruturais,
respectivamente. Durante a descrio dessas fases so discutidas as caractersticas do processo,
as quais proporcionam que a estrutura de um hiperdocumento possa ser definida.
11
2.2.1 O Mtodo Fusion : Uma Viso Introdutria

O mtodo Fusion foi criado por Coleman e outros (1996), na tentativa de reunir as melhores
tcnicas propostas pelos mtodos ento existentes. O mtodo compreende trs fases distintas:
anlise, projeto e implementao. A Figura 2.3 apresenta uma viso geral do mtodo e da
interao entre as fases, alm de apresentar os documentos gerados em cada uma delas.
Figura 2.3 - Viso Geral do Mtodo Fusion (Masiero, 1995)

Durante a fase de anlise do mtodo Fusion so gerados dois modelos do sistema: o Modelo
de Objetos, que descreve a estrutura do sistema e o modelo de interface, que descreve o
comportamento do sistema. Por sua vez, o modelo de interface composto de dois modelos que
capturam diferentes aspectos do comportamento: o Modelo de Ciclo de Vida, o qual caracteriza
seqncias permitidas de operaes e eventos do sistema e o Modelo de Operaes, o qual
caracteriza o efeito de cada operao do sistema em termos de mudanas de estado e eventos
gerados (Coleman et al., 1996).
O ponto de partida e fonte de informaes para a fase de anlise um documento de
requisitos informalmente especificado, contendo os requisitos necessrios para o sistema
(Penteado, 1996).
12
A anlise deve iniciar em um alto nvel de abstrao, recomendando-se que os detalhes

sejam inseridos s depois que a estrutura geral for considerada satisfatria. Os objetos, na fase de
anlise, no incluem a definio de mtodos, ou procedimentos inerentes s classes, os quais
sero incorporados na fase de projeto (Masiero, 1995).
O Modelo de Objetos tem como objetivo representar conceitos existentes no domnio do
sistema e o relacionamento entre eles (Masiero, 1995). A notao derivada da notao do
modelo entidade-relacionamento estendido, sendo composta por classes, relacionamentos entre
classes, atributos de classes e de relacionamentos e possveis agregaes, especializaes e
generalizaes (Coleman et al., 1996). A notao bastante semelhante a do Modelo de Objetos
do mtodo OMT (Penteado, 1996).
O Modelo de Ciclo de Vida composto por expresses regulares que definem a seqncia
de eventos a que o sistema pode interagir durante toda a sua vida. Ele descreve o comportamento
completo de como o sistema se comunica com o ambiente, desde sua criao at o seu trmino
(Masiero, 1995), (Penteado, 1996).
As expresses do ciclo de vida so simples extenses de expresses regulares ou gramaticais
(Costa, 1997). As expresses regulares definem a seqncia de eventos aceita pelo sistema do
mesmo modo que nas gramticas elas definem as seqncias de smbolos da linguagem que
podem ser aceitas pelo compilador (Coleman et al., 1996).
O Modelo de Ciclo de Vida possui a seguinte sintaxe geral (Masiero, 1995):
life cycle [Nome:] Expresso-Regular
(nome-local = Expresso-Regular)*
onde Nome especifica o nome do sistema, e uma vez que a expresso regular seja composta por
nome-local, so fornecidas na seqncia as expresses de sua formao.
O Modelo de Operaes decorrente do Modelo de Ciclo de Vida. Este modelo especifica o
comportamento de uma operao de forma declarativa em termos das mudanas de estado do
sistema e eventual gerao de eventos de sada (Masiero, 1995).
Cada operao identificada no Modelo de Ciclo de Vida descrita individualmente atravs
de um formulrio textual contendo as seguintes informaes: nome da operao, descrio
informal, dados de entrada, objetos acessados3 e modificados, eventos de sada e os agentes que
3
Embora o termo acessar no seja uma palavra encontrada nos dicionrios da Lngua Portuguesa, amplamente
utilizado pela comunidade da rea de Cincia da Computao.
13
os recebem, pr-condies e resultados da operao, descritos como ps-condies (Penteado,

1996), seguindo o esquema mostrado na Quadro 2.1. Dessa forma, o Modelo de Operaes ser
expresso por uma srie de esquemas, sendo que existir, no mnimo, um esquema para cada
operao do sistema (Coleman et al., 1996).
Nesse modelo tambm so indicados quais valores so parmetros da operao, atravs da
palavra supplied antecedendo os itens acessados (valores lidos pela operao). A criao de
novos objetos indicada atravs da palavra new antecedendo o nome do objeto.
Finalizando a etapa de anlise feita uma verificao de consistncia e completitude do
modelo. Um modelo dito consistente quando no existem contradies, implcita ou
explicitamente, entre as partes do modelo. Um modelo dito completo se todas as abstraes
significativas do domnio tiverem sido captadas e se o modelo de anlise for condizente com as
expectativas do usurio descritas no documento de requisitos (Penteado, 1996).
Quadro 2.1 - Representao do esquema para descrio das operaes
Operao:
nome
Descrio:
texto
L:
itens
Modifica:
itens
Envia:
agentes e eventos
Assume:
condio
Resultado:
estado
Como o mtodo Fusion-RE/I utiliza apenas os modelos de anlise do mtodo Fusion, neste
trabalho no abordaremos as fases de projeto e implementao que complementam o mtodo.
Assim, nas prximas subsees retomamos a descrio do mtodo Fusion-RE/I.
2.2.2 Recuperao de Vises Funcionais

Visando obter a abstrao da funcionalidade do sistema, nesta primeira fase do mtodo FusionRE/I, so realizadas duas tarefas: a obteno de informaes existentes sobre o sistema e a
recuperao do modelo de anlise do sistema, as quais so descritas a seguir.
a. Obter Informaes Existentes Sobre o Sistema
Nesta tarefa busca-se toda a informao disponvel sobre o sistema em estudo. Isso envolve
reunir a documentao existente (manuais, listagens de cdigo, etc.) sobre o sistema e tambm
14
obter outras informaes relevantes, como o domnio do sistema, linguagem de implementao,

etc. Entrevistas com os usurios tambm podem ser teis j que, muitas vezes, informaes
importantes podem no estar documentadas.
De fato, j existe um trabalho de mestrado sendo desenvolvido (Jubileu; Sanches, 1999) com
o objetivo de sistematizar a coleta de informaes, visando tornar essa tarefa mais eficiente.
Tendo reunida toda a documentao existente, esta deve ser analisada para identificao de
informaes relacionadas aos requisitos do sistema, ao projeto arquitetural, de dados e
procedimental, ao ambiente onde o sistema executado, a organizao dos arquivos em disco,
etc. (Costa, 1997).
b. Recuperar Modelo de Anlise do Sistema
Tendo recuperado todas as informaes existentes sobre o sistema, parte-se para a tarefa
seguinte, de recuperao das informaes da fase de anlise. Todas as informaes recuperadas
nesse passo so obtidas por meio da investigao sobre a interface do sistema. O mtodo FusionRE/I utiliza os modelos da fase de anlise do mtodo de desenvolvimento de software orientado
a objetos Fusion para representar as informaes recuperadas.
No entanto, por entendermos ser til a representao dessas informaes de forma
independente de um mtodo de desenvolvimento de software, optamos pela investigao da
utilizao da notao UML. Sendo assim, como um dos objetivos deste trabalho de mestrado,
faremos um estudo que relacione a representao do modelo de anlise Fusion UML. Na Seo
2.4, apresentado um estudo inicial sobre uma proposta de mapeamento dos elementos de
modelagem Fusion para a UML.
A tarefa de recuperao do modelo de anlise do sistema, segundo Costa (1997),
compreende a elaborao dos trs modelos da fase de anlise do mtodo Fusion: o Modelo de
Ciclo de Vida, o Modelo de Operaes e o Modelo de Objetos. Embora se trate de uma tarefa
ligada manipulao do sistema, por meio da sua interface, de forma bastante intensiva, sendo
dessa forma uma tarefa concreta, exigido um grande esforo de ateno e concentrao por
parte do engenheiro de software (ou mantenedor), ao investigar quase que exaustivamente todos
os estados da interface do sistema. A seguir, so brevemente descritos os procedimentos para a
elaborao dos modelos da fase da anlise.
15
b.1. Elaborar o Modelo de Ciclo de Vida do Sistema

A partir do uso do sistema, do estudo da documentao existente e das entrevistas com os
usurios pode-se definir a seqncia de operaes permitidas e os eventos de entrada e de sada
que o sistema aceita.
As opes presentes no menu da interface do sistema formaro a expresso principal do
Modelo de Ciclo de Vida. A partir das opes listadas na expresso principal, so construdas
novas expresses, uma para cada opo, mostrando 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, os quais aparecem precedidos pelo smbolo # (Costa, 1997).
b.2. Elaborar o Modelo de Operaes do Sistema
Para a elaborao do Modelo de Operaes, no mtodo Fusion-RE/I, parte-se do Modelo de
Ciclo de Vida obtido anteriormente. Esse Modelo de Ciclo de Vida apresenta uma viso geral da
funcionalidade das operaes do sistema, as quais, para a elaborao do Modelo de Operaes
devem ser melhor estudadas, atravs do uso intensivo do sistema, de modo que possam ser
especificadas detalhadamente (Costa, 1997).
Dessa forma, descreve-se a execuo de cada operao identificada no Modelo de Ciclo de
Vida. O mtodo Fusion-RE/I considera no apenas as operaes e eventos gerados atravs da
interface, mas tambm operaes e eventos no visveis em tela, como criao e manipulao de
arquivos pelas operaes do sistema. Isso se d atravs da observao do diretrio de trabalho
do sistema, aps a execuo de cada operao da interface, verificando a modificao ou a
criao de novos arquivos.
Uma vez compreendida a operao, pode ser preenchido o formulrio de descrio da
mesma. Deste formulrio constam os seguintes itens: nome, descrio, l, modifica,
envia, assume e resultado.
A descrio da operao pode ser obtida atravs do manual do usurio. As informaes
do item l so obtidas a partir da observao da interface, identificando-se o valor referente a
cada elemento acessado pela operao (eventos de entrada). Atravs da observao da interface e
da execuo da operao obtm-se as informaes do item modifica, identificando-se o valor
referente a cada elemento acessado e modificado pela operao. As informaes do item envia
16
so obtidas atravs da observao da interface, identificando os eventos de sada gerados pela

operao. As informaes do item assume especificam as pr-condies necessrias para a
execuo da operao e tambm so obtidas pela observao da interface. As informaes do
item resultado podem ser preenchidas identificando-se, atravs da execuo da operao, o
relacionamento entre o estado inicial do sistema (antes da operao) e o estado final do sistema
(aps o trmino da operao) (Costa, 1997).
b.3. Elaborar o Modelo de Objetos do Sistema
Para a elaborao desse modelo no Fusion-RE/I primeiramente definem-se os assuntos
relacionados com a funcionalidade do sistema. Esses assuntos so denominados Temas (Costa,
1997).
Para que se possa definir os temas necessria uma anlise das informaes recuperadas na
primeira fase e tambm das abstraes observadas nos modelos de Ciclo de Vida e de
Operaes. Essa uma das tarefas mais subjetivas do mtodo Fusion-RE/I e de fundamental
importncia para a aplicao do mtodo (Costa, 1997).
Tendo definido os temas, feito um agrupamento das operaes de acordo com os temas a
que se referem. Assim, ao final tem-se uma lista de temas e as operaes dos temas. Temas
podem ser constitudos de outros temas, quando os assuntos se relacionam em um nvel de
abstrao mais alto.
Para cada um dos temas definidos, construdo um Modelo de Objetos. Para isso, as
operaes so novamente analisadas, agora buscando identificar componentes que constituem o
Modelo de Objetos, ou seja, classes, relacionamentos, atributos, e possveis agregaes,
especializaes e generalizaes.
Os componentes do Modelo de Objetos podem incluir componentes que no esto explcitos
nas operaes, mas que so identificados pela abstrao e entendimento da funcionalidade de
cada elemento e de cada operao (Costa, 1997).
A construo do Modelo de Objetos uma tarefa bastante subjetiva, e embora no conste no
mtodo, provavelmente v requerer um feedback aps a recuperao das vises estruturais
(visualizao do cdigo). Prevemos essa necessidade, uma vez que as principais referncias
sobre esse mtodo de Engenharia Reversa no emitem uma diretriz nica para a elaborao desse
Modelo de Objetos. Em Costa (1997), onde o mtodo Fusion-RE/I descrito, no h uma
17
definio clara de que o Modelo de Objetos possa ser construdo atravs da observao da
interface somente. Em Penteado (1996), onde descrito o mtodo Fusion-RE, do qual se origina
o Fusion-RE/I, o Modelo de Objetos recuperado atravs da investigao do cdigo fonte, mas
tambm no so claramente definidas as diretrizes para essa tarefa, ficando a cargo do
engenheiro de software um processo quase que de tentativa e erro para identificar os possveis
objetos do sistema.
2.2.3 Recuperao de Vises Estruturais

Nesta fase trabalha-se com o cdigo fonte do sistema, tendo como objetivo identificar os
procedimentos que implementam as operaes do sistema discriminadas na etapa anterior.
A seguir, so descritos os procedimentos de elaborao que devem ser realizados nesta fase.
a. Elaborar Quadro de Procedimentos de Implementao
Neste passo tem-se como objetivo identificar cada procedimento, sua funcionalidade e a
seqncia de chamadas desse procedimento. Para tal, so utilizados dois quadros: um Quadro de
Chamadas para cada arquivo de programa do sistema e um ndice geral de procedimentos.
a.1. Elaborar o Quadro de Chamadas
O quadro de chamadas deve ser elaborado para cada arquivo de cdigo fonte do sistema,
apresentando os procedimentos contidos no arquivo, suas respectivas funcionalidades e os
procedimentos utilizados (chamados) e utilizadores (chamados por) (Costa, 1997).
As informaes de descrio (funcionalidade) dos procedimentos podem ser conseguidas a
partir de comentrios no cdigo fonte. Os procedimentos chamados por outro procedimento so
obtidos pela anlise do prprio cdigo, enquanto que os procedimentos utilizadores (Chamado
por) vo sendo obtidos a medida que os quadros so elaborados.
Finalizando, os procedimentos de cada quadro so re-arranjados em ordem alfabtica.
a.2. Elaborar o Quadro ndice de Procedimentos
O ndice de Procedimentos apresenta todos os procedimentos da implementao do sistema em
ordem alfabtica, com as respectivas localizaes (arquivo e diretrio).
18
Para a elaborao desse quadro utiliza-se todos os quadros de chamadas obtidos

anteriormente.
b. Elaborar Quadro das Operaes - Procedimentos de Implementao
Nesse passo identifica-se os procedimentos que implementam as operaes da interface e, de
acordo com sua funcionalidade, os procedimentos so classificados como os que implementam
os mecanismos da interface ou como implementando operaes de um dos temas definidos
anteriormente.
Nas primeiras colunas do quadro so colocadas as opes do menu e as operaes de cada
opo (descrio da interface). Na prxima coluna so colocados os procedimentos que
implementam cada operao, de acordo com a hierarquia de chamadas descrita no Quadro de
Chamadas.
O nvel de profundidade que os procedimentos so detalhados nesse quadro depende do
interesse em questo (Costa, 1997).
As prximas colunas do quadro so utilizadas para alocar os procedimentos interface ou a
um dos temas definidos. Assim, tem-se uma coluna para interface e uma para cada tema
definido.
2.3 Por que UML?

O desenvolvimento da UML - Unified Modeling Language - teve incio em 1994 com o objetivo
de incorporar as melhores prticas da indstria de software em uma notao padro para a
especificao de sistemas orientados a objetos. Propositadamente, no especificado um padro
de processo, baseado no fato de que cada organizao e cada projeto adotam diferentes tipos de
processos (Rational, 1997a). Desta forma, o processo pode ser ajustado de acordo com as
necessidades do projeto e do desenvolvedor.
Os mtodos de desenvolvimento de software esto evoluindo de forma que convergem em
muitos pontos (Rational, 1997a). O objetivo da UML remover as diferenas desnecessrias
entre as notaes e terminologias, permitindo que as similaridades entre os mtodos se tornem
19
mais claras. Essa padronizao permitir aos desenvolvedores uma melhor comunicao,
independente do mtodo utilizado e permitir um melhor aproveitamento de ferramentas CASE.
Como esperado que o prprio mtodo Fusion, em sua nova verso, adote a notao UML,
por ser um projeto apoiado por grandes empresas de software (Coleman et al., 1997), e por todos
os motivos acima citados que optamos por nos antecipar e representar as informaes
recuperadas atravs do Fusion-RE/I em UML. Desta forma, a familiarizao e uma melhor
compreenso da nova notao ocorrem no s atravs de estudos, mas de uma aplicao prtica.
A seguir, so apresentados os principais aspectos da notao UML, de forma resumida, com
o objetivo de fundamentar o uso da mesma para a investigao da correspondncia aos modelos
requeridos pelo Fusion-RE/I.
A notao UML est visualmente representada no documento UML Notation Guide
(Rational, 1997b). Este documento apresenta uma explanao dos elementos notacionais e um
breve resumo da semntica desses elementos.
A UML prope nove diagramas e um conjunto de elementos que podem ser utilizados em
quaisquer desses diagramas, chamados de elementos de notao genrica. Entre esses elementos
encontram-se notas, packages, restries, rtulos, strings, esteretipos, nomes, ou seja,
elementos independentes da natureza do diagrama.
Os diagramas encontram-se agrupados em diagramas de estrutura esttica, diagramas
comportamentais (caso de uso, de seqncia, de colaborao, de estado e de atividade) e
diagramas de implementao, e so brevemente descritos abaixo.
a) Diagramas de Estrutura Esttica
Dois diagramas compem os diagramas de estrutura esttica: os diagramas de classes e os
diagramas de objetos.
Um diagrama de classe uma coleo de elementos estticos, tais como classes, tipos e seus
relacionamentos, conectados uns aos outros e aos seus contedos.
Um diagrama de objetos uma instncia de um diagrama de classes. Ele mostra o estado
detalhado do sistema em um ponto no tempo.
20
b) Diagramas de Caso de Uso

Um modelo de caso de uso descreve os requisitos funcionais de um sistema em termos de casos
de uso. Um diagrama de caso de uso mostra as relaes entre atores e casos de uso dentro do
sistema.
Um caso de uso um conjunto de seqncias de aes que um sistema realiza que produz
um resultado de valor observvel por um ator particular.
c) Diagramas de Seqncia
Um diagrama de seqncia mostra uma interao arranjada em uma seqncia de tempo. Em
particular, ele mostra os objetos participando da interao pelas suas linhas da vida e as
mensagens que eles trocam, arranjadas em uma seqncia de tempo. Esse diagrama no mostra a
associao entre objetos.
Diagramas de colaborao e de seqncia expressam informaes similares mas o fazem de
formas diferentes. Os diagramas de seqncia mostram a seqncia explcita de mensagens e so
melhores para especificaes em tempo real e para cenrios complexos. Diagramas de
colaborao mostram os relacionamentos entre os objetos e so melhores para entender todos os
efeitos sobre um dado objeto e para serem utilizados no projeto arquitetural.
d) Diagramas de Colaborao
Um diagrama de colaborao mostra uma interao organizada em torno dos objetos na interao
e os links de uns para os outros. Um diagrama de colaborao mostra os relacionamentos entre os
objetos, porm no mostra o tempo como uma dimenso separada.
Um diagrama de colaborao um contexto, isto , um grafo de objetos e ligaes, com
fluxos de mensagens conectados s ligaes. O contexto do diagrama mostra os objetos
relevantes para o desempenho de uma operao.
e) Diagramas de Estado
Um diagrama de estado representa a seqncia de estados que um objeto ou uma interao passa
durante sua vida, em resposta a um estmulo recebido, junto com suas respostas e aes.
Todo diagrama de estado conectado a uma classe ou a um mtodo (implementao de
operaes). A sintaxe e semntica dos diagramas de estado esto descritas posteriormente.
21
f) Diagramas de Atividade
Um diagrama de atividade um caso especial de diagrama de estado no qual todos (ou pelo
menos a maioria) os estados so estados de ao e no qual todas as transies (ou pelo menos a
maioria) so disparadas pela finalizao das aes nos estados origem.
Todo diagrama de atividade conectado a uma classe, implementao de uma operao ou
a um caso de uso. O propsito desse diagrama focalizar o fluxo direcionado pelo
processamento interno.
g) Diagramas de Implementao
Esses diagramas mostram aspectos de implementao, incluindo estrutura do cdigo fonte e a
estrutura da implementao em tempo de execuo. Existem dois tipos de diagramas de
implementao: diagramas de componentes e diagramas de disponibilidade.
Os diagramas de componentes apresentam a estrutura do cdigo em si, mostrando as
dependncias entre os componentes de software. Isso apresentado atravs de um grafo de
componentes conectado por relacionamentos de dependncia.
Os diagramas de disponibilidade mostram a configurao de elementos processando em
tempo de execuo e os componentes de software, processos, e objetos que vivem sobre eles, ou
seja, mostram a estrutura do sistema em tempo de execuo.
Um diagrama de disponibilidade representado por um grafo de ns conectados por
associaes de comunicao. Um n um tipo de objeto fsico de execuo que representa um
recurso computacional, geralmente tendo no mnimo memria e capacidade de processamento.
2.4 Representao dos Modelos do Mtodo FusionRE/I em UML

Tendo por base os estudos realizados sobre o mtodo Fusion-RE/I, o mtodo Fusion e a notao
UML, nesta seo apresentado o conjunto de elementos de modelagem e diagramas UML
utilizados para que representem, adequadamente, os modelos construdos durante a aplicao do
Fusion-RE/I.
22
2.4.1 Modelo de Anlise do Mtodo Fusion x UML

Como o modelo de anlise do Fusion composto do Modelo de Objetos, do Modelo de
Operaes e do Modelo de Ciclo de Vida, tais modelos so brevemente discutidos a seguir, com
o objetivo de apresentar as respectivas notaes em UML.
Modelo de Objetos
A correspondncia do Modelo de Objetos Fusion para a notao UML pde ser feita
diretamente, pois a UML modela os mesmos elementos existentes no Modelo de Objetos Fusion.
Alm disso, tanto o Modelo de Objetos Fusion como o Modelo de Objetos UML adotam a
representao na forma de diagramas, e as diferenas encontram-se apenas na representao
grfica dos elementos de cada diagrama.
Pode-se observar que a UML, por sua vez, mais abrangente que a notao proposta no
Fusion, isto , oferece mais recursos para a modelagem de objetos. Alm dos elementos de
modelagem definidos pelo Fusion, ela permite a incluso da definio dos mtodos pertencentes
s classes como no Fusion, e tambm possibilita a diferenciao entre agregao fraca e
agregao forte (composio), a dependncia entre classes e a definio de interface entre as
classes.
Notao para Diagrama de Objetos em UML

Na Figura 2.4 exemplificada a notao usada pela UML para diagramas de classes e objetos.
Os exemplos utilizados foram adaptados dos documentos da Rational (1997b).
Semanticamente, para a UML, um diagrama de classe uma coleo de elementos estticos,
tais como classes, tipos, e seus relacionamentos, conectados uns aos outros e aos seus contedos
como um grafo (Rational, 1997c).
Um diagrama de objetos um grafo de instncias. Um diagrama de objetos esttico uma
instncia de um diagrama de classe. Ele mostra o estado detalhado do sistema em um ponto no
tempo (Rational, 1997b).
23
Classe 1
Classe 1
Classe 2
Classe 2
Classe 3
Classe 1
Atributo 1: tipo
Classe de
associao
Classe de
associao
atributo
atributo
Operao 1( )
(c) Associao ternria que uma

classe de associao
(b) Associao que tambm uma

classe de associao
(a) Classe
Classe 1
...
Classe 3
Classe n
Classe 1
Classe
Classe
Classe
Classe
(e) Vrias formas de mostrar composio

Classe 1
Classe 2
Classe 3
...
Classe 2
Classe n
Classe 3
Classe n
...
(f) Diferentes formas de mostrar generalizao

Classe 1
<<friend>>
Classe 2
Classe 4
Operao( )
<<call>>
Classe 3
(g) Dependncias entre classes
Classe 1
...
Operao( )
Classe 2
(h) Interface entre classes
Figura 2.4 - Resumo da notao UML para diagrama de classes e objetos

Uma classe um descritor para um conjunto de objetos com estrutura, comportamento e
relacionamentos similares.
Conforme mostrado na Figura 2.4, uma classe representada por um retngulo com trs
compartimentos separados horizontalmente por linhas. O primeiro compartimento contm o
nome e outras propriedades da classe. O compartimento seguinte contm a lista de atributos e o
ltimo compartimento contm a lista de mtodos (Rational, 1997b).
A notao para objetos igual a notao usada para classes, uma vez que um objeto uma
instncia de uma classe. Para diferenciar ambos, a UML usa um sublinhado. Desta forma, nomes
de objetos aparecem sublinhados enquanto nome de classes no.
24
Na Figura 2.5 mostrado o Modelo de Objetos simplificado do sistema SASHE, recuperado

durante o processo de engenharia reversa, utilizando-se a notao indicada pelo mtodo FusionRE/I, a do mtodo de desenvolvimento Fusion (Coleman et al., 1996). A Figura 2.6 apresenta o
mesmo Modelo de Objetos, porm utilizando a notao UML para sua representao.
Comparando-se esse exemplo possvel observar a correspondncia entre as duas notaes.
Figura 2.5 - Modelo de Objetos simplificado para o tema Autoria, em Fusion
Professor
interage
Hiperbase
manipula
Interface de Autoria
N
Elo
Browser
N Contexto
Browser Grfico
N Terminal
Browser Estrutural
Roteiro
T exto
Imagem
Vdeo
udio
Execuo
Figura 2.6 - Modelo de Objetos simplificado para o tema Autoria, em UML
25
Modelo de Interface
A interface de um sistema o conjunto de operaes permitidas e o conjunto de eventos de sada
desse sistema. O modelo de interface descreve o comportamento do sistema em termos de
eventos e das mudanas de estado que eles causam (Coleman et al., 1996).
O modelo de interface do mtodo Fusion usa dois modelos para a obteno de diferentes
aspectos do comportamento: Modelo de Ciclo de Vida e Modelo de Operaes.
O Modelo de Ciclo de Vida caracteriza a seqncia permitida de operaes do sistema
declarativamente, em termos de mudanas de estado. O Modelo de Operaes especifica os
efeitos de cada operao do sistema de forma declarativa, em termos das mudanas de estado
que eles causam e dos eventos de sada que envia (Coleman et al., 1996).
Por essas definies, o que nos pareceu mais adequado foi a representao desses modelos
por meio de diagramas de estados4, que como j mencionado na Seo 2.2, caracterizam uma
seqncia de estados possveis para um determinado objeto, mapeando tambm suas aes e
sadas.
Um diagrama de estados descreve de forma grfica uma mquina de estados finitos. Por sua
vez, uma mquina de estados finitos descreve o comportamento que especifica as seqncias de
estados que um objeto ou uma interao assume durante sua vida em resposta a eventos, junto
com suas respostas e aes (Rational, 1997b).
Parte dos modelos do mtodo Fusion so descritos utilizando-se recursos grficos
(diagramas), e outra parte utiliza representaes textuais, como expresses regulares e quadros
declarativos. A UML no assume que toda a informao em um modelo deva ser expressa como
um diagrama (Rational, 1997b). No entanto, toda a notao UML possui o suporte de diagramas,
semanticamente definidos por meio de um metamodelo.
A representao tabular das informaes deixada para as ferramentas. A UML no faz esse
tratamento porque toda a informao bsica adequadamente representada no metamodelo UML
(Rational, 1997b).
Sendo objetivo deste trabalho representar as informaes recuperadas de um sistema e
recuperar essas informaes por meio da aplicao do mtodo de Engenharia Reversa Fusion4
Diagramas de Estados ou Diagramas de Transio de Estados (DTEs) so termos utilizados indistintamente nesta
dissertao.
26
RE/I, em UML, um estudo sobre a melhor adequao dos documentos requeridos pelo mtodo
foi realizado. Como no encontramos na notao UML diagramas diretamente correspondentes
ao modelo de interface Fusion, optamos pela representao desse modelo atravs de diagramas
de transio de estados, uma vez que os conceitos de tais diagramas parecem ir de encontro aos
objetivos dos modelos de ciclo de vida e de operaes, que compem o modelo de interface.
De fato, o Modelo de Ciclo de Vida descreve o comportamento do sistema sob a perspectiva
de como ele se comunica com o ambiente desde sua criao at o seu fim. Essa descrio se d
atravs de um conjunto de expresses regulares que definem as seqncias de operaes
permitidas. Essas expresses so decompostas at o nvel de operaes no decomponveis
(Coleman et al., 1996).
A grosso modo, podemos dizer que um Modelo de Ciclo de Vida pode ser visto como uma
linguagem, j que composto por seqncias de expresses regulares. Dessa forma, o Modelo de
Ciclo de Vida pde ser adequadamente representado por um diagrama de estados.
O Modelo de Operaes define o
comportamento
das operaes do sistema
declarativamente, de forma textual. Isto feito atravs de quadros que especificam as operaes
atravs dos seguintes itens:
nome da operao;
descrio informal da operao;
valores a que a operao pode ter acesso (apenas leitura);
valores que a operao pode modificar;
lista de eventos que pode ser enviada a agentes (entidades ativas que interagem com o
sistema) pela operao;
pr-condies; e
ps-condies, relacionando o estado do sistema antes da operao e o estado posterior a

efetivao da operao.
Uma vez que o Modelo de Ciclo de Vida pde ser mapeado em diagrama de estados, j
temos no prprio diagrama todas as operaes realizadas pelo sistema que deveriam ser descritas
no Modelo de Operaes. Atravs dos recursos notacionais disponveis ao diagrama de estados,
as informaes representadas no Modelo de Operaes puderam ser incorporadas ao diagrama.
Vale ressaltar que os diagramas de transio de estados esto semntica e notacionalmente
descritos nos documentos referentes a UML (Rational, 1997b), (Rational, 1997c), de forma que,
27
por meio de seu uso de forma completa, o modelo de interface do mtodo Fusion pode ser
representado satisfatoriamente.
A maioria dos mtodos de modelagem OO utilizam notao grfica e formalismos baseados
em estados para descrever o comportamento de sistemas. No entanto, na maioria dos casos, falta
uma definio rigorosa da semntica da linguagem utilizada para a descrio comportamental, e
sem essa semntica rigorosa, os mtodos de modelagem no conseguem ser precisos o suficiente
(Harel; Gery, 1997).
Sendo o diagrama de estados um elemento de modelagem poderoso sob o aspecto da
modelagem de seqncias de eventos e de estados de um objeto, e sendo semanticamente bem
definido, era esperado que a representao do aspecto comportamental do sistema atravs de tais
diagramas revelasse aspectos sobre o sistema em anlise, que no so to claramente
evidenciadas nos modelos propostos pelo mtodo Fusion-RE/I. De fato, os diagramas de
transio de estado possibilitaram uma melhor visualizao da seqncia de operaes
representada no Modelo de Ciclo de Vida, permitindo que fossem feitas as devidas correes no
modelo, para que mesmo ficasse consistente com a interface do SASHE.
A seguir mostrado um resumo da notao UML para diagramas de transio de estado,
juntamente com um exemplo de como as sentenas do Modelo de Ciclo de Vida foram
representadas em DTEs (Figura 2.9).
Notao para Diagrama de Estados em UML

Um diagrama de estados representa a seqncia de estados pela qual um objeto ou uma
interao passa durante sua vida, em resposta a um estmulo recebido, junto com suas respostas e
as aes.
Embora os Statecharts sejam uma extenso dos diagramas de transio de estados, por
possurem caractersticas notacionais adicionais, a semntica e a notao, adotadas
irrestritamente na notao UML para representar os diagramas de estados, so substancialmente
as mesmas dos statecharts de Harel (1987).
Um diagrama de estado um grafo bipartido de estados e transies. Todo o diagrama de
estado conectado (atravs do modelo) a uma classe ou a um mtodo (uma implementao de
operao), conforme definio encontrada em Rational (1997b). Esse conceito implementado
na ferramenta de apoio a modelagem em UML, a Rational Rose (Rational, 1999).
28
Transio para o
prprio estado
Smbolo
terminal
Smbolo
inicial
Nome do evento
Nome do estado
Transio de estado
Transio de estado
Figura 2.7 - Notao do Diagrama de Estado usado pela UML

Os diagramas de transio de estados so de grande importncia no contexto deste trabalho,
uma vez que tipicamente so destinados a descrever o comportamento de sistemas em geral. A
Figura 2.7 mostra a notao bsica utilizada pela UML para diagramas de estados (Rational,
1997b).
O Modelo de Ciclo de Vida e Modelo de Operaes, diagramas da notao do mtodo
Fusion, foram representados atravs de um diagrama de estados da notao UML. A Figura 2.8
mostra as sentenas iniciais do Modelo de Ciclo de Vida do sistema SASHE, e que esto
representadas no DTE apresentado na Figura 2.9. Todos os DTEs foram construdos com o
auxlio da ferramenta Rational Rose (1999).
life cycle SASHE = ( PROFESSOR | ESTUDANTE | Sada )

PROFESSOR = ( HIPERBASE | JANELAS | AJUDA | b_Criar_hiperbase |
b_ABRIR_HIPERBASE | b_SALVAR_HIPERBASE | b_ROTEIRO |
b_GLOSSRIO | ELOS | NS )+
...
Figura 2.8 - Parte inicial do Modelo de Ciclo de Vida do SASHE

A primeira sentena presente na Figura 2.8 representa o menu inicial do SASHE, onde o
usurio tem como opes o mdulo de autoria (Professor), o mdulo de navegao (Estudante),
ou sair do sistema. A segunda sentena representa o menu principal do mdulo Professor,
descrevendo as opes disponveis no momento em que o software executa o mdulo de autoria.
Nas sentenas, os nomes que iniciam com b_ representam botes na interface, ao passo que o
restante representa opes de menu. Alm disso, para as opes que correspondem a aes
terminais do sistema (ou seja, que no necessitam ser expandidas em sentena subseqente, foi
adotado escrev-las com letras minsculas). As interaes escritas somente com letras
maisculas correspondem a aes a serem expandidas.
29
Mdudo do Prof essor

Elos
Glossrio
Roteiro
Ns
Abrir Hiperbase
clique do
boto
Prof essor
Interf ace de autoria
Salv ar hiperbase
b_criar_hiperbase
clique do
boto Sair
Menu Hiperbase
Hiperbase nov a criada
Menu Ajuda
clique do boto
Estudante
Menu Janelas
escolha da
opo Sair
Estudante
Figura 2.9 - Diagrama de estado representando as sentenas iniciais do ciclo de vida

Devido ao alto nmero de transies presentes no DTE mostrado na Figura 2.9, parte das
transies no esto com os nomes dos eventos que as disparam, pois caso contrrio a
visualizao do diagrama seria comprometida.
O Quadro 2.2 apresenta o formulrio de descrio de uma das operaes do sistema SASHE,
representada no DTE da Figura 2.9 como a transio b_criar_hiperbase. Essa transio
disparada sempre que ocorre o evento do boto Criar Hiperbase ser clicado.
Quadro 2.2 - Descrio da operao Criar Hiperbase
Operao:
b_Criar_hiperbase
Descrio:
Cria uma nova hiperbase vazia
L:
Modifica:
Envia:
Assume:
Resultado:
Se existe uma hiperbase aberta, ento criada uma nova

rea para edio de hiperbase e a hiperbase que estava
aberta fechada
Alteraes no salvas na hiperbase que estava aberta
estaro perdidas
Conforme comentado, a UML no especifica a representao de informao textual,

deixando a critrio das ferramentas de apoio UML tal representao. As Figuras 2.10 e 2.11
apresentam os campos disponibilizados pela ferramenta Rational Rose para a especificao de
30
cada transio entre os estados do DTE. Conforme indicado nas figuras pelas setas, esses
campos permitem que informaes descritas no Modelo de Operaes sejam incorporadas ao
DTE como caractersticas das transies, sem que isso altere a semntica do diagrama. As
informaes que aparecem nas Figuras 2.10 e 2.11 como parte da transio b_criar_hiperbase
foram retiradas do formulrio de descrio da operao, mostrado no Quadro 2.2.
Figura 2.10 - Janela para especificao geral da transio de estado na Rational Rose
Figura 2.11 - Janela para especificao detalhada da transio de estado na Rational Rose
31
Mapeamento Fusion-RE/I x UML (Viso Funcional)

Baseado nos estudos realizados sobre o mtodo Fusion-RE/I e sobre a UML, foi elaborada uma
proposta para a representao das informaes da fase de anlise recuperadas pela aplicao do
Fusion-RE/I utilizando-se a notao UML. Essa proposta teve como objetivo encontrar as
correspondncias entre as duas notaes, a utilizada pelo Fusion-RE/I e a UML, de forma que
toda informao contida nos modelos de anlise do mtodo Fusion-RE/I pudessem ser
representadas adequadamente em UML.
O Quadro 2.3 mostra de forma resumida quais elementos da UML foram utilizados para a
representao dos modelos de anlise do Fusion-RE/I.
Quadro 2.3 - Modelo de anlise Fusion-RE/I x UML
Fusion-RE/I
UML
Modelo de Objetos Fusion
Modelo de Objetos UML
Diagrama de Estados
Modelo de Operaes
2.4.2 Vises Estruturais x UML

Os documentos obtidos nessa etapa so compostos por trs quadros: Quadro de Chamadas,
Quadro ndice de Procedimentos e Quadro de Operaes-Procedimentos de Implementao.
Quadro de Chamadas
Existe um Quadro de Chamadas para cada arquivo do sistema. Nesse quadro so descritos todos
os procedimentos includos no arquivo, bem como quais so chamados e quais o chamam.
A partir de um estudo sobre quais tipos de notao UML suportariam tal quadro de
chamadas, pudemos verificar duas: packages e diagramas de componentes.
Na UML, um package um agrupamento de elementos de modelagem. Todos os tipos de
elementos de modelagem e diagramas UML podem ser organizados em packages, inclusive
outros packages (Rational, 1997b).
Um diagrama de componente um dos diagramas de implementao disponveis na UML.
Esse diagrama mostra as dependncias entre componentes de software, incluindo componentes
32
de cdigo fonte, componentes de cdigo binrio, e componentes executveis. representado

como um grafo de componentes conectado por relacionamentos de dependncia (Rational,
1997b).
O diagrama pode ser usado para mostrar interfaces e dependncias de chamadas entre os
componentes, usando setas pontilhadas dos componentes para interfaces de outros componentes.
Os componentes podem conter objetos; isto indica que o objeto parte do componente (Rational,
1997b). Existem esteretipos que qualificam o tipo de componente de software sendo
representado. Um desses esteretipos distingue a representao de subprogramas.
Se cada procedimento de um Quadro de Chamadas for representado como um componente,
podemos mostrar a seqncia de chamadas atravs das dependncias entre os componentes. O
conjunto de componentes (procedimentos) pertencentes a um mesmo arquivo podem ser
agrupados em packages que teriam como nome, o nome do arquivo e seu diretrio. Chamadas
entre procedimentos de arquivos diferentes tambm podem ser representadas, pois dependncias
e importaes entre packages so permitidas.
Dessa forma, a descrio informal dos procedimentos que faz parte do Quadro de Chamadas
dever continuar sendo descrita de forma textual, uma vez que a UML no fornece nenhuma
estrutura para esse tipo de elemento.
Notao para Diagrama de Componente em UML

Um componente uma parte reusvel que fornece o empacotamento fsico de elementos do
modelo. A sua semntica representa uma mudana de nvel de abstrao: enquanto todos os
outros elementos de modelagem (exceto componentes e ns) representam uma abstrao lgica,
componente representa uma abstrao fsica, significando uma abstrao da implementao
fsica de instncias de outros elementos de modelagem.
Uma instncia de componente no pode implementar outra instncia de componente ou de
n. Uma instncia de componente pode implementar zero ou mais instncias de elementos de
modelagem, e toda instncia de um elemento de modelagem pode ser implementada por zero ou
mais instncias de componentes.
Um tipo de componente representa um pedao do cdigo do software. Existem seis
esteretipos padro que se aplicam a componentes (Rational, 1997c). Eles so usados para tornar
o diagrama mais preciso e claro, definindo o qu cada tipo de componente representa no mundo
33
real (Eriksson; Magnus, 1998). Na Rational Rose (Rational, 1999) um componente que
representa um subprograma pode ser apresentado como um retngulo, conforme mostrado na
Figura 2.12.
NewSubprogBody
Figura 2.12 - cone utilizado pela Rational Rose para representar o corpo de um subprograma
Um componente mostrado como um retngulo com uma pequena elipse e dois retngulos
menores projetando-se em um de seus lados. Uma instncia de componente tem um nome e um
tipo. O nome do componente e seu tipo pode ser mostrado como uma string sublinhada, seja
dentro do smbolo de componente, acima ou abaixo, com a sintaxe:
component-name : component-type
Um diagrama de componente engloba os componentes e seus relacionamentos. Um

diagrama de componente um grafo de componentes conectado por relacionamentos de
dependncia (Rational, 1997c), conforme mostrado na Figura 2.13. Componentes tambm
podem ser conectados a componentes por um compartimento fsico representando
relacionamentos de composio.
Uma dependncia indica uma relao semntica entre dois (ou mais) elementos do modelo.
Ela relaciona os prprios elementos do modelo e no requer um conjunto de instncias para ter
significado. Ela indica uma situao em que uma mudana no elemento alvo pode requerer uma
mudana no elemento fonte na dependncia.
Interface do Componente 1
Componente 1
Interface do Componente 2
Componente 2
Componente 3
Figura 2.13 - Exemplo de diagrama de componente

34
A relao de dependncia mostrada como uma seta pontilhada de um elemento para outro
elemento do modelo, onde o primeiro elemento o dependente (na Figura 2.13, Componente 3
depende do Componente 2, que depende do Componente 1). A seta pode ser rotulada
opcionalmente com um esteretipo ou um nome. A UML prov esteretipos padres que se
aplicam a dependncias, de forma a especificar o tipo de dependncia que est sendo modelada.
A Figura 2.14 apresenta o diagrama de componentes construdo para o Quadro de Chamadas
do arquivo ancora.cpp. O Quadro de Chamadas mostrado no Quadro 2.4. Os diagramas de
componentes tambm foram construdos com o auxlio da ferramenta Rational Rose (Rational,
1999). Mesmo possibilitando a representao de subprogramas nos diagramas de componente, a
ferramenta no disponibiliza espao para descrio textual dos mesmos. Dessa forma, parte das
informaes contidas nos Quadros de Chamadas no so incorporadas ao diagrama.
A sintaxe utilizada na Figura 2.14 a mesma apresentada anteriormente. As setas de
dependncia, no caso da figura, explicitam as chamadas entre os subprogramas. Algumas
chamadas esto direcionadas para um arquivo e no para um procedimento. Isso foi feito para
que o diagrama ficasse mais claro e sua leitura fosse facilitada.
Quadro 2.4 - Quadro de Chamadas recuperado do arquivo ancora.cpp
Sistema: SASHE
Arquivo: ancora.cpp
Procedimento:
(12) ancora::ancora(int Ind, int
ide): entidade(Ind)
Diretrio/Arquivo:
hyperprop/ancora.cpp
Descrio:
Construtor da ncora
Chama:
(12) entidade(Ind)
Chamado por:
Anc_aud.cpp\(12) ancora_audio::ancora_audio(int
ind, int ide) : ancora(ind, ide)
Anc_cont.cpp\(12)
ancora_contexto::ancora_contexto(int ind,int
ide,int id_no) : ancora(ind, ide)
Anc_exec.cpp\(12)
ancora_executavel::ancora_executavel(int ind, int
ide) : ancora(ind, ide)
Anc_ima.cpp\(12) ancora_imagem::ancora_imagem(int
Anc_tab.cpp\(12) ancora_tabela::ancora_tabela(int
Anc_tex.cpp\(14) ancora_texto::ancora_texto(int
ind, int ide, char *pal, int inicio, int fim) :
ancora(ind, ide)
Anc_tri.cpp\(12) ancora_trilha::ancora_trilha(int
ind,int ide) : ancora(ind, ide)
Anc_vid.cpp\(12) ancora_video::ancora_video(int
35

Procedimento:
(20) ancora::ancora(int Ind):
entidade(Ind)
Diretrio/Arquivo:
Descrio:
Construtor usado quando a ncora recuperada do
arquivo.
Chama:
(20) entidade(Ind)
Chamado por:
Anc_aud.cpp\(19) ancora_audio::ancora_audio(int
ind): ancora(ind)
Anc_cont.cpp\(20) ancora_contexto ::
ancora_contexto(int ind) : ancora(ind)
Anc_exec.cpp\(19)
ancora_executavel::ancora_executavel(int ind):
ancora(ind)
Anc_ima.cpp\(19) ancora_imagem::ancora_imagem(int
ind): ancora(ind)
Anc_tab.cpp\(19) ancora_tabela::ancora_tabela(int
ind): ancora(ind)
Anc_tex.cpp\(24) ancora_texto::ancora_texto(int
ind): ancora(ind)
Anc_tri.cpp\(19) ancora_trilha ::
ancora_trilha(int ind) : ancora(ind)
Anc_vid.cpp\(19) ancora_video::ancora_video(int
ind): ancora(ind)
Procedimento:
Descrio:
(28) int ancora::grava_ancora(FILE Salva os atributos da ncora em arquivo.
*fp)
Diretrio/Arquivo:
Chama:
(30) entidade::grava(fp)
Chamado por:
anc_cont.cpp\(38) int
ancora_contexto::grava_ancora(FILE *fp)
anc_text.cpp\(61) int
ancora_texto::grava_ancora(FILE *fp)
list_anc.cpp\(71) int lista_ancoras :: grava(FILE
*fp)
Procedimento:
Descrio:
(38) int
Recupera os atributos da ncora do arquivo.
ancora::recupera_ancora(FILE *fp)
Diretrio/Arquivo:
Chama:
(40) fscanf(fp, "%d)\n", &ident)
Chamado por:
anc_cont.cpp\(47) int
ancora_contexto::recupera_ancora(FILE *fp)
anc_text.cpp\(71) int
ancora_texto::recupera_ancora(FILE *fp)
list_anc.cpp\(118) int lista_ancoras ::
recupera(No *n, FILE *fp)
36

entidade::entidade(int id)
int entidade::f scanf (FILE *f p, const char *f ormat, int *item)
Lis t_
anc.cpp
Anc_tri.cpp
ncora.cpp
Anc_
ima.cpp
int ancora::recupera_ancora(FILE *f p)
ancora::ancora(int Ind): entidade(Ind)
Anc_
tab.cpp
Anc_
aud.cpp
ancora::ancora(int Ind, int ide): entidade(Ind)
int ancora::grav a_ancora(FILE *f p)
Anc_
v id.cpp
Anc_
exec.cpp
int entidade::grav a(FILE *f p)

Anc_
tex.cpp
Anc_
cont.cpp
Figura 2.14 - Diagrama de componentes para o arquivo ancora.cpp
Quadro de ndice
O quadro de ndice proveniente do Quadro de Chamadas e trata-se de uma lista, em ordem
alfabtica, de todos os procedimentos de implementao do sistema, com suas respectivas
localizaes (arquivo e diretrio).
Esse quadro tem como finalidade agilizar o trabalho de manipulao dos procedimentos. Por
tratar-se apenas de uma lista textual, esse quadro no necessita de uma representao especfica
em UML.
Quadro de Operaes Procedimentos de Implementao

Esse quadro tem por objetivo identificar quais os procedimentos que implementam as operaes
da interface e classific-los, de acordo com sua funcionalidade, interface ou a um dos temas
definidos.
37
Por tratar-se de uma tabela, a UML no fornece uma representao direta. No encontramos
na notao UML um diagrama que relacionasse, diretamente, os procedimentos de
implementao com as operaes da interface com o usurio, como acontece no quadro de
Operaes Procedimentos de Implementao.
Assim, optamos por deixar o mapeamento desse quadro em aberto.
Mapeamento Fusion-RE/I x UML (Viso Estrutural)

Os quadros gerados durante a fase de recuperao de vises estruturais do Fusion-RE/I no
utilizam modelos de um mtodo de desenvolvimento de software, como acontece na fase de
recuperao do modelo de anlise, na qual so utilizados os modelos do mtodo Fusion. Desta
forma, as informaes recuperadas so expressas de forma tabular.
Como a UML no trata representaes tabulares, foi proposto um diagrama UML para a
representao de um dos quadros gerados atravs da aplicao do Fusion-RE/I, de forma que
haja correspondncia entre o quadro e o diagrama. Os outros quadros devero permanecer na
forma tabular.
O Quadro 2.5 mostra de forma resumida quais elementos da UML podem ser utilizados para
a representao das vises estruturais do Fusion-RE/I.
Quadro 2.5 - Vises Estruturais Fusion-RE/I x UML
Fusion-RE/I
UML
Quadro de Chamadas
Diagrama de Componentes
Quadro de ndice
Quadro de Operaes Procedimentos

de Implementao
2.5 Consideraes Finais

Neste captulo foram abordados os principais conceitos relacionados Engenharia Reversa de
Software, bem como o mtodo de engenharia reversa utilizado neste trabalho, o Fusion-RE/I.
Sendo que o Fusion-RE/I utiliza modelos do mtodo de desenvolvimento de sistemas Fusion,
esse foi introduzido, seguido das respectivas fases de recuperao de informao do FusionRE/I: recuperao de vises funcionais do sistema e recuperao de vises estruturais do
38
sistema. O Quadro 2.6 apresenta um resumo das etapas previstas pelo mtodo Fusion-RE/I,
mostrando a ordem de execuo das tarefas.
Quadro 2.6 - Ordem das tarefas prescritas pelo Fusion-RE/I
Etapa 1. Recuperao de Vises Funcionais
a. Obteno de informaes existentes sobre o sistema

b. Recuperao do modelo de anlise
b1. Elaborao do Modelo de Ciclo de Vida
b2. Elaborao do Modelo de Operaes
b3. Elaborao do Modelo de Objetos
Etapa 2. Recuperao de Vises Estruturais
a. Elaborao do Quadro de procedimentos de implementao

a1. Elaborao do Quadro de Chamadas
a2. Elaborao do Quadro ndice de procedimentos
b. Elaborao do Quadro de Operaes-Procedimentos de Implementao
Tambm nesse captulo foi discutido o porqu da opo pela utilizao da notao UML
para a representao dos modelos recuperados atravs da aplicao do mtodo Fusion-RE/I e foi
apresentada uma proposta para o mapeamento da representao utilizada pelo Fusion-RE/I para a
notao UML, j que foi objetivo deste trabalho que as informaes recuperadas pela aplicao
do mtodo Fusion-RE/I estivessem de acordo com a notao UML. Tal mapeamento foi
realizado, e foram apresentados exemplos dos resultados.
Orientando-se para utilizar a notao UML, o processo de engenharia reversa segundo o
mtodo Fusion-RE/I foi ento realizado. Entretanto, devido a restrio do SASHE de no
permitir a criao de ncoras e links
entre documentos grficos, os modelos textuais do
Fusion-RE/I foram construdos de forma a tornar completa a recuperao de informaes

almejada.
Compem a proposta deste trabalho a construo de uma hiperbase, com um conjunto de
links representativos no domnio da Engenharia Reversa, que auxilie no decorrer do processo de
recuperao de informaes, permitindo que os documentos gerados durante a aplicao de um
mtodo de engenharia reversa estejam disponveis na forma de hiperdocumento. Dessa forma, no
prximo captulo discutido o suporte dado pela tecnologia de hipermdia organizao de
documentos dentro de vrios domnios de aplicao, mais especificamente a Engenharia de
Software e a Engenharia Reversa.
39
40
Captulo 3
O Suporte de Sistemas Hipermdia

Nielsen (1995) define hipermdia como sendo a tecnologia que habilita intrinsecamente a leitura
no-seqencial, em contraste com a forma de leitura seqencial disponvel nos livros-textos.
Ento, um hiperdocumento consiste de pedaos de informao (denominados ns)
interconectados (pelos chamados links) e o contedo de um n pode ser de vrios tipos tais como
texto, grfico, imagem, som, cdigo executvel, etc.
Essa forma de estruturao fornece uma grande flexibilidade para que se faa o
relacionamento entre documentos que no possuem uma estrutura de relacionamentos bem
definida (Meira; Cabral, 1994).
Os sistemas hipermdia tm sido aplicados em vrios domnios, como pode ser constatado
nos trabalhos de Castro (1997), Nunes et al. (1997b), Nunes e Fortes (1997), cujo domnio de
aplicao o ensino, e outros como: Meira e Cabral (1994), e Bigelow e Riley (1987), onde o
domnio a engenharia de software; Rizk e Sutcliffe (1997), e Bullock e Goble (1997), onde o
domnio informaes tursticas e culturais. O uso dos sistemas hipermdia em domnios
diversificados tm ocorrido devido no s a sua flexibilidade para relacionar diferentes tipos de
documentos, mas tambm por permitir um maior controle por parte do usurio sobre as
informaes que so recuperadas.
Para engenharia de software a tecnologia hipermdia pode ser de grande auxlio, uma vez
que existe um relacionamento entre os documentos gerados durante o ciclo de vida de um
software, embora esse relacionamento no tenha uma forma bem definida (Meira; Cabral, 1994).
41
Captulo 3 - O Suporte de Sistemas Hipermdia
A estruturao dos documentos do ciclo de vida do software na forma de hiperdocumento

pode ser explorada no s no auxlio navegao, mas tambm como forma de associar mais
informaes aos relacionamentos, tornando-os mais explcitos. Isso permite uma melhor
avaliao das dependncias entre os documentos que descrevem o ciclo de vida do software, de
forma que a visualizao dos efeitos que as mudanas em um documento causariam sobre outro
pode ser feita com maior preciso.
Na Engenharia Reversa, a estruturao adequada das informaes recuperadas de um
sistema na forma de um hiperdocumento possibilitaria estabelecer no s um melhor
relacionamento entre os documentos, mas traria uma maior garantia de fidelidade do contedo da
documentao com relao ao produto de software que est sendo documentado (Tilley; Smith,
1997). Alm disso, espera-se que uma melhor consistncia entre as partes do hiperdocumento e
os componentes de software seja obtida com mais facilidade por meio dos links definidos.
Dessa forma, o alvo deste trabalho foi especificar uma estrutura de hiperbase que fosse
adequada engenharia reversa. Para tanto, foi realizada a engenharia reversa no sistema
hipermdia SASHE, cujo domnio de aplicao o ensino. Esse exerccio proporcionou um
levantamento efetivo dos requisitos para a especificao do conjunto de estruturas relevantes ao
domnio de documentao do processo de engenharia reversa de software.
Para que tivssemos um ponto de partida bem definido para a construo da hiperbase,
contendo os documentos recuperados, uma modelagem conceitual do domnio de engenharia
reversa foi necessria. Para a realizao de tal modelagem, foi utilizado o mtodo OOHDM
Object Oriented Hypermidia Design Methodology (Schwabe; Rossi, 1995), (Rossi, 1996),
(Schwabe et al., 1996). O OOHDM um mtodo voltado para o desenvolvimento de aplicaes
hipermdia que descreve as tarefas a serem executadas desde a anlise de domnio da aplicao
at a sua implementao (Schwabe et al., 1996). Ele um descendente direto do HDM (Garzotto
et al., 1993), incorporando uma srie de novos conceitos vindos sobretudo da orientao a
objetos.
Uma vez que o mtodo de Engenharia Reversa utilizado, o Fusion-RE/I, tambm orientado
a objetos, a utilizao do OOHDM nos pareceu mais natural, j que o Fusion-RE/I serviu como
base para essa modelagem. A fim de estabelecer o mtodo de modelagem hipermdia a ser
utilizado para modelar o domnio do processo de engenharia reversa, em Feltrim e Fortes
42
(1998a) foi feito um estudo de algumas abordagens presentes na literatura que pudessem
satisfazer os nossos objetivos.
Baseada na modelagem conceitual resultante e levando em conta os conceitos do MCA
(Casanova et al., 1991), foi construda uma hiperbase contendo os documentos recuperados do
sistema SASHE, no prprio sistema. Com a hiperbase pronta, a modelagem pde ser validada,
uma vez que o processo realizado foi uma instncia do modelo proposto.
Essa tarefa de inserir os documentos do sistema SASHE no prprio SASHE foi o exerccio
que revelou requisitos necessrios para que o esse sistema se tornasse adequado ao domnio de
engenharia reversa. De fato, foi constatado que para que o SASHE comportasse a documentao
de engenharia reversa e permitisse uma navegao eficiente atravs desses documentos, alguns
pontos precisam ser ajustados. Assim, elaboramos uma proposta de adequao, contendo as
modificaes necessrias para que o sistema se torne adequado ao domnio de engenharia
reversa.
O SASHE, sistema alvo da engenharia reversa realizada, apresentado na Seo 3.1. Na
Seo 3.2 descrito o mtodo utilizado, OOHDM, seguido pelos resultados da modelagem
resultante, que mostrada na Seo 3.3. Na Seo 3.4 mostrada a hiperbase construda para o
sistema SASHE, e na Seo 3.5 apresentada uma proposta de adequao do sistema SASHE
para o domnio de engenharia reversa de software. Finalmente, na Seo 3.6 so apresentadas as
consideraes finais sobre este captulo.
3.1 O Sistema SASHE

Desenvolvido totalmente no Departamento de Computao do ICMC-USP/S.Carlos, o ambiente
SASHE teve como suporte, um projeto maior do ProTeM/HyperProp (Soares et al., 1995), o qual
tinha como um de seus objetivos explorar as potencialidades do Modelo de Contextos Aninhados
(MCA) (Casanova et al., 1991) como modelo conceitual de dados de hipermdia.
A Figura 3.1 apresenta a arquitetura geral dos mdulos funcionais de SASHE, mostrando
seus usurios de forma esquemtica, segundo Nunes et al. (1997b). Pode-se observar que
existem mdulos funcionais especficos para cada um dos tipos de usurios previstos no
ambiente (Autoria e Navegao). No entanto, essa arquitetura modular no havia sido detalhada
43
por meio de documentao de projeto, em qualquer dos documentos pertinentes ao ambiente

SASHE.
Dessa forma, com o desenvolvimento da engenharia reversa sobre o SASHE, pde ser
recuperada toda a documentao fiel ao sistema implementado.
O sistema hipermdia SASHE - Sistema de Autoria e Suporte Hipermdia para Ensino tem
como caracterstica permitir que um autor de hiperdocumentos possa qualificar e organizar os
elementos constituintes (ns) do documento, de modo que o sistema resultante contenha funes
adicionais navegao tradicional. Tais funes incluem recursos para a localizao contextual
do leitor, bem como estratgias instrucionais dependentes dos valores dos atributos dos ns
(Nunes et al., 1997b).
Autor Geral
Hip
Confeco
de Roteiros
Autor de Roteiros
Hiperbase
Mdulo de
Navegao
Leitor/Usurio
Mdulo de Autoria
Figura 3.1 - Arquitetura geral dos mdulos funcionais de SASHE.

O ambiente SASHE prev dois tipos de usurios: o professor, atuando como autor, e o
estudante, atuando como leitor. Os usurios so chamados professor e estudante devido ao
domnio da aplicao atual do sistema ser o ensino. Por autor entende-se o construtor da
hiperbase bem como o construtor de roteiros sobre uma hiperbase j existente.
Embora o MCA se fundamente nos conceitos de ns terminais e vrias classes de ns de
contexto, o SASHE utiliza apenas ns terminais, ns de contexto do tipo trilha, contexto de
usurio e hiperbase pblica. Dentro da aplicao, os ns de contexto so classificados de acordo
com o assunto que englobam, ao passo que os ns terminais so classificados quanto a sua
funo didtica, dificuldade e palavras-chave que qualificam o contedo.
A funo didtica indica um dos seguintes tipos possveis de documento no domnio
de
aplicao
ensino:
introduo,
exerccio,
motivao,
definio,
bibliografia, glossrio, exemplo, resumo e ajuda. Caso desejado, esses valores

podem ser revistos ou estendidos, sem causar problemas no funcionamento geral do sistema.
44
A dificuldade indica o nvel de dificuldade do n terminal, que pode ser classificado

como fcil, regular ou difcil.
No caso de ns de contexto, apenas o atributo nome deve ser preenchido, sendo que este
passa a ter a funo de assunto, indicando qual assunto tratado pelos ns contidos nesse
contexto. Por definio, o sistema considera que todos os ns contidos em um determinado
contexto pertencem ao assunto correspondente. Dessa forma, para a construo da hiperbase,
deve-se levar em conta essa caracterstica e atribuir os assuntos mais especficos aos contextos
mais internos. Dessa forma, o hiperdocumento apresentar uma hierarquia de assuntos,
facilitando o entendimento da estrutura do mesmo (Nunes et al., 1997b).
A partir de um hiperdocumento j existente, o autor pode criar roteiros de navegao,
visando atingir um determinado grupo de usurios. Dessa forma, o autor de roteiros decide quais
ns estaro no roteiro, definindo tambm o grau de liberdade associado a cada n, de forma a
especificar quanto o leitor poder se afastar do roteiro, sem que isso comprometa a relevncia
do material. A criao de roteiros feita no mesmo mdulo de autoria em que o hiperdocumento
foi criado.
Como ferramenta para auxiliar tanto na criao da hiperbase como na criao de roteiros, o
SASHE disponibiliza um browser grfico, que permite ao usurio visualizar a estrutura do
hiperdocumento ou parte dela como um grafo. Para ativ-lo basta clicar sobre o boto browser
grfico, e os ns pertencentes ao contexto atual sero exibidos. Atravs do ttulo da janela
possvel se saber qual contexto est sendo visualizado. Para a visualizao de contextos mais
aninhados, caso existam, basta pressionar o boto direito do mouse sobre o n escolhido.
No mdulo de leitura o usurio encontra vrios recursos de navegao adicionais
(Figura 3.2), que permitem a navegao levando em conta as informaes dos atributos e da
contextualizao dos ns. O usurio pode navegar normalmente, avanando ou retrocedendo no
roteiro que est seguindo, ou navegar de acordo com o grau de dificuldade encontrado. Isso se d
atravs das funes Est fcil e Est difcil. Dessa forma, o atributo dificuldade
levado em conta quando feito uso desse recurso, apresentando ao usurio um n com grau de
dificuldade maior ou menor, dependendo da funo escolhida. A busca por ns mais fceis ou
mais difceis se d sempre dentro do contexto em que se encontra o usurio. Caso no se
encontre dentro do contexto atual um n que seja adequado ao grau de dificuldade requerido,
passa a ser feita a busca por um n com uma funo didtica anterior atual, no caso de
45
se procurar por um n mais fcil ou, com uma funo didtica posterior, no caso de se
procurar por um n mais difcil.
As estratgias de busca por funo didtica associada ao grau de dificuldade um
diferencial importante, o qual reflete um suporte melhor para orientao do usurio/leitor.
O usurio tambm pode avanar ou retroceder dentro do caminho percorrido por ele,
independente se esse caminho coincidente com o roteiro ou no, atravs da funo
Histrico. A funo Onde estou? situa, graficamente, a posio do n atual em relao
ao roteiro programado.
Figura 3.2 - Controles de navegao disponveis no sistema SASHE

A funo Mais
informaes dispara uma busca por uma lista, em todo
hiperdocumento, de ns que possuem palavras-chave em comum com o n atual, sendo que

qualquer um dos ns selecionados podero ser visualizados pelo leitor. Informaes teis
tambm podem ser conseguidas atravs das funes Bibliografia, Exerccios e
Glossrio. A funcionalidade das funes Bibliografia e Exerccios recuperar ns
com os respectivos valores de funo didtica. A funo Glossrio permite o acesso ao
glossrio disponvel.
46
A partir dessas caractersticas operacionais descrevendo a interface do SASHE, obtidas dos

documentos de requisitos Nunes et al. (1996, 1997b), foi possvel dar incio aplicao do
Fusion-RE/I ao SASHE, por meio do cumprimento da primeira fase do mtodo.
Na seo seguinte (3.1.1) brevemente comentado o MCA, o modelo conceitual de dados
de hipermdia sobre o qual o sistema SASHE baseado.
3.1.1 Modelo de Contextos Aninhados

No modelo MCA (Casanova et al., 1991), os documentos so definidos com base nos conceitos
de ns e elos. Ns so fragmentos de informao e elos interconectam os ns que mantm
alguma relao entre si. Nesse modelo, os ns podem ser classificados como ns terminais ou
ns de composio.
Segundo Nunes et al. (1996), um n terminal caracteriza-se por conter dados cuja estrutura
interna dependente da aplicao. Sendo assim, essa classe de n pode conter objetos com
informaes textuais, grficas, de udio, vdeo, etc.
Um n de composio um agrupamento de ns que pode incluir outros ns de composio.
Podemos distinguir duas classes de ns de composio: ns de contexto e ns do tipo trilha.
Um n de contexto agrupa um conjunto de elos, trilhas, ns terminais e de contexto,
recursivamente. Esse tipo de n permite o aninhamento em qualquer profundidade, permitindo
organizar hierarquicamente, ou no, conjuntos de ns. Os ns de contexto se especializam nas
classes de ns de anotao, contexto de verses, bases privadas, hiperbases pblicas e contexto
de usurio.
So denominados trilhas ns de composio que contm uma lista ordenada de ns. Ns
trilha podem incluir, recursivamente, outros ns trilha. A idia representar caminhos que
devem ser, ou que foram, percorridos pelo usurio.
Como o MCA foi o fundamento lgico dos mecanismos que devem estar disponibilizados
no SASHE, as investigaes referentes s estruturas lgicas dos dados e procedimentos
implementados no SASHE, se orientam a partir das definies propostas no MCA. Tais
conceitos, de certa forma, auxiliaram tambm a primeira etapa do mtodo Fusion-RE/I.
47
3.2 O mtodo OOHDM

O OOHDM considera o processo de desenvolvimento de uma aplicao hipermdia como um
processo de quatro atividades, desempenhadas combinando-se estilos iterativos e incrementais
de desenvolvimento; em cada etapa um modelo construdo ou enriquecido (Rossi, 1996).
Produtos
Mecanismos
Interesses do Projeto
Classes, subsistemas,
relacionamentos,
perspectivas de atributos
Classificao, composio,
generalizao e
especializao
Modelagem da semntica
do domnio de aplicao
Projeto da
Navegao
Ns, elos, estruturas de

acesso, contextos de
navegao,
transformaes
navegacionais
Mapeamento entre objetos

conceituais e de navegao.
Padres de navegao para
a descrio da estrutura geral
da aplicao.
Leva em conta o perfil do

usurio e a tarefa; nfase
em aspetos cognitivos e
Arquiteturais.
Projeto da
Interface
Abstrata
Objetos de interface
abstrata, reaes a eventos
externos, transformaes
de interface
Mapeamento entre objetos de

navegao e objetos de
interface.
Modelagem de objetos
perceptveis, implementa
metforas escolhidas.
Descrio de interface para
objetos navegacionais
Implementao
Aplicao em execuo
Aqueles fornecidos pelo

ambiente alvo
Desempenho, completitude
Fases
Modelagem
Conceitual
Figura 3.3 - Esboo da Metodologia OOHDM (Rossi, 1996)

Na Figura 3.3 mostrado um esboo do OOHDM, destacando cada uma das quatro fases
que compem o mtodo, juntamente com os produtos gerados em cada fase, os mecanismos de
abstrao utilizados na fase correspondente, e qual o foco empregado em cada uma das fases do
mtodo.
A modelagem conceitual dos dados feita utilizando-se os princpios da modelagem
orientada a objetos, onde o principal objetivo construir um modelo do domnio da aplicao. O
resultado um modelo conceitual composto por subsistemas, classes e relacionamentos.
Na modelagem da navegao feita a descrio da estrutura navegacional da aplicao, em
termos de contextos navegacionais, levando em conta os tipos de usurios da aplicao e suas
tarefas. Os ns representam vises sobre as classes conceituais definidas durante a anlise do
domnio e os links so derivados dos relacionamentos conceituais. Diferentes modelos
navegacionais podem ser feitos para o mesmo modelo conceitual, expressando diferentes vises
48
do mesmo domnio. Tendo os ns e os links definidos, o movimento dentro do espao

navegacional pode ser modelado, independente do modelo conceitual.
No projeto da interface abstrata construdo um modelo especificando quais objetos de
interface sero vistos pelo leitor, e particularmente, a forma de apresentao dos diferentes
objetos navegacionais, as transformaes causadas pela ativao desses objetos, quais objetos
ativaro a navegao, a maneira como os objetos multimdia sero sincronizados e quais
transformaes ocorrero na interface. Podem ser feitos diferentes projetos de interface abstrata
para o mesmo projeto navegacional, de acordo com as preferncias dos leitores.
Na etapa de implementao feito o mapeamento dos objetos de interface para objetos de
implementao.
Em Feltrim e Fortes (1998a) apresentado um estudo mais aprofundado do mtodo
OOHDM, com o intuito de realizar a modelagem do domnio do processo de engenharia reversa.
3.3 Modelagem hipermdia do domnio de Engenharia

Reversa
Nas subsees seguintes so mostrados os modelos gerados atravs da aplicao do mtodo
OOHDM para o domnio de engenharia reversa de software. Cada um dos modelos descrito,
esclarecendo suas semnticas. Para este trabalho, apenas a primeira etapa do mtodo OOHDM
foi suficiente para que os objetivos fossem alcanados. Dessa forma, foram construdos um
modelo conceitual, um modelo de classes navegveis e um modelo de contexto de navegao.
Em Feltrim e Fortes (1998b), essa modelagem apresentada como parte dos requisitos
funcionais identificados no processo de Engenharia Reversa de Software que possam ser
suportados por um Sistema Hipermdia.
3.3.1 Esquema Conceitual

Na fase de modelagem conceitual construdo um esquema conceitual do domnio em questo.
O foco est em modelar os objetos que constituem o domnio e os relacionamentos entre eles,
49
sendo que nessa atividade observa-se uma maior preocupao com a estrutura dos objetos do que
com seu comportamento. Para o desenvolvimento do modelo empregada a abordagem
orientada a objetos, segundo a notao do mtodo OMT (Rumbaugh et al., 1991), com a adio
de alguns elementos novos, como o conceito de subsistemas e de perspectiva de atributos.
Dessa forma, dizemos que um modelo conceitual definido atravs de classes, subsistemas
e relaes, organizados de acordo com a semntica do domnio.
O modelo de classes do processo de engenharia reversa (PER) foi derivado do estudo desse
processo sob a perspectiva do mtodo de engenharia reversa Fusion-RE/I, segundo demonstrado
na Figura 3.4. Os elementos presentes no modelo podem ser agrupados em duas hierarquias
principais: uma hierarquia de tarefas de engenharia reversa e uma hierarquia de produtos
gerados.
Figura 3.4 - Modelo Conceitual do PER para o Fusion-RE/I
50
As classes Pessoa e Tarefa de Engenharia Reversa (TER) definem a parte do modelo

correspondente ao gerenciamento de projeto. Como TER corresponde a atividade de recuperao
de informaes relevantes gerao de uma viso do sistema, foi definido o relacionamento umpara-um entre TER e Viso. Pessoa est relacionada com TER apesar dessa tarefa poder ser vista
como mais de uma atividade. Na modelagem, entretanto, foi considerado TER como uma tarefa
que pode ser desenvolvida por uma nica pessoa e no existe a necessidade de se controlar a
execuo da TER por mais de uma pessoa, da o relacionamento muitos-para-um entre TER e
Pessoa. So as TER que conectam a parte de projeto e os produtos gerados. Uma TER pode ser
uma: Consulta a Documento Existente, Anlise da Interface, ou Anlise do Cdigo Fonte. Essas
tarefas so descritas pelo mtodo Fusion-RE/I, sendo que, segundo o mtodo, apresentam uma
ordenao definida para a realizao de cada uma delas. No decorrer do processo, no entanto,
essa ordem pode mudar de acordo com as necessidades do engenheiro reverso, e certas tarefas
podem ser novamente realizadas.
Uma Viso define uma interpretao do sistema sob Engenharia Reversa. Essa interpretao
corresponde a um nvel de abstrao, sendo que pode ser estrutural, funcional ou de domnio. O
Fusion-RE/I prope recuperao de vises tanto ao nvel estrutural como funcional. Assim, a
representao de um sistema composta por um conjunto de vises, e isso expresso pelo
relacionamento um-para-muitos entre Software e Viso.
Uma Viso um agregado de documentos e dos relacionamentos existentes entre esses
documentos. Um documento um Documento Externo que descreve informaes recuperadas
por uma TER. Relacionamento com outros Docs descreve uma ligao entre um documento e
seus documentos relacionados.
Documento Externo um dos modelos ou quadros propostos como resultado do FusionRE/I. No esquema conceitual (modelo de classes), todos os documentos so implicitamente
relacionados atravs de seus atributos. As operaes contidas no Modelo de Ciclo de Vida so as
mesmas que compem o Modelo de Operaes. Da mesma forma, cada operao descrita em
Operao constituinte do Modelo de Operaes e parte de um Objeto. Modelo de Objetos
um agregado de objetos relacionados sendo que o atributo Tema indica o tema que inspirou o
Modelo de Objetos em questo. O Quadro de Operaes-Procedimentos de Implementao um
agregado de Item, onde cada Item compe uma entrada do quadro. As operaes citadas nesse
modelo tambm so as mesmas descritas nos modelos mencionados anteriormente. Da mesma
51
forma, os procedimentos presentes em cada Item tambm so descritos em Procedimento. A

agregao de Procedimento compe os Quadros de Chamadas, cujo atributo arquivo indica o
arquivo onde se encontra o cdigo que implementa Procedimento. O relacionamento explcito
entre Operao e Procedimento se faz necessrio uma vez que, apesar de existir o
relacionamento (uma operao implementada por um procedimento), no existem atributos
relacionados. O relacionamento um-para-muitos se explica por uma operao ser implementada
por um ou mais procedimentos.
3.3.2 Esquema de Classes Navegacionais

A modelagem navegacional gera dois produtos principais: um esquema de classes navegacionais
e um esquema contextual ou de contextos de navegao (Seo 3.3.3). Neles so descritos as
classes de ns, as classes de ligaes, as estruturas de acesso e os contextos de navegao que
compem a aplicao (Cerqueira, 1997).
Como pode ser visualizado na Figura 3.5, o esquema de classes navegacionais derivado do
esquema conceitual descrito anteriormente, e composto pelas classes que sero efetivamente
navegadas, ou seja, sero visualizadas pelo usurio do aplicativo, e as ligaes entre elas, isto ,
as conexes que fazem sentido na viso navegacional sendo modelada.
Figura 3.5 - Modelo de Classes Navegacionais

Dentro do processo descrito anteriormente no esquema conceitual, as classes navegveis
sero os produtos gerados pelas TER (modelos e quadros). Com exceo do Modelo de Ciclo de
Vida e do Modelo de Objetos, todos os outros produtos so uma agregao de outros objetos.
Dessa forma, as classes que compem a agregao que sero navegados, e no a classe
agregada.
52
Assim, as classes componentes do esquema navegacional so Operao, Objeto,

Procedimento, Item, Modelo de Objetos e Modelo de Ciclo de Vida. Nesse esquema tornam-se
explcitos os relacionamentos que no esquema conceitual esto implcitos por meio dos atributos
contidos nas classes. Esses relacionamentos so expressos pelas setas rotuladas. O
direcionamento das setas foi decidido considerando os objetos Operao, Objeto, Procedimento,
Modelo de Ciclo de Vida e Modelo de Objetos como possveis entradas para o incio da
navegao. A partir disso os outros objetos foram relacionados de forma que todos pudessem ser
alcanados e os relacionamentos fossem coerentes.
3.3.3 Esquema Contextual

Os contextos navegacionais so geralmente induzidos pelas classes navegacionais e expressam a
estrutura navegacional geral da aplicao, enquanto as classe navegacionais especificam os
objetos que sero vistos pelo usurio (Rossi, 1996).
Os contextos so um conjunto de instncias relacionadas, como, por exemplo, todos
procedimentos em um determinado arquivo, todos os procedimentos com uma determinada data,
etc. No esquema contextual as classes navegveis so mostradas juntamente com os contextos
em que podem aparecer na aplicao. Os contextos so representados por caixas pontilhadas que
aparecem dentro da classe a qual o contexto pertence. Para simplificao do diagrama, os
contextos podem ser agrupados em quadros pontilhados maiores quando conveniente. As setas
indicam navegao ou mudana de contexto. Quando uma seta chega a um agrupamento de
contexto, isto indica que qualquer um dos contextos pertencentes ao agrupamento estar
disponvel para a navegao, sendo que os contextos da classe que no estiverem no
agrupamento no sero visveis. Os ndices tambm aparecem com caixas pontilhadas entre as
setas de navegao.
No esquema contextual apresentado na Figura 3.6, o ndice esquerda o principal, a partir
do qual podem ser acessados diversos ndices intermedirios. Cada classe pode ento ser
navegada nos contextos mostrados na figura. Um exemplo de navegao em diferentes contextos
pode ser visualizado na classe Procedimento. Uma vez que os procedimentos so acessados
atravs do ndice de procedimentos, cada instncia da classe Procedimento pode ser navegada
tanto no contexto por data como no contexto por arquivo. No entanto, quando a classe
53
Procedimento acessada atravs da classe Operao, a classe Procedimento passa a poder ser
navegada no contexto por operao, uma vez que uma operao pode ser implementada por
mais de um procedimento. A partir desse contexto, a classe Procedimento pode ser navegada
tambm nos contextos por data e por arquivo. Dessa forma, o contexto por operao s visvel
quando a classe acessada atravs da classe Operao, e no aparece quando a classe acessada
atravs do ndice.
Figura 3.6 - Modelo Contextual

A navegao mostrada nesse esquema a mesma do esquema de classes navegveis, porm
em maior nvel de detalhamento. Neste diagrama so visualizados os contextos em que cada
classe pode ser navegada. Na seo seguinte, mostrada a hiperbase construda para o sistema
SASHE, baseada na modelagem apresentada nesta seo.
3.3 A hiperbase construda no SASHE

No momento da construo da hiperbase, sentiu-se a necessidade de re-arranjar o modelo
navegacional construdo em OOHDM, de forma que fosse considerada a caracterstica de
contextos aninhados (MCA) implementada no SASHE.
54
O esquema apresentado na Figura 3.7 foi criado considerando-se apenas a idia de contextos
aninhados, organizando a documentao do SASHE em contextos coerentes, que orientasse a
navegao. Na figura, os retngulos representam contextos, as elipses representam documentos
textuais e a elipse irregular representa documentos grficos. As setas indicam possveis links
entre os documentos, dando uma idia do contexto a que cada link pertence. Quando a ligao
implementada por um link ultrapassa os limites de um contexto (seta pontilhada), esse link deve
ser criado no maior contexto que o contm (no caso da Figura 3.7, o contexto Documentos de
Engenharia Reversa).
'RFXPHQWRV GH (QJHQKDULD 5HYHUVD
9LVmR (VWUXWXUDO
9LVmR )XQFLRQDO
&KDPDGDV GH 3URFHGLPHQWRV
&LFOR GH 9LGD
4XDGUR GH &KDPDGDV
0RGHOR GH &LFOR GH 9LGD
QGLFH GH 3URFHGLPHQWRV
2SHUDo}HV
4XDGUR GH QGLFH
0RGHOR GH 2SHUDo}HV
2SHUDo}HV3URFHGLPHQWRV
&ODVVHV
0RGHOR GH 2EMHWRV
4XDGUR GH 2SHUDo}HV3URFHGLPHQWRV GH
,PSOHPHQWDomR
Figura 3.7 - Projeto dos contextos aninhados da hiperbase para documentar a engenharia reversa
segundo o Fusion-RE/I
Tendo organizado os contextos que seriam criados na hiperbase com os documentos de
engenharia reversa, o esquema contextual do OOHDM foi adaptado para que ficasse consistente
com os contextos criados. A Figura 3.8 apresenta um novo esquema contextual, baseado no
esquema contextual da modelagem OOHDM (Figura 3.6) e no esquema de contextos da Figura
3.7. Nessa figura, os ndices de acesso so apresentados como retngulos pontilhados, como no
OOHDM, porm os documentos ainda so mostrados como elipses para diferenciar ns
documentos de ns de contextos (retngulos). O retngulo N Inicial equivale ao ndice de
acesso principal, fornecendo links para os outros ndices.
55
'RFXPHQWRV GH (QJHQKDULD 5HYHUVD

9LVmR )XQFLRQDO
&LFOR GH 9LGD
1y ,QLFLDO
0RGHOR GH &LFOR GH 9LGD
2SHUDo}HV
QGLFH GH 2SHUDo}HV
2SHUDomR
2EMHWRV
QGLFH GH 7HPDV
9LVmR (VWUXWXUDO
2SHUDo}HV3URFHGLPHQWRV
4XDGUR GH &KDPDGDV
QGLFH GH 3URFHGLPHQWRV
3URFHGLPHQWR
,WHP GH
,PSOHPHQWDomR
Figura 3.8 - Esquema contextual adaptado aos ns de contextos criados

A Figura 3.9 mostra a interface do mdulo navegacional do estudante no SASHE,
juntamente com a janela que apresenta o ndice de acesso principal da hiperbase com os
documentos do SASHE, e a janela com o ndice de acesso s descries das operaes. Nessa
figura no so mostrados os controles de navegao atualmente disponveis no SASHE, uma vez
que esses comandos no so adequados fora do domnio de ensino. Sendo assim, na hiperbase
com os documentos de engenharia reversa toda a navegao feita atravs das ncoras criadas e
dos links estabelecidos.
A verso 1.0 do SASHE possui algumas restries de edio que precisaram ser contornadas
para que a hiperbase fosse construda de acordo com o que havia sido modelado. Como o
SASHE no estabelece links dentro do mesmo n, os modelos que eram apresentados de forma
tabular tiveram que ser desmembrados em vrios documentos individuais, possibilitando a
criao de links que direcionassem uma parte especfica do modelo, j que cada parte do modelo
passou a ser apresentada em um n. Esse desmembramento foi feito com o Modelo de
56
Operaes, com o Quadro de Chamadas, e com o Quadro de Operaes-Procedimentos de

Implementao.
Figura 3.9 - Parte do ndice principal da hiperbase juntamente com o ndice de operaes
Tambm devido ao fato do sistema no suportar a edio de tabelas, os documentos
tabulares foram descritos como um texto seqencial, conforme mostra a Figura 3.10. Nessa
figura apresentada uma das entradas da tabela que compem o Modelo OperaesProcedimentos de Implementao.
Quadro 3.1 - Parte do Modelo Operaes-Procedimentos de Implementao
Opes da Interface do tema NAVEGAO
Opes
Controles
Operaes
b_Avana_histrico
Procedimentos
To_fo_Controles.o_bu_ProximoClick(Sender: TObject);
To_fo_Principal.Apresentar_No(p_NomeDoNo: Ptochar;
ApresentarNosTerminais: integer);
57
Figura 3.10 - Item de implementao Avana Histrico

Esse modelo (Operaes-Procedimentos de Implementao) foi desmembrado em itens de
implementao, sendo que cada item corresponde a uma linha da tabela que compe o modelo.
As informaes apresentadas nos itens de implementao so exatamente as mesmas contidas na
forma tabular do modelo, conforme pode ser observado atravs do Quadro 3.1, que descreve a
entrada do modelo de Operaes-Procedimentos de Implementao representada no item de
implementao apresentado na Figura 3.10. Esse item de implementao corresponde a operao
Avana Histrico, contida na opo de interface Controles.
Para conseguir uma navegao eficiente, foi necessrio tambm a insero de novos
elementos nos textos dos documentos, a fim de que as ncoras necessrias ao estabelecimento
dos links pudessem ser criadas.
A Figura 3.11 mostra uma janela (n) contendo a descrio de uma das operaes
componente do modelo de operaes. Note-se que nesse n foi necessrio inserir trs elementos
no pertencentes ao modelo (descrio da operao) a fim de que fossem criadas as ncoras
necessrias navegao modelada no esquema contextual. Como o prprio nome sugere, a
ncora Prxima operao faz o link para um outro n contendo a descrio de outra operao. A
ncora Objeto faz o link para um n contendo o modelo de objetos no qual a classe que
implementa a operao do n atual faz parte. A ncora Implementao faz o link para um n
contendo o item de implementao que descreve os procedimentos de implementao da
operao exibida no n atual.
58
Figura 3.11 - Janela apresentando a descrio da operao Ativar Janela n

A necessidade de se criar essas ncoras em todos ns acarreta um esforo que poderia ser
poupado atravs de controles de navegao adequados para esse tipo de documento. A seguir
discutida uma forma de se resolver essa e outras questes relacionadas a adequao do SASHE
para o armazenamento e navegao de documentos de engenharia reversa.
3.5 Proposta de adequao do SASHE para

Engenharia Reversa
Conforme comentado na seo anterior, existem alguns pontos que necessitam de modificao
para que o SASHE torne-se um sistema apto construo e navegao de hiperbases contendo
documentos de engenharia reversa. Alm da mudana da nomenclatura utilizada pela interface,
algumas funes de navegao teriam de ser modificadas, pois atualmente, os controles de
navegao disponveis no SASHE so direcionados ao domnio de documentos didticos.
Dessa forma, com base na experincia adquirida durante o processo de engenharia reversa e
na insero dos documentos resultantes desse processo no SASHE, foi elaborada uma proposta
de modificao da nomenclatura utilizada na qualificao dos ns terminais e tambm de
mudana dos controles de navegao atuais.
59
Figura 3.12 - Janela do SASHE para a criao de um n terminal

Atualmente, quando um n terminal criado no SASHE, ele pode ser classificado como um
texto, uma imagem, um vdeo, um udio ou um n execuo, conforme pode ser observado na
Figura 3.12. Alm do tipo do n, outros atributos so definidos, como sua funo didtica, seu
grau de dificuldade e uma lista de palavras-chave com as quais o assunto do n se relaciona.
Tanto essa classificao quanto os atributos especificados perdem o sentido quando o domnio de
documentao deixa de ser o de ensino. No entanto, interessante que a idia de qualificao de
ns terminais permanea, pois so esses atributos que possibilitam a existncia de outros
controles de navegao alm dos tradicionais (Nunes et al., 1997b). As setas, na Figura 3.12,
indicam os campos que necessitam modificao.
Sendo assim, na Figura 3.13 apresentado um exemplo de como poderia ser a janela de
criao de ns, de modo a estabelecer atributos adequados documentao de engenharia
reversa. Os tipos de n foram reduzidos a dois: n texto e n grfico. Basicamente, um
documento de software pode ser textual ou grfico. De forma geral, outros tipos de n poderiam
ser definidos, porm essa proposta foi baseada na capacidade atual de edio do sistema SASHE.
60
Figura 3.13 - Possvel modificao de interface para a janela de criao de n

O atributo Abstrao define o nvel de abstrao do modelo pertencente ao n sendo criado.
Esse atributo permitir a navegao entre documentos com o mesmo nvel de abstrao, que
pode ser Funcional ou Estrutural.
O atributo Tipo do Modelo classifica o n como um modelo ou parte de um modelo definido
pelo Fusion-RE/I. Dessa forma, um n pode ser um Modelo de Ciclo de Vida, uma Operao
(parte do Modelo de Operaes), um Modelo de Objetos, um Item de Chamada (parte do Quadro
de Chamadas), um ndice, ou um Item de Implementao (parte do Quadro de OperaesProcedimentos de Implementao). Esses tipos de modelo so apresentados no combobox desse
atributo, de forma que no momento da criao ou edio do n basta escolher um dos tipos
disponveis. A definio dos ns com um atributo de tipo de modelo permitir a navegao entre
os mesmos tipos de modelos (por exemplo, entre operaes) sem que seja necessrio criar no n
uma ncora que faa o link para um prximo item.
O atributo Relacionamentos consiste de uma lista de ns relacionados ao n sendo criado.
Conforme mostrado na Figura 3.13, o combobox desse atributo apresentar o nome de todos os
ns da hiperbase, para que sejam escolhidos os ns que se deseja relacionar com o n sendo
criado ou editado. No listbox logo abaixo do combobox so apresentados os nomes do ns
selecionados. Esse atributo permitir a navegao entre ns de tipos diferentes, porm
relacionados, sem seja preciso se criar um ncora para se estabelecer o link desejado.
61
Tendo definidos esses atributos para os ns, elaboramos uma proposta de novos controles de
navegao, mostrados na Figura 3.14. Embora a maior parte da navegao seja feita atravs das
ncoras explicitamente definidas no contedo dos ns, esses controles viriam facilitar a
navegao e reduzir o esforo de criao de ncoras e definio de links.
Figura 3.14 - Possvel modificao dos controles de navegao

Os botes Histrico de Navegao permitiriam retroceder e avanar na lista de ns j
navegados na seo atual do SASHE. Esses controles funcionariam da mesma maneira como
esto no SASHE atual.
Os botes Itens do Modelo permitiriam a navegao entre ns pertencentes ao mesmo tipo
de modelo dentro do contexto atual. Observando o conceito de contextos aninhados (Figura 3.8),
razovel que os itens de um mesmo modelo sejam organizados em contextos, assim como
feito atualmente com ns de um mesmo assunto. Dessa forma, elimina-se a necessidade da
criao de ncoras para navegao seqencial dentro do mesmo contexto.
Os botes Modelos Funcionais e Modelos Estruturais mostrariam uma lista com os ns da
hiperbase de acordo com o atributo Abstrao. Esse ndice de modelos permitiria a navegao
dentro de um nico nvel de abstrao, sem que o usurio final da hiperbase precise ter
conhecimento de quais documentos so considerados funcionais e quais so considerados
estruturais.
O boto ndice ativaria, dentro do contexto atual, o n que tiver o atributo Tipo de Modelo
sendo ndice. Caso no exista um n ndice no contexto atual de navegao, ser ativado o ndice
principal, ou seja, do maior contexto que englobe o contexto atual.
62
Finalmente, o boto Relacionamentos acionaria uma janela contendo uma lista dos ns que
possuem relacionamento com o n atual. Esse controle de navegao possibilita que sejam
estabelecidos links entre modelos diferentes, sem a insero de novas ncoras para o
estabelecimento do link. Por exemplo, a partir de um n Operao, poder-se-ia navegar para o
Item de Implementao que lista os procedimentos que implementam a operao do n atual.
Um conceito importante para o SASHE o de roteiros de navegao, pois no domnio de
ensino, o roteiro permite que o professor limite o contexto de navegao do estudante com o
objetivo de guia-lo pela hiperbase quando este a estiver navegando. No domnio de engenharia
reversa, o conceito de roteiro deixa de ser necessrio, pois os prprios controles de navegao
propostos (Figura 3.14) j fornecem recursos que guiam o usurio pela hiperbase.
Embora seja definida uma seqncia de etapas a serem seguidas durante desenvolvimento
do processo de engenharia reversa (por exemplo, os passos propostos pelo Fusion-RE/I), aps ter
a documentao resultante inserida na hiperbase, no existe uma seqncia especificada para o
acesso aos documentos. Dessa forma, no h como delimitar o contexto de navegao da
documentao, sendo que o usurio deve ter a possibilidade de navegar em todos os contextos,
guiado pela necessidade de informao que estiver buscando.
Os atributos e controles de navegao propostos nesta seo foram baseados na experincia
adquirida durante a interao com SASHE para sua auto-documentao. Essa proposta foi
elaborada a partir de problemas encontrados na utilizao do SASHE para a manipulao de
documentos que no fossem didticos. Dessa maneira, a proposta apresentada se restringiu aos
aspectos funcionais do sistema, deixando os aspectos de implementao do sistema como
trabalho futuro.
O grande volume de documentao envolvida num processo de engenharia reversa foi um
dos motivadores para a utilizao de um sistema hipermdia neste trabalho. A realizao do
estudo de caso com o sistema SASHE comprovou a necessidade de um meio de acesso s
informaes recuperadas que fosse mais gil e eficiente. Num sistema hipermdia, alm dos links
estabelecidos
facilitarem a
manipulao
dos
documentos,
tambm
explicitam
seus
relacionamentos, orientando tanto o usurio final como o engenheiro construtor ou mantenedor

da hiperbase.
63

Neste captulo foram apresentadas as consideraes sobre como os sistemas hipermdia tm
apoiado atividades que englobam a manipulao de grandes volumes de informao que no
possuem uma estrutura seqencial para essas informaes, entre elas a engenharia de software.
Tambm foi introduzido na Seo 3.1 o sistema hipermdia SASHE, que foi o sistema alvo
para o processo de engenharia reversa e tambm foi o sistema utilizado para o armazenamento
das informaes recuperadas.
Na Seo 3.2 foi mostrado um estudo feito sobre o mtodo de modelagem de aplicaes
hipermdia OOHDM, e na Seo 3.3 foi apresentada a modelagem conceitual realizada para o
domnio de engenharia reversa, segundo o mtodo Fusion-RE/I, utilizando-se o mtodo
OOHDM.
A hiperbase construda no sistema SASHE com os documentos resultantes do processo de
engenharia reversa foi apresentada na Seo 3.4 e na seqncia, na Seo 3.5 foram propostas
modificaes ao SASHE, para que o sistema passe a ser adequado ao domnio de engenharia
reversa.
No prximo captulo mostrado um resumo dos documentos recuperados durante o
processo de engenharia reversa aplicado ao SASHE, assim como algumas mtricas registradas
durante o processo. Tambm so comentados os problemas encontrados no desenvolvimento da
engenharia reversa.
64
Captulo 4
Engenharia Reversa aplicada ao sistema

SASHE
Este captulo apresenta os produtos obtidos como resultado do processo de engenharia reversa
aplicado ao sistema SASHE. Conforme descrito na Seo 3.1, o sistema SASHE um sistema
para autoria e navegao de documentos hipermdia, cujo domnio de aplicao o ensino.
Baseado no Modelo de Contextos Aninhados (MCA) (Casanova et al., 1991), o SASHE tem
como caracterstica permitir que um autor de hiperdocumentos possa qualificar e organizar os
elementos constituintes (ns) do documento, de modo que o sistema resultante contenha funes
adicionais navegao tradicional. Tais funes incluem recursos para a localizao contextual
do leitor, bem como estratgias instrucionais dependentes dos valores dos atributos dos ns
(Nunes et al., 1997b).
Funcionalmente, puderam ser identificados uma hiperbase, um mdulo de autoria e um
mdulo de navegao. Toda a funcionalidade do sistema foi documentada atravs dos modelos
propostos pelo mtodo Fusion-RE/I para a etapa de recuperao funcional: o Modelo de Ciclo de
Vida, o Modelo de Operaes e o Modelo de Objetos (em UML). Esses modelos foram
recuperados exclusivamente atravs da interao com a interface, sem nenhuma viso do cdigofonte.
Em nvel de implementao, o sistema composto pela hiperbase, um gerenciador da
hiperbase, uma biblioteca de classes e uma interface. Na anlise do cdigo fonte do sistema
65
Captulo 4 - Engenharia Reversa aplicada ao sistema SASHE
SASHE foram manipuladas cerca de dez mil linhas de cdigo C++, que implementam o
gerenciador da hiperbase e as estruturas para o suporte do MCA, e cerca de quatro mil linhas de
cdigo Delphi, implementando a interface do sistema. A interface entre o gerenciador da
hiperbase e a interface usurio/computador se d atravs de uma DLL, a qual exporta as funes
de manipulao da hiperbase para a interface.
No total, foram analisados oitenta e quatro (84) arquivos de cdigo C++ e vinte e um (21)
arquivos de cdigo Delphi.
Na prxima seo so apresentados exemplos tirados do conjunto de documentos
recuperados atravs da aplicao do mtodo Fusion-RE/I ao sistema hipermdia SASHE. A
documentao completa encontra-se em Feltrim e Fortes (1999). Na Seo 4.2 so mostradas
algumas mtricas do processo desenvolvido e na Seo 4.3 so ento citados os problemas
enfrentados durante a realizao da engenharia reversa.
4.1 Resumo dos resultados da Engenharia Reversa

Devido ao grande volume de documentao gerada como produto do processo de engenharia
reversa, nesta seo so apresentadas apenas partes dos documentos, com o intuito de propiciar
uma viso geral dos resultados obtidos. Nas subsees 4.1.1, 4.1.2 e 4.1.3 so mostrados
documentos componentes da viso funcional, recuperados na primeira etapa do mtodo. No
restante das subsees so apresentados documentos recuperados na segunda etapa do mtodo,
que compem a viso estrutural do software.
4.1.1 Modelo de Ciclo de Vida

A partir do uso intensivo do sistema, do estudo da documentao existente e das entrevistas com
os usurios pde-se definir a seqncia de operaes permitidas e os eventos de entrada e de
sada que o sistema aceita.
O Modelo de Ciclo de Vida composto por expresses regulares que definem a seqncia
de eventos a que o sistema pode interagir durante todo o perodo que est em execuo. Ele
66
descreve o comportamento completo de como o sistema se comunica com o ambiente, desde sua
inicializao at o seu trmino (Masiero, 1995), (Penteado, 1996).
O Modelo de Ciclo de Vida construdo para o SASHE contm cerca de cinqenta e cinco
(55) sentenas compondo as seqncias de operaes permitidas no sistema, incluindo ambos os
mdulos5 que compem o software: o mdulo do Professor e o mdulo do Estudante.

b_ABRIR_HIPERBASE | b_SALVAR_HIPERBASE | b_ROTEIRO
| b_GLOSSRIO | ELOS | NS )+
NS = ( b_CRIAR_N | b_BROWSER_ESTRUTURAL | b_BROWSER_GRFICO |
SELECIONAR_N )*
Figura 4.1 - Parte inicial do Modelo de Ciclo de Vida do SASHE

A primeira sentena que aparece no ciclo de vida, exemplificada no texto apresentado na
parte inferior da Figura 4.1, descreve a tela de entrada do SASHE, onde existem apenas trs
opes: Professor (Mdulo de Autoria), Estudante (Mdulo de Navegao) e Sada.
A segunda e terceira sentenas descrevem a interface do mdulo de autoria, conforme
mostrado na Figura 4.1. Nesta figura apresentada a tela principal desse mdulo, e as sentenas
definem a seqncia de comandos possveis a partir desse ponto de interao do software.
67

b_ABRIR_HIPERBASE | b_SALVAR_HIPERBASE | b_ROTEIRO |
b_GLOSSRIO | ELOS | NS )+
NS = ( b_CRIAR_N | b_BROWSER_ESTRUTURAL | b_BROWSER_GRFICO |
SELECIONAR_N )*
HIPERBASE = ( ((Criar | ABRIR) . SALVAR) | Sair )
ABRIR = ( (Nome_do_arquivo . (Pastas | Unidades_de_disco |
Listar_arquivos_do_tipo | Som._Leitura | b_REDE |
b_AJUDA)* . (b_Ok | b_Cancelar) .
(((#msg_no__possvel_encontrar_este_arquivo...). b_Ok .
ABRIR) | ((#msg_este_nome_de_arquivo_tem_muitas_letras) .
b_Ok . ABRIR) )*) | b_Cancelar )
Figura 4.2 - Refinamento da opo Hiperbase e da operao Abrir

Para facilitar a compreenso do modelo, foi adotada uma conveno para a escrita do ciclo
de vida neste trabalho. Os nomes que aparecem em itlico no so constantes da interface do
sistema, ou seja, no aparecem de fato na interface. Esses nomes, ou so aes do usurio, como
selecionar elementos que aparecem na hiperbase, ou so recursos de abstrao para facilitar a
escrita e o entendimento do ciclo de vida. Os nomes que so precedidos de b_ aparecem na
5
O SASHE utiliza a terminologia mdulo para diferenciar os modos de interao do sistema: um para o Professor
e um para o Estudante.
68
interface como botes, ao passo que os outros so opes de menu. Quando um nome (uma
opo da interface) aparece em letras maisculas, porque existe uma sentena que descreve
com mais detalhes essa opo. Os nomes em letras minsculas so smbolos terminais, que
podem ser uma operao ou uma entrada.
A Figura 4.2 mostra um refinamento em dois nveis, pois alm da sentena refinando a
opo de menu Hiperbase, apresentado o refinamento da operao Abrir, pertencente ao
menu Hiperbase. A Figura 4.2 apresenta tambm a tela para a abertura de uma hiperbase.
Note-se que todas as entradas requeridas na interface esto descritas nas sentenas de ciclo de
vida. Na sentena que descreve especificamente a operao Abrir, existe uma chamada a
prpria operao, caracterizando uma recurso. Isso se deve ao fato da janela para a abertura de
hiperbase continuar ativa caso um erro de abertura do arquivo ocorra. Dessa forma, o usurio s
volta janela anterior quando a operao for bem sucedida ou quando for cancelada atravs do
boto Cancelar.
Abrir Hiperbase
Cliq ue do boto Abrir
Hip erbase
Clique d o boto Ok
Clique d o boto Cancelar
Janela da operao
Pasta escolhida
Entrada do no me do arquivo( arq )
Clique d o boto Ok
Cliq ue do boto Ajuda /

Clique som. leitura
Dados do arquivo preen chidos
Selecionar
diretrio de
trabalho
Selecionar
unidade de disco
Unid. de disco escolhida
E
Clique do
boto Ok
Erro
Selecion ar tip o de arquivo a

ser exibido
Clique do
boto Rede
E
Tipo de arquivo escolhid o
E
Caminho de Rede
Clique do boto Ok / Cancelar
Figura 4.3 - Diagrama de transio de estado para a operao Abrir Hiperbase
69
O mesmo procedimento de refinamento foi aplicado a todas as opes apresentadas na

interface do software, at que todas as seqncias de operaes possveis estivessem descritas no
modelo.
Para facilitar a verificao da corretitude do Modelo de Ciclo de Vida, foram construdos
Diagramas de Transio de Estado (DTE), representando cada uma das sentenas presentes no
modelo. Os DTEs foram construdos com o auxlio da ferramenta Rational Rose (Rational,
1999), segundo a notao UML. Esses diagramas propiciaram uma melhor visualizao das
seqncias de operaes descritas nas sentenas do ciclo de vida, facilitando assim sua
verificao. A Figura 4.3 mostra o DTE construdo para a operao Abrir Hiperbase.
4.1.2 Modelo de Operaes

O Modelo de Operaes decorrente do Modelo de Ciclo de Vida. Esse modelo tem como
objetivo especificar o comportamento de uma operao de forma declarativa em termos das
mudanas de estado do sistema e eventual gerao de eventos de sada (Masiero, 1995).
Conforme abordado no Captulo 2, cada operao identificada no Modelo de Ciclo de Vida
descrita individualmente atravs de um formulrio textual, descrito na Figura 2.4.
Dessa forma, o Modelo de Operaes expresso por uma srie de esquemas, sendo que
existir, no mnimo, um esquema para cada operao do sistema (Coleman et al., 1996). Foram
identificadas no ciclo de vida construdo para o sistema SASHE sessenta e duas (62) operaes,
sendo que cada uma delas foi estudada exaustivamente para que pudesse ser descrita de acordo
com os requisitos do esquema proposto pelo mtodo. Todos os esquemas juntos compem o
Modelo de Operaes.
As informaes representadas nesse modelo foram quase totalmente recuperadas a partir da
interao com o software, pois na documentao disponvel na ocasio, havia muito pouca
meno ao comportamento das operaes em si. As informaes conseguidas nas entrevistas
com os usurios do sistema foram de grande ajuda, complementando os resultados de descrio
obtidos e at mesmo orientando a interao com o software.
70
Na elaborao desse modelo foram analisadas tambm as aes do sistema que no so

visveis na interface, por serem aes internas do sistema, como criao e modificao de
arquivos, resultantes das operaes realizadas pelo usurio.
O Quadro 4.1 apresenta a descrio (um dos esquemas) feita para a operao Abrir do
menu Hiperbase.
Quadro 4.1 - Esquema descrevendo a operao Abrir do menu Hiperbase
Operao:
Abrir
Descrio:
Abre uma hiperbase j existente
L:
Nome do arquivo; diretrio; drive; somente leitura; boto ok;

boto cancelar
Modifica:
Envia:
Agente externo:{#msg no possvel encontrar este arquivo};

Agente externo:{#msg este nome de arquivo tem muitas letras}
Assume:
Resultado:
Se boto cancela, operao cancelada

Se boto ok,
Se arquivo existente, a hiperbase aberta
Se arquivo no encontrado, mensagem de arquivo no encontrado
enviada, e continua na operao Abrir hiperbase
Se nome de arquivo tem mais de 8 letras, mensagem de nome com
muitas letras enviada, e continua na operao Abrir hiperbase
4.1.3 Modelo de Objetos

Para a elaborao do Modelo de Objetos no Fusion-RE/I primeiramente definem-se os assuntos
relacionados com a funcionalidade do sistema. Esses assuntos so denominados Temas (Costa,
1997). Tendo definido os Temas, feito um agrupamento das operaes de acordo com os
Temas a que se referem. Assim, ao final tem-se uma lista de Temas e as operaes dos Temas.
Finalmente, para cada um dos Temas definidos, construdo um Modelo de Objetos.
Para que se pudesse definir os Temas foi necessria uma anlise das informaes
recuperadas na primeira etapa (Obteno de Informaes Existentes Sobre o Sistema) e tambm
das abstraes vindas dos modelos de ciclo de vida e de operaes. Essa uma das tarefas mais
subjetivas do mtodo Fusion-RE/I e de fundamental importncia para a aplicao do mtodo
(Costa, 1997). De fato, constatamos a subjetividade da definio dos Temas, o que nos levou a
vrias tentativas de possveis Temas, antes de decidirmos quais seriam os Temas definitivos do
sistema.
71
3RVVtYHLV 7HPDV SDUD R 6$6+(

3URIHVVRU
(VWXGDQWH
+LSHUEDVH
&RQWUROHV GH
1DYHJDomR
(ORV
1yV
+LSHUEDVH
1DYHJDGD
5RWHLUR
Figura 4.4 - Primeira tentativa de definio de Temas para o SASHE

Aps uma primeira tentativa de fazer o agrupamento das operaes identificadas nos Temas
propostos (Figura 4.4), percebeu-se que os Temas definidos ainda no eram adequados, pois
algumas operaes no se encaixavam em nenhum dos Temas, e alguns Temas no continham
nenhuma operao. Alm disso, os Temas definidos no evoluam para os modelos de objetos.
Sendo assim, analisando cuidadosamente as operaes e seus relacionamentos propusemos dois
Temas para o sistema: Autoria e Navegao, o que nos pareceu adequado (Figura 4.5). Foi feito
ento a agrupamento de todas as operaes identificadas no Modelo de Operaes em um dos
dois Temas.
1RYRV 7HPDV SDUD R 6$6+(

1DYHJDomR
$XWRULD
Figura 4.5 - Temas propostos para o SASHE

Aps esse agrupamento, as operaes foram novamente analisadas, buscando identificar
componentes que constitussem o Modelo de Objetos, ou seja, classes, relacionamentos,
atributos, e possveis agregaes, especializaes e generalizaes. Dessa forma foram
construdos dois modelos de objetos, um para o tema Autoria (Figura 4.6) e um para o tema
Navegao (Figura 4.7).
Para a edio dos modelos de objetos foi utilizada a ferramenta Rational Rose (Rational,
1999). Sendo que essa ferramenta suporta a modelagem em UML, os modelos de objetos j
foram construdos utilizando essa notao. Dessa forma, embora o Fusion-RE/I se baseie na
notao do mtodo Fusion, os modelos das Figuras 4.6 e 4.7 so apresentados em UML.
72
importante ressaltar que esses modelos foram propostos baseados apenas na viso
funcional do software, conseguida atravs da interao exaustiva com o software. Embora no
conste no mtodo Fusion-RE/I, espervamos que aps a recuperao das informaes estruturais
do software esses modelos de objetos sofressem algumas alteraes, para que se tornassem
consistentes com a estrutura do software, porm esperava-se que essas alteraes fossem
pequenas. De fato, os modelos de objetos sofreram modificaes razoveis em relao ao
Modelo de Objetos recuperado a partir do cdigo do sistema.
A Figura 4.8 apresenta esse modelo recuperado do cdigo fonte, retratando o Modelo de
Objetos Real, isto , o verdadeiramente implementado no sistema. Nessa modelagem no foram
considerados aspectos de interface, direcionando o foco para o sistema Hip/Windows (Nunes et
al., 1996) e o mdulo de navegao do SASHE, isto , no foram includas no modelo classes
que implementam janelas, barras de rolagem, etc. No modelo apresentado na Figura 4.8 tambm
no esto representadas dez (10) classes, utilizadas para a manipulao de som, imagem e vdeo,
e que no esto no modelo por no influenciarem a estrutura geral do sistema. As classes que
aparecem limitadas por uma linha pontilhada, fazem parte da implementao do browser grfico.
Com o trmino da recuperao do Modelo de Ciclo de Vida, do Modelo de Operaes e dos
modelos de objetos, encerra-se a primeira etapa do mtodo Fusion-RE/I, que recupera vises
funcionais do software unicamente atravs da interao com a interface do sistema. Na prxima
etapa so recuperadas informaes estruturais atravs da anlise do cdigo-fonte do software. Os
documentos resultantes dessa nova etapa so apresentados nas prximas subsees.
73

Professor
i nterage
Interface de Autori a
Janel a Ns e Elos()
Ativar j anel a n()
Rede()
Cascata()
Lado a l ado()
Fechar()
Sai r()
manipula
Hiperbase
nom e
Browser
Abri r hi perbase()
Criar hi perbase()
Sal var hiperbase()
Browser Estrutural
Explorar n()
Visual izar Browser Estrutural ()
contm
Browser Grfi co
contm
Elo
nom e
li sta de ncoras
Aj uda Hipgrafo()
Vol tar n()
Zoom i n()
Zoom out()
Visual izar Browser Grfico()
Contexto()
Criar n()
Edi tar n()
Elimi nar n da hi perbase()
Mover()
Copiar()
ori gem
destino
atri butos
Criar el o()
El iminar el o()
Al terar el o()
um
um
N Term inal
N Contexto
funo di dti ca
dificul dade
pal avras-chave
li sta de ns
l ista de elos
Abri r nova j anel a com o contexto seleci onado()
Vi sualizar contexto selecionado()
Vol tar para o contexto anterior()
Reti rar n do contexto()
um
um
Rotei ro
Edi tar contedo()

Ler arquivo()
Vi sual izar contedo do n()
Edi tar n de ajuda()
N Texto
l ista de ns l iberdade
Apagar n()
Criar roteiro()
Seleci onar ns()
Inseri r no roteiro()
Limpar roteiro()
Mudar n li berdade()
um
um
um
um
arqui vo txt
N Imagem
N Vdeo
N udio
arqui vo bm p
arquivo avi
arqui vo wav
Figura 4.6 - Modelo de Objetos para o tema Autoria
74
N Execuo
arqui vo txt

Browser Grf ico
Ajuda Hipgraf o()
Voltar n()
Zoom in()
Zoom out()
Visualizar Browser Grf ico()
Contexto()
contm
Interf ace de Controle de Nav egao

Hiperbase
navega
Estudante
nome
Estudante()
Cascata()
Lado a lado()
Ativ ar janela n()
Sair()
manipula
Abrir hiperbase()
Criar hiperbase()
Salv ar hiperbase()
contm
contm
contm
Nav egao e localizao no Histrico

Busca por atributo
lista de ns v isitados
regras de busca
Nav egao e localizao no roteiro

lista de ns do roteiro
um
Atributo Especf ico
Ajuda()
Bibliograf ia()
Exerccios()
Mais Inf ormaes()
uma
Histrico()
Av ana histrico()
Retrocede histrico()
Onde estou?()
Av ana tpico()
Retrocede tpico()
Estratgia
Est dif cil()
Est f cil()
Figura 4.7 - Modelo de Objetos para o tema Navegao
75

ancora_audio
ancora_v ideo
elo
ancora_imagem
ancora
entidade
ancora_tabela
ancoratrilha
no
ancora_executav el
ancora_contexto
composio
ancora_texto
contexto
trilha
no_terminal
contextov erses
basepriv ada
no_imagem
no_texto
no_audio
no_v ideo
contextousuario
no_exec
no_tab
lista
elemento
lista_elos
CScrollView
CGraf oView
lista_ancoras
CWinApp
CGraf oApp
tutor
hipwindow
lista_nos
CDialog
CDocument
CAboutDlg
CGrafoObj
CoordNo
Graf o
Pilha
CoordArco
Figura 4.8 - Modelo de Objetos recuperado a partir do cdigo fonte do SASHE
4.1.4 Quadro de Chamadas

Esse quadro foi elaborado para cada arquivo de cdigo fonte do sistema, apresentando os
procedimentos contidos no arquivo, suas respectivas funcionalidades e os procedimentos
utilizados (chamados) e utilizadores (chamados por).
Parte das informaes de descrio (funcionalidade) dos procedimentos foram conseguidas a
partir de comentrios no cdigo fonte. Os procedimentos chamados por cada procedimento
foram obtidos pela anlise do prprio cdigo, enquanto que os procedimentos utilizadores
(chamados por) foram obtidos atravs dos prprios Quadros de Chamadas elaborados e da
anlise do cdigo fonte.
76
A construo desse quadro de forma manual requer um esforo muito grande. Dessa
maneira, foi utilizada uma ferramenta de apoio engenharia reversa para cdigo C++, a
Understand for C/C++ (STI, 1999). Atravs de um sistema de busca eficiente proporcionado
pela ferramenta, foi possvel rastrear de forma mais gil as chamadas a procedimentos. Essa
ferramenta tambm auxilia na recuperao do Modelo de Objetos implementado, traando um
grafo de herana para cada classe do sistema.
Nesta etapa, foi necessria a recuperao do Modelo de Objetos implementado, atravs da
anlise do cdigo fonte (Figura 4.8), para a composio do Quadro de Chamadas. Essa
necessidade se deu por uma srie de fatores decorrentes do paradigma de implementao do
sistema, como herana, ponteiros dinmicos, entre outros. Esses fatores so detalhados na Seo
4.3, onde so descritas as principais dificuldades encontradas para a realizao da engenharia
reversa do SASHE.
Foram construdos setenta e nove (79) quadros para os arquivos C++ e vinte e um (21)
quadros para os arquivos Delphi, num total de 100 Quadros de Chamadas. Existem cinco (5)
arquivos C++ que no possuem Quadros de Chamadas, pois so arquivos de definio de
constantes e importao de bibliotecas, no contendo nenhum procedimento. Tambm na
instalao da verso 1.0 do SASHE so encontrados treze (13) arquivos Delphi para os quais no
foram elaborados Quadros de Chamadas. Esses treze arquivos no so de fato utilizados na
interface do SASHE, porm no foram retirados do projeto do sistema. Na nova verso 2.0 esse
problema j foi corrigido.
O Quadro 4.2 mostra um dos Quadros de Chamadas elaborados para os arquivos do sistema
SASHE, referente ao arquivo elo.cpp. Existe um quadro como este para cada arquivo de cdigo
fonte do sistema (Feltrim; Fortes, 1999). Os nmeros que aparecem no quadro entre parnteses
correspondem ao nmero da linha em que aquele cdigo se apresenta. Os nomes de arquivos que
aparecem no incio da linha de cada procedimento da seo Chamado por correspondem aos
arquivos em que cada chamada feita.
77
Quadro 4.2 - Quadro de Chamadas recuperado do arquivo elo.cpp

Sistema: SASHE
Arquivo: Hyperprop\elo.cpp
Procedimento:
(15) elo::elo(int id) :
entidade(id)
Diretrio/Arquivo: elo.cpp
Procedimento:
(23) elo::elo(int id, No *orig,
char *ani_orig, int ind_or,No
*dest, char *ani_dest, int
ind_dest, int simul, int mostr) :
entidade(id)
Procedimento:
(41) int elo::grava_elo(FILE *fp)
Procedimento:
(56) int elo::recupera_elo(FILE
*fp)
Descrio:
Construtor utilizado apenas quando o elo
carregado do arquivo
Chama:
(15) entidade(id)
Chamado por:
List_elo.cpp\ (61) int lista_elos::recupera(No
*pno,FILE *fp)
Descrio:
Construtor utilizado pela interface
Chama:
(23) entidade(id)
Chamado por:
Trilha.cpp\ (62) int trilha::insere_no(No *pno,
contexto *pno_liberdade)
Trilha.cpp\ (97) int trilha::insere_no(No *pno)
contexto *pno_liberdade, int posicao)
int posicao)
Hipger.cpp\ (1517) extern "C" int FAR PASCAL
_export cria_elo(char *nome_contexto, int id_elo,
char *origem, int anc_origem, char *destino, int
anc_destino, int simultaneo, int mostra_conteudo)
Descrio:
Grava o identificador do elo, nome do n origem,
identificador da ncora origem, nome do n
destino e o identificador da ncora destino
Chama:
(43)obtem_identificador()
(44)obtem_origem()
(44)obtem_aninhamento_origem()
(45)obtem_destino()
(45)obtem_aninhamento_destino()
Chamado por:
List_elo.cpp\ (51) int lista_elos::grava(FILE
*fp)
Descrio:
O identicador do elo foi recuperada pela lista de
elos. Recupera do arquivo o nome do n origem,
identificador da ncora origem, nome do n
destino e o identificador da ncora destino.
Chama:
(60) fscanf(fp, "\t\tOrigem(%s,\"", pnome)
(61) hb.Retorna(pnome)
(63) fscanf(fp, "%s\",", aninhamento_origem)
(64) fscanf(fp, "%d)\n", &ancora_no_origem)
(65) fscanf(fp, "\t\tDestino(%s,\"", pnome)
(66) hb.Retorna(pnome)
(68) fscanf(fp, "%s\",", aninhamento_destino)
(69) fscanf(fp, "%d)\n", &ancora_no_destino)
(70) fscanf(fp, "\t\tAtributos(%d,", &simultaneo)
(71) fscanf(fp, "%d)\n",
&mostra_conteudo_contexto)
Chamado por:
List_elo.cpp\ (61) int lista_elos::recupera(No
*pno,FILE *fp)
78
4.1.5 Quadro ndice de Procedimentos

Esse quadro apresenta todos os procedimentos da implementao do sistema em ordem
alfabtica, com as respectivas localizaes (arquivo e diretrio).
Para a elaborao desse quadro foram utilizados todos os Quadros de Chamadas obtidos
anteriormente. Esse quadro tambm pode ser gerado automaticamente por uma ferramenta de
apoio a engenharia reversa, como a j citada (STI, 1999). No caso deste trabalho
especificamente, esse quadro foi especialmente til, pois serviu como ndice de acesso aos
procedimentos na construo da hiperbase.
Parte do Quadro ndice de Procedimentos obtido para os arquivos C++ apresentada no
Quadro 4.3.
Quadro 4.3 - Parte do Quadro ndice para os procedimentos C++
Sistema:
SASHE Sistema de Autoria e Suporte Hipermdia ao Ensino

Procedimentos
ancora_audio::ancora_audio(int ind):ancora(ind)
ancora_audio::ancora_audio(int ind, int ide):ancora(ind, ide)
ancora::ancora(int Ind):entidade(Ind)
ancora::ancora(int Ind, int ide):entidade(Ind)
ancora_contexto::ancora_contexto(int ind):ancora(ind)
ancora_contexto::ancora_contexto(int ind,int ide,int
id_no):ancora(ind, ide)
ancora_contexto *contexto::contem_ancora(int id_no)
ancora_contexto *contexto::cria_ancora_contexto(int ide, int
id_no)
ancora_executavel::ancora_executavel(int ind):ancora(ind)
ancora_executavel::ancora_executavel(int ind, int
ide):ancora(ind, ide)
ancora_imagem::ancora_imagem(int ind):ancora(ind)
ancora_imagem::ancora_imagem(int ind, int ide):ancora(ind,
ide)
ancora *No::primeira_ancora()
ancora *No::proxima_ancora()
ancora *No::retorna_ancora(int ind)
ancora *No::ultima_ancora()
ancora_tabela::ancora_tabela(int ind):ancora(ind)
ancora_tabela::ancora_tabela(int ind, int ide):ancora(ind,
ide)
ancora_texto::ancora_texto(int ind):ancora(ind)
ancora_texto::~ancora_texto()
ancora_texto::ancora_texto(int ind, int ide, char *pal, int
inicio, int fim):ancora(ind, ide)
ancora_trilha::ancora_trilha(int ind):ancora(ind)
ancora_trilha::ancora_trilha(int ind,int ide):ancora(ind,
ide)
ancora_video::ancora_video(int ind):ancora(ind)
ancora_video::ancora_video(int ind, int ide):ancora(ind, ide)
79
Diretrio\Arquivo
hyperprop\anc_aud.cpp
hyperprop\anc_aud.cpp
hyperprop\ancora.cpp
hyperprop\ancora.cpp
hyperprop\anc_cont.cpp
hyperprop\anc_cont.cpp
hyperprop\contexto.cpp
hyperprop\contexto.cpp
hyperprop\anc_exec.cpp
hyperprop\anc_exec.cpp
hyperprop\anc_ima.cpp
hyperprop\anc_ima.cpp
hyperprop\No.cpp
hyperprop\No.cpp
hyperprop\No.cpp
hyperprop\No.cpp
hyperprop\anc_tab.cpp
hyperprop\anc_tab.cpp
hyperprop\anc_tex.cpp
hyperprop\anc_tri.cpp
hyperprop\anc_tri.cpp
hyperprop\anc_vid.cpp
hyperprop\anc_vid.cpp
Para facilitar o manuseio do documento, e tambm devido ao fato do software ser

implementado em duas linguagens de programao, optamos por dividir o ndice de
procedimentos em dois quadros: um para os arquivos C++ e outro para os arquivos Delphi.
4.1.6 Quadro de Operaes-Procedimentos de

Implementao
Nesse quadro esto identificados os procedimentos que implementam cada uma das operaes
disponveis na interface do SASHE. Nas primeiras colunas do quadro so colocadas as opes do
menu e as operaes de cada opo (descrio da interface). Na prxima coluna so colocados os
procedimentos que implementam cada operao, de acordo com a hierarquia de chamadas
descrita no Quadro de Chamadas.
De acordo com a definio apresentada em Costa (1997), cada um dos procedimentos deve
ser classificado, de acordo com funcionalidade, como implementao da interface ou relacionado
a um dos Temas definidos anteriormente. Isso feito atravs de colunas, sendo uma para a
interface e uma para cada tema definido.
Tambm em Costa (1997), citado que o nvel de detalhamento das chamadas de
procedimentos, descritos nesse quadro, depende do objetivo do processo de engenharia reversa
em realizao.
No caso deste trabalho, a documentao recuperada ser utilizada na re-engenharia do
sistema para mudana do domnio de aplicao. Como o foco principal dessa re-engenharia se
concentra na interface do sistema, o Quadro de Operaes-Procedimentos de Implementao est
detalhado at o nvel das chamadas das operaes exportadas pela DLL. Outro fato que, devido
natureza do software (mdulos distintos) e dos Temas definidos, os quadros puderam ser
separados por Temas (um quadro para o tema Autoria e um quadro para o tema Navegao),
proporcionando tambm uma melhor visualizao.
Sendo que os quadros esto separados por Temas, e esto detalhados apenas os
procedimentos de implementao da interface, com exceo das chamadas a DLL, as referidas
colunas de classificao foram excludas. O Quadro 4.4 apresenta parte do Quadro de
Operaes-Procedimentos de Implementao recuperado, mostrando operaes do tema Autoria.
80
Quadro 4.4 - Parte do Quadro de Operaes-Procedimentos de Implementao

Opes da Interface para o tema AUTORIA
Opes
Hiperbase
Operaes
Procedimentos
Criar
To_fo_Principal.o_bu_CriarHiperbaseClick(Sender: TObject);
To_fo_Principal.Ler_DLL;
extern "C" int FAR PASCAL _export cria_base_privada(char *nome);
Abrir
To_fo_Principal.o_bu_AbrirHiperbaseClick(Sender: TObject);
To_fo_Principal.Ler_DLL;
extern "C" int FAR PASCAL _export recuperar(char *nome);
Salvar
To_fo_Principal.o_bu_GravarHiperbaseClick(Sender: TObject);
extern "C" int FAR PASCAL _export salvar(char *nome);
Sair
To_fo_Principal.o_mn_SairClick(Sender: TObject);
To_fo_Principal.FormCloseQuery(Sender: TObject; var CanClose:
Boolean);
Janelas
Lado_a_lado
...
4.2 Mtricas do processo de Engenharia Reversa

realizado
Durante o andamento da engenharia reversa foram registradas algumas medidas sobre o processo
em desenvolvimento e sobre os produtos gerados, com o intuito de dar uma noo do esforo
requerido e de revelar informaes implcitas documentao.
O Quadro 4.5 apresenta um resumo de toda a documentao recuperada em totais de
elementos por documento, dimensionando cada um dos documentos recuperados. Tambm
mostrada a medida do esforo de tempo dedicado recuperao.
Quadro 4.5 - Resumo dos produtos obtidos, em totais
Modelos
Modelo de Operaes
Modelo de Objetos
Totais
55 sentenas
62 operaes
2 modelos (24 classes no total)
Esforo de tempo para recuperao funcional: 2 meses
Quadros
Totais
Quadro de Chamadas de Procedimentos
84 arquivos/ 722
21arquivos/ 165
procedimentos C++
procedimentos Delphi
Quadro de ndice de Procedimentos
887 entradas
Quadro de Operaes-Procedimentos de
2 quadros (Autoria e Navegao) com procedimentos
Implementao
de implementao da interface e chamadas Dll
Esforo de tempo para recuperao estrutural: 2 meses e meio
81
A documentao funcional recuperada do SASHE composta por um Modelo de Ciclo de

Vida com cinqenta e cinco (55) sentenas, um Modelo de Operaes composto por sessenta e
duas (62) operaes e dois modelos de objetos, um para cada tema proposto. O nmero elevado
de sentenas do Modelo de Ciclo de Vida um indicativo da grande interatividade do software e
dos muitos estilos de interface (menus, botes, mltiplas janelas) implementados no sistema.
Com o trmino da recuperao do Modelo de Ciclo de Vida, do Modelo de Operaes e dos
modelos de objetos, encerra-se a primeira etapa do mtodo Fusion-RE/I, que recupera vises
funcionais do software unicamente atravs da interao com as informaes sobre o sistema e
sua interface. A concluso dessa etapa do mtodo deu-se ao final de cerca de dois meses,
considerando-se uma dedicao de oito (8) horas/dia para uma (1) pessoa.
A segunda etapa, de recuperao de informaes estruturais atravs da anlise do cdigo
fonte do software, caracterizou o sistema SASHE com cerca de dez mil linhas de cdigo C++,
implementando o gerenciador da hiperbase (71,5% do cdigo), e cerca de quatro mil linhas de
cdigo Delphi, implementando a interface do sistema (28,5% do cdigo).
Todos os Quadros de Chamadas definidos para os arquivos de cdigo C++ totalizaram
setecentos e vinte e dois (722) procedimentos registrados, incluindo prottipos e funes
implementadas, sendo que para cento e setenta (170) procedimentos (23,5%) no foram
encontradas chamadas que os ativassem. Esse alto nmero de procedimentos inativos deve-se ao
fato de que alguns objetos implementam mtodos que no so utilizados pelo sistema, no
entanto, complementam o conceito representado pelo objeto. Tambm existem procedimentos
implementados em verses anteriores que, mesmo deixando de serem utilizados na verso
analisada, no foram retirados do cdigo pelos mantenedores. No total, foram analisadas
quarenta e sete (47) classes, quinhentas e vinte e nove (529) funes (descartando-se os
prottipos), codificadas em oitenta e quatro (84) arquivos de cdigo C++.
Quanto aos procedimentos em Delphi, foram analisados, no total, cento e sessenta e cinco
(165) procedimentos, codificados em vinte e um (21) arquivos. Grande parte dos procedimentos
analisados no apresentou nenhuma chamada no cdigo. Devido ao paradigma da linguagem,
orientada a eventos, j era esperado que fossem encontradas poucas chamadas aos procedimentos
implementados em Delphi.
Como resultado, constatamos que aproximadamente 19,1% do cdigo total do SASHE
inativo, ou seja, no chamado em nenhum momento.
82
Grande parte do trabalho concentrou-se no cdigo C++, por ser a parte em que est
implementada a hiperbase, sob o modelo MCA (Casanova et. al., 1991). A construo do Quadro
de Chamadas demandou cerca de um ms e meio de trabalho apenas para os arquivos C++. Parte
dessa tarefa foi auxiliada pelo uso da ferramenta Understand for C/C++ (STI, 1999), da qual foi
utilizada uma cpia demo, disponvel via Internet. Cerca de dez dias foi o tempo despendido na
anlise e construo dos Quadros de Chamadas dos arquivos Delphi. Foram necessrios
aproximadamente cinco dias para a construo do Quadro ndice de Procedimentos, incluindo os
procedimentos em C++ e Delphi. Finalmente, a elaborao do Quadro de OperaesProcedimentos de Implementao demandou trs semanas de trabalho para a sua concluso.
Assim, podemos resumir o esforo de recuperao, conforme mostrado no Quadro 4.5, em
aproximadamente dois meses para a viso funcional (modelos) e 2 meses e meio para a viso
estrutural (quadros).
4.3 Problemas encontrados na realizao da

Engenharia Reversa
Por tratar-se de um sistema desenvolvido como prottipo em um projeto anterior (Soares et al.,
1995), o SASHE apresenta diversos problemas, os quais nos levou a encontrar algumas
dificuldades no processo de engenharia reversa. Conforme j foi mencionado, toda
documentao relacionada ao desenvolvimento do sistema encontrava-se em dois relatrios
tcnicos (Nunes et al., 1996), (Nunes et al., 1997b), sendo que nenhum deles constitui um
manual do usurio. Dessa forma, grande parte da informao sobre a funcionalidade do sistema
foi conseguida atravs da interao exaustiva com o mesmo, e com vrias entrevistas com alguns
usurios, j que no havia uma descrio da mesma.
Outro problema que acarretou um certo atraso na realizao das atividades que exigiam
interao com a interface do sistema foi a sua instabilidade. Por tratar-se de um prottipo, muitas
das funes continham problemas de execuo, e tambm algumas inconsistncias foram
encontradas. Sendo assim, para determinar o resultado de uma funo, a mesma tinha que ser
executada vrias vezes, pois nem sempre apresentava o mesmo comportamento. Tambm devido
a essa instabilidade, tornou-se muito trabalhosa a elaborao dos documentos com as
83
informaes recuperadas no prprio SASHE, pois a cada erro corria-se o risco de perder essas
informaes. Assim optamos por elaborar os modelos e quadros em outras ferramentas de apoio
e depois montar o hiperdocumento no sistema SASHE. De fato, essa foi uma das maiores
dificuldades encontradas.
Tambm na anlise do cdigo encontramos dificuldades devido ao fato do software ter sido
desenvolvido em duas linguagens diferentes, e por no existir comentrios descritivos em grande
parte desse cdigo. Assim, sem informaes que nos orientasse, o cdigo tornou-se um
emaranhado de comandos a serem desvendados. Esse fato fez com que a tarefa de descrio
dos procedimentos fosse demorada e bastante custosa (concentrao e lgica de raciocnio).
As prprias caractersticas do cdigo OO foi outro fator que acarretou dificuldade
engenharia reversa. A aplicao de alguns dos conceitos da orientao a objetos traz certas
dificuldades leitura do cdigo, que no so encontradas na manipulao de um cdigo
procedimental.
Pelo cdigo ser orientado a objetos, as chamadas aos procedimentos nem sempre so
explcitas, sendo feitas atravs de troca de mensagens. Isso proporciona uma dinmica ao cdigo
em execuo que dificulta o rastreamento das chamadas. Dessa forma, embora com o auxlio de
uma ferramenta de suporte a engenharia reversa, a Understand for C/C++ (STI, 1999), o
rastreamento dos ponteiros dinmicos foi feito manualmente, para que cada chamada de
procedimento fosse corretamente localizada. De fato, a falta de ferramentas que manipulassem o
cdigo-fonte de modo a auxiliar efetivamente a recuperao de informaes durante todo o
processo de engenharia reversa tambm foi um problema enfrentado neste trabalho.
Outro fator que influencia na identificao das chamadas o fato de objetos diferentes
conterem mtodos com cdigo diferente e com o mesmo prottipo (mesmo nome, mesmos
parmetros). Devido a essa caracterstica, preciso identificar o tipo do ponteiro que est
referenciando o mtodo, para se identificar a qual objeto pertence o mtodo ativado. Alm disso,
existem os mtodos virtuais, que para se identificar a sua chamada, preciso saber o contexto
(escopo) da chamada, em tempo de execuo.
A utilizao de mtodos por herana tambm acarreta um trabalho extra ao rastreamento da
chamada. Principalmente por se ter o conceito de herana, que precisamos do Modelo de
Objetos Real para a construo do Quadro de Chamadas. Somente tendo o conhecimento desse
modelo, torna-se possvel rastrear um mtodo que est sendo utilizado por herana. De fato, se
84
por um lado a herana poupa o trabalho do implementador, a possibilidade dos nveis de

aninhamento de herana so esconderijos que tornam o entendimento do cdigo problemtico
para determinados tipos de manuteno.
Conforme foi descrito nesta subseo, foram encontradas vrias dificuldades na realizao
da engenharia reversa do sistema SASHE, tanto na etapa de recuperao da viso funcional
quanto na recuperao da viso estrutural, devido a complexidade e volume inerentes do sistema,
bem como pelo nvel de detalhes exigido pelos documentos do Fusion-RE/I. Porm, essas
dificuldades puderam ser transpostas, de forma que o processo de engenharia reversa pde ser
concludo com sucesso.

Neste captulo foram apresentados os resultados do processo de engenharia reversa
desenvolvido, tendo como o alvo recuperar informaes estruturais e de anlise do sistema
SASHE.
Nas subsees da Seo 4.1 foram apresentados detalhadamente cada um dos produtos
gerados como resultado da engenharia reversa, sendo que algumas medidas dos produtos e do
esforo requerido para a concluso do processo foram apresentados na Seo 4.2.
Finalmente, na Seo 4.3 foram descritas as dificuldades encontradas durante o processo de
engenharia reversa, dificuldades essas devidas tanto a instabilidade do sistema, pois trata-se de
um prottipo, como a falta de documentao para o incio do processo, a falta de ferramentas
adequadas, e at mesmo as caractersticas inerentes do cdigo OO.
No prximo captulo apresentada uma avaliao geral do mtodo de engenharia reversa
utilizado, o Fusion-RE/I.
85
86
Captulo 5
Avaliao geral do Fusion-RE/I

Este captulo tem por objetivo apresentar a avaliao do mtodo Fusion-RE/I, baseada no estudo
de caso realizado com o sistema SASHE. So comentados pontos positivos e pontos crticos
encontrados na aplicao do mtodo, bem como aspectos de validao. Finalmente,
apresentada uma nova proposta, adequando o Fusion-RE/I a sistemas originalmente
implementados sob o paradigma OO.
5.1 Discusso dos pontos positivos e crticos da

aplicao do mtodo Fusion-RE/I
O Fusion-RE/I (Costa, 1997) um mtodo de engenharia reversa que prope o incio do
processo pela interao com a interface do software para a recuperao de informaes sobre a
sua funcionalidade, e posteriormente, em uma segunda etapa, iniciar a recuperao de
informaes estruturais. Seu objetivo recuperar a documentao de anlise orientada a objetos
de um software implementado sob o paradigma procedimental. Dessa forma, pode ser aplicado
para a migrao de paradigma do sistema (procedimental para OO) (Figura 5.1), assim como o
Fusion-RE (Penteado, 1996). Uma das diferenas entre o Fusion-RE e o Fusion-RE/I est na
ordem de recuperao das vises. O Fusion-RE inicia o processo pela recuperao estrutural,
enquanto o Fusion-RE/I recupera a viso funcional inicialmente.
87
Captulo 5 - Avaliao geral do Fusion-RE/I
Como mencionado no Captulo 2, o mtodo Fusion-RE/I foi desenvolvido a partir do

mtodo Fusion-RE, herdando, dessa forma, a base desse mtodo. Entretanto, durante o
andamento do processo de engenharia reversa, constatou-se que a recuperao dos modelos de
anlise, que descrevem a funcionalidade do sistema, poderia ser facilitada atravs de uma
manipulao mais intensiva da interface do software. De fato, nas aplicaes anteriores do
mtodo Fusion-RE/I (Costa, 1997) (Quinaia, 1998), ficou evidenciado que os Modelos de Ciclo
de Vida e de Operaes podem ser totalmente recuperados sem que haja nenhuma manipulao
de cdigo. Entretanto, a recuperao do Modelo de Objetos atravs da manipulao da interface
pode ser vlida ou no, conforme discutido adiante.
Como o objetivo da engenharia reversa proposta pelo Fusion-RE/I a migrao de
paradigma de projeto e implementao procedimental para orientao a objetos, o mtodo
Fusion-RE/I proporciona um bom ganho. Uma vez que a etapa inicial do mtodo a recuperao
do modelo de anlise, atravs da interao exaustiva com a interface, pode-se garantir que o
engenheiro de software envolvido na engenharia reversa ter uma viso completa da
funcionalidade do software, sem que o mesmo tenha sido influenciado pelos aspectos da
implementao, pois at o trmino dessa etapa, o engenheiro no tem contato com o cdigo fonte
do software, tarefa esta que s realizada aps o trmino da etapa de recuperao da viso
funcional.
Dessa forma, garante-se que o modelo recuperado no novo paradigma (OO) contm uma
proposta nova, baseada na viso da funcionalidade do sistema, sem contaminao do cdigo.
Classe
Fusion-RE/I
Figura 5.1 - Aplicao do Fusion-RE/I a sistemas procedimentais

Outra vantagem que se obtm com a aplicao do Fusion-RE/I um ganho de familiaridade
com o domnio do sistema j no incio do processo de engenharia reversa. Como premissa do
Fusion-RE/I, para que o engenheiro de software possa recuperar os modelos de anlise de um
sistema, preciso antes reunir informaes sobre o mesmo. A documentao existente, a
linguagem de implementao, os dados obtidos por meio de entrevistas com os usurios e o
domnio do sistema so fontes de informao valiosas (Biggerstaff, 1989). Dentre esses, o
domnio do sistema, por ser um aspecto bastante relacionado s informaes do mundo real e
88
que so representadas de uma forma abstrata no sistema implementado, merece ateno

diferenciada.
Domnio do sistema pode ser entendido como a rea de conhecimento a qual um sistema
pertence, que pode variar muito. Certamente, o domnio exerce influncia no levantamento de
informaes sobre um determinado sistema. Uma vez que o engenheiro de software possui
conhecimento (familiaridade) sobre o domnio ao qual o sistema pertence, maior a chance
desse sistema ser melhor entendido (Adelson; Soloway, 1985). E conseqentemente, maior a
chance de se obter uma melhor anlise do mesmo.
Dessa mesma forma, sempre que o engenheiro de software possui familiaridade com o
domnio do sistema, de se esperar que isso influencie positivamente na construo do modelo
mental desse sistema. O modelo mental permite ao engenheiro de software escolher um caminho
particular de pensamento sobre um problema e gerar uma representao deste problema. Quanto
mais familiar for o domnio ao engenheiro de software, uma melhor representao do sistema
feita e menos erros surgiro posteriormente (Adelson; Soloway, 1985).
Pesquisas j indicaram que a experincia e a familiaridade do engenheiro em um domnio de
software influem diretamente nas etapas do ciclo de vida do software (Adelson; Soloway, 1985),
(Greenbaum; Kyng, 1991). Sob a perspectiva da engenharia reversa, DeBaud et al. (1994)
realizaram estudos de caso em que descrevem como o conhecimento do domnio pode auxiliar
um processo de engenharia reversa e como a engenharia reversa pode ser usada para construir
um modelo melhor do domnio de uma aplicao.
Pode-se dizer que, quando um sistema pertence a um determinado domnio, a sua interface
um dos elementos que melhor evidencia esse domnio. H muito a interface deixou de ser apenas
mais um elemento do sistema; atravs dela que se d o conjunto de processos, dilogos e aes
entre o usurio e o computador, de forma a resultar em mecanismos objetivos para se obter a
funcionalidade desejada.
No Fusion-RE/I, interao com a interface ponto inicial do processo de engenharia reversa.
Uma interao exaustiva com a interface realizada, tornando o engenheiro de software
conhecedor das funcionalidades e caractersticas operacionais do sistema. Dessa forma, o
Fusion-RE/I possibilita um ganho efetivo de familiaridade com o domnio.
Quanto recuperao dos modelos de anlise, embora se trate de uma tarefa ligada
manipulao do sistema, por meio da sua interface, de forma bastante intensiva, sendo dessa
89
forma uma tarefa concreta, exigido um grande esforo de ateno e concentrao por parte
do engenheiro de software (ou mantenedor), ao investigar quase que exaustivamente todos os
estados da interface do sistema.
Os Modelos de Ciclo de Vida e de Operaes, mesmo exigindo um grande esforo para sua
obteno, fornecem um conhecimento completo da funcionalidade do sistema, revelando as
seqncias de comandos permitidas e a descrio das operaes do sistema de forma clara e
objetiva.
Esses foram alguns pontos positivos que puderam ser evidenciados durante o
desenvolvimento do processo. Entretanto, neste trabalho, o Fusion-RE/I foi aplicado a um
sistema implementado sob o paradigma de orientao a objetos, o sistema SASHE. O
desenvolvimento do processo de engenharia reversa em um sistema com essa caracterstica nos
permitiu algumas concluses sobre o mtodo que no haviam sido abordadas anteriormente.
Os estudos de caso anteriores realizados com o Fusion-RE/I (Costa, 1997), (Quinaia, 1998)
foram aplicados a sistemas originalmente no orientados a objetos, e com um estilo de interface
diferente do utilizado no SASHE. As informaes sobre os estudos de caso realizados com o
mtodo so apresentadas no Quadro 5.1. O fato do sistema SASHE ser orientado a objetos, nos
permitiu analisar uma srie de outros fatores, que so discutidos a seguir.
Quadro 5.1 - Informaes sobre os estudos de caso realizados com o Fusion-RE/I
Documentao Funcional Gerada
Sistema
Domnio
Paradigma
de
programao
Linguagem
No de
linhas de
cdigo
Plataforma
No de
sentenas
do ciclo de
vida
No de
operaes do
modelo de
operaes
No de
modelos de
objetos
SASHE
Autoria e suporte
hipermdia ao
ensino
Orientao a
objetos
C++ e
Delphi
14.000
PC/
Windows
55
62
SAPES
(Quinaia,
1998)
Apoio pesquisa
cientfica
Orientado a
funo
Clipper
4.000
PC/ Dos
46
17
Proteum
V1. 1 C
(Costa,
1997)
Teste de software
Orientado a
funo
C e X-View
27.000
Estaes
SUN/ Unix
No
disponvel
No disponvel
A abstrao conseguida sem influncia do cdigo fonte deixa de ser vantajosa quando o
objetivo da engenharia reversa no mais a recuperao de projeto para a mudana de
paradigma, e passa a existir a necessidade de se recuperar o projeto exatamente como est. Em
90
sistemas cujo cdigo no esteja sob o paradigma OO, faz sentido construir uma abstrao do
mesmo, na forma de Modelos de Objetos, atravs da anlise de suas funcionalidades e do seu
domnio de atuao, sem que o cdigo implementado interfira na modelagem. Entretanto,
quando o software est implementado sob o paradigma OO, a estrutura do Modelo de Objetos j
existe e est instanciada no cdigo do software. Assim, a construo de um Modelo de Objetos
baseado somente nas vises funcionais do sistema deixa de ser vlida. Seguindo-se os passos
prescritos pelo Fusion-RE/I, aps ter recuperado os modelos funcionais, preciso construir um
novo Modelo de Objetos, que realmente reflita a implementao, pois para que a recuperao do
Quadro de Chamadas seja feita, necessrio o Modelo de Objetos realmente implementado.
Sendo assim, um novo esforo de recuperao do Modelo de Objetos requerido.
A recuperao do Modelo de Objetos, sem dvida, uma tarefa fundamental na
documentao do software, no entanto, para sistemas orientados a objetos, a realizao dessa
tarefa nos parece mais adequada em outra etapa do processo de engenharia reversa. De fato, na
experincia com o SASHE, ao se iniciar a segunda etapa, o Modelo de Objetos teve que ser
ajustado s classes implementadas. Um ponto a ser ressaltado que o ganho proporcionado pela
interao com a interface, para a recuperao dos Modelos de Ciclo de Vida e de Operaes,
permanece, independente da ordem em que essas tarefas de recuperao sejam realizadas.
Quadro 5.2 - Vantagens e desvantagens do Fusion-RE/I aplicado a sistemas OO
Incio do Processo de Engenharia Reversa pela Recuperao da Viso Funcional
Vantagens
Desvantagens
Ganho de familiaridade com o domnio da aplicao logo A diviso das funcionalidades em temas pode influenciar a
no incio do processo.
abstrao do Modelo de Objetos de forma errnea.
Na leitura do cdigo fonte existe um conhecimento prvio
O Modelo de Objetos pode ter que ser recuperado

novamente, a partir do cdigo, para o prosseguimento do
processo.
da funcionalidade que est implementada.
A recuperao dos modelos de anlise atravs da interface Perde-se tempo abstraindo um Modelo de Objetos que
mais facilitada do que pelo cdigo fonte, pois o nvel de
abstrao das interaes mais alto.
posteriormente poder ser descartado.
Um ponto crtico evidenciado durante a aplicao do mtodo foi a recuperao do Modelo

de Objetos, o que nos levou a considerar algumas questes. Uma primeira questo que pde ser
discutida foi a validade da inverso na ordem das etapas de recuperao proposta pelo FusionRE/I, isto , o incio do processo de engenharia reversa pela recuperao da viso funcional do
91
sistema atravs da interface, sem interao com o cdigo fonte. Algumas vantagens inerentes a
esta caracterstica do mtodo permanecem na sua aplicao a sistemas OO. Porm, a mesma
caracterstica acarreta alguns problemas a serem discutidos (Quadro 5.2).
Uma outra questo a diviso das funcionalidades do sistema em Temas. Os Temas
foram uma abstrao do sistema particionada pelo agrupamento da funcionalidade em
assuntos semelhantes. No caso de um sistema OO, muito provvel que esse particionamento
no exista no modelo implementado. Dessa forma, o engenheiro de software induzido a
recuperar uma abstrao que no estar de acordo com a implementao.
Na verdade, bastante discutvel a validade da definio de Temas quando a engenharia
reversa aplicada a sistemas OO. A partir do momento que o Modelo de Objetos deixa de ser
uma abstrao criada a partir das vises funcionais do software e passa a registrar a sua estrutura
real, a definio de Temas perde o significado. Nesse caso, pode-se discutir a utilidade dos temas
tambm para sistemas OO, mas no da maneira como originalmente proposto pelo FusionRE/I. Uma possvel aplicao da definio de Temas seria a sua utilizao para a organizao do
Modelo de Objetos extrado do cdigo. Sistemas maiores podem exigir que a estrutura
recuperada do cdigo seja dividida em vrios Modelos de Objetos. No entanto, nesse caso, os
Temas deveriam se adequar implementao, j que o modelo implementado no pode ser
mudado para se adequar aos Temas propostos de acordo com as funcionalidades observadas.
Dessa forma, os temas teriam a mesma funo de agrupamento, como proposto no Fusion-RE/I,
porm em um outro nvel de abstrao. Nessa nova proposta, os temas seriam ento definidos
visando o agrupamento de classes e relacionamentos que implementam um determinado aspecto
(assunto) do sistema.
As tarefas para recuperao de vises estruturais, segunda etapa do mtodo Fusion-RE/I,
foram adequadas, porm bastante trabalhosas, como pde ser verificado atravs dos nmeros
apresentados no Captulo 4. Foi constatado que parte dessas tarefas podem ser automatizadas
com sucesso.
De acordo com o Fusion-RE/I, a primeira tarefa de recuperao estrutural a elaborao do
Quadro de Chamadas. Parte da elaborao desse quadro foi feita automaticamente, com o auxilio
da ferramenta Understand for C/C++ (STI, 1999), conforme descrito no Captulo 4. No entanto,
a descrio dos procedimentos teve que ser feita manualmente, o que demandou muito trabalho
para sua concluso. A informao descrita nesse quadro bastante significativa, pois atravs dele
92
possvel rastrear a execuo de cada procedimento, do momento em que chamado (Chamado

por) aos procedimentos que so disparados no corpo do procedimento (Chama). Alm disso, o
entendimento da funcionalidade de cada procedimento apresentado no item Descrio.
Quanto ao Quadro de ndice, a sua gerao pode ser totalmente automatizada, j que esse
quadro uma lista de todos os procedimentos e suas respectivas localizaes (arquivo/diretrio).
Neste trabalho, esse quadro se torna especialmente til, pois ser usado na construo de uma
pgina ndice da hiperbase contendo links para acesso aos procedimentos de outro quadro.
O Quadro de Operaes-Procedimentos de Implementao encerra a documentao
estrutural recuperada segundo o mtodo Fusion-RE/I. Esse quadro complementa as informaes
apresentadas no Quadro de Chamadas, associando a cada operao identificada na interface os
procedimentos responsveis por sua implementao. Um ponto positivo do mtodo a
flexibilidade de se detalhar os procedimentos relacionados a cada operao num nvel de
profundidade que esteja de acordo com o objetivo final da engenharia reversa, como foi
exemplificado no Captulo 4.
Um ponto a se discutir na elaborao desse quadro (Etapa2-b do Quadro 2.6) a
classificao dos procedimentos em um dos temas definidos na primeira etapa do mtodo, ou
como uma implementao da interface. Novamente entramos na questo da validade da
elaborao de temas para sistemas orientados a objetos. No caso de sistemas implementados sob
outros paradigmas, a classificao dos procedimentos nos temas definidos importante para que
se possa ter uma idia de onde (em qual classe) cada procedimento ficaria melhor implementado.
Isso seria especialmente til no caso de uma re-engenharia para mudana de paradigma
(procedimental para OO). Uma vez que o cdigo orientado a objetos, essa classificao deixa
de ser necessria, pois cada procedimento j implementado como mtodo de uma determinada
classe, permanecendo vlida apenas a classificao dos procedimentos que implementam as
interaes da interface relativas a cada operao.
Tendo terminado o processo de engenharia reversa, conclumos que o Fusion-RE/I no
recupera informaes de projeto orientado a objetos, uma vez que as informaes estruturais
recuperadas atravs do mtodo no so suficientes para a construo dos modelos que
constituem o projeto de um software OO. Seguindo-se os passos propostos pelo Fusion-RE/I,
recupera-se o modelo de anlise do sistema, segundo o mtodo Fusion, e importantes
informaes estruturais, como o Quadro de Chamadas de Procedimentos e o Quadro de
93
Operaes - Procedimentos de Implementao. Porm, no so recuperadas informaes que

fazem parte do projeto OO, como grafo de herana e grafo de visibilidade entre os objetos. Ou
seja, caractersticas de projeto inerentes orientao a objetos no so abordadas pelo mtodo
Fusion-RE/I.
ClassA
Fusion-RE/I
ClassA
ClassB
ClassA
b: ClassB
Figura 5.2 - Aplicao do Fusion-RE/I a sistemas orientados a objetos

Sendo assim, podemos dizer que, para sistemas OO, o Fusion-RE/I um mtodo que
possibilita o entendimento e a documentao funcional (OO), e o rastreamento do cdigo do
sistema. Porm, essas informaes estruturais recuperadas no constituem a documentao de
projeto OO do sistema (Figura 5.2).
O diferencial do Fusion-RE/I est na proposta de etapas bem definidas para que o
engenheiro de software seja capaz de extrair o modelo de anlise do sistema (segundo o mtodo
Fusion) sem ter que manipular, em qualquer momento da extrao do modelo, o cdigo fonte do
mesmo. Dependendo do objetivo da engenharia reversa, esta caracterstica do mtodo pode ser
desejvel ou no.
No estudo de caso desenvolvido por Quinaia (1998), o objetivo era recuperar apenas a
funcionalidade do sistema, pois o cdigo fonte seria todo descartado, a fim de implementar o
mesmo sistema sob outro paradigma. Nesse caso, as etapas propostas pelo mtodo foram
suficientes, sendo que foi realizada apenas a etapa de recuperao da viso funcional. A
aplicao do Fusion-RE/I, nesse caso, proporcionou ao engenheiro um ganho de tempo e
esforo, j que foi feita a modelagem de toda a funcionalidade sem nenhuma interao com o
cdigo fonte do sistema. Esse um ponto positivo que ser vlido sempre que o cdigo fonte for
desconhecido pelo engenheiro de software e/ou no existir a necessidade de documentao
estrutural, seja o sistema alvo procedimental ou OO. Assim, podemos dizer que, nas condies
descritas acima, o mtodo aplicvel e vantajoso.
No estudo de caso realizado com o SASHE neste trabalho, foram encontrados alguns
problemas na aplicao do Fusion-RE/I, uma vez que era objetivo do processo de engenharia
reversa no s a recuperao da modelagem funcional, como tambm a modelagem estrutural do
94
sistema. A recuperao da estrutura do software era necessria, j que o SASHE no seria reimplementado, e o objetivo era documentar o software para auxiliar em futuras manutenes.
Nesse ponto surgiram dificuldades, especialmente relacionadas ao fato do SASHE ser um
software OO e do mtodo Fusion-RE/I no estabelecer etapas para a recuperao de projeto OO
(Figura 5.2).
Dessa forma, podemos concluir que algumas premissas do mtodo Fusion-RE/I devem ser
reavaliadas, de acordo com o objetivo do processo de engenharia reversa que se pretende
realizar, antes de se iniciar a engenharia reversa. Alguns fatores determinantes para o sucesso da
aplicao do mtodo e que devem ser avaliados antes do incio do processo so:
nvel de documentao que se espera recuperar (funcional/estrutural);
paradigma de implementao do sistema atual;
desejo de se reutilizar o cdigo fonte original;
nvel de conhecimento do engenheiro de software sobre o sistema alvo do processo.
Esclarecidos esses pontos, pode-se traar um plano para a aplicao do mtodo,

determinando possveis aes a serem realizadas, como:
quantas etapas do mtodo sero necessrias para se alcanar o objetivo estabelecido para
o processo;
reorganizao das etapas propostas pelo mtodo, caso necessrio, de acordo com a
necessidade de detalhamento da documentao estrutural; (necessidade do Modelo de
Objetos recuperado da estrutura, necessidade da definio de temas, necessidade da
classificao em temas no Quadro Operaes-Procedimentos de Implementao)
avaliao do custo-benefcio da aplicao do mtodo, caso o engenheiro esteja

familiarizado com o cdigo fonte do sistema alvo.
Todos esses fatores devem ser levados em conta, antes do incio da aplicao do mtodo de
engenharia reversa propriamente dito, para que se possa garantir um processo eficiente e
resultados consistentes com os objetivos traados.
95
5.2 Validao dos Resultados obtidos com o FusionRE/I

Como mencionado anteriormente, no incio do processo de engenharia reversa no existia quase
nenhuma documentao de anlise e projeto do sistema SASHE, sendo que as informaes
existentes esto em dois relatrios tcnicos (Nunes et al., 1996), (Nunes et al., 1997b). Em Nunes
et al. (1996) mostrada uma pretensa arquitetura em camadas para o sistema SASHE (Figura
5.3a), assim como uma breve descrio das funcionalidades inicialmente desejveis para o
sistema. Tambm nesse relatrio apresentada uma viso geral da mquina HIP (Figura 5.3b),
componente do sistema SASHE. Em Nunes et al. (1997b) feita uma apresentao da interface
do sistema e de suas principais funcionalidades. No entanto, em nenhum momento apresentada
uma modelagem do sistema.
Figura 5.3a - O ambiente SASHE proposto

(Nunes et al., 1996)
Figura 5.3b - Arquitetura bsica do Hip

(Nunes et al., 1996)
A Figura 5.3a mostra a proposta feita inicialmente para o sistema SASHE. Nessa proposta, o
Autor, que no precisa ser necessariamente o professor, seria o construtor da hiperbase de fato,
ou seja, agruparia todos os documentos desejados dentro do SASHE. Essa hiperbase constituiria
a camada Hipermdia X. Sobre essa camada, o Professor propriamente dito poderia trabalhar,
criando sobre a camada Hipermdia X um roteiro especfico para seu objetivo. Para tal, o
Professor disporia de todos as ferramentas listadas na camada Professor da figura. A hiperbase
limitada pelo roteiro construdo pelo professor seria a camada Hipermdia X, ou seja, uma
instncia da camada Hipermdia X. O Estudante, por sua vez, atuaria sobre essa camada
Hipermdia X, utilizando o navegador.
96
A Figura 5.3b mostra a arquitetura do Hip/Windows, um sistema para desenvolvimento de

aplicaes hipermdia, que constitui o mdulo de autoria de hiperdocumentos do sistema
SASHE. Em Nunes at al. (1996) so descritos os componentes do Hip, conforme mostrado na
Figura 5.3b:
Interface, responsvel pela interao do sistema com o usurio;
Biblioteca de Classes, que implementa as abstraes definidas pelo modelo MCA

(Casanova et al., 1991);
Gerenciador da Hiperbase, responsvel pela manipulao dos objetos que compem a

hiperbase.
As informaes presentes em Nunes et al. (1996, 1997b) so muito importantes e serviram

como ponto de partida para o processo de engenharia reversa, porm, como j mencionado, no
havia nenhuma documentao de anlise ou de projeto do sistema que foi efetivamente seguida
para a implementao do SASHE.
Usurio
Usurio
Hip/Windows
Interface de Autoria
Navegador
Sistema
Hip
Gerenciador da Hiperbase
DLL
Biblioteca de Classes
Hiperbase (MCA)
Figura 5.4a - Arquitetura recuperada do

ambiente SASHE
Figura 5.4b - Arquitetura recuperada do

Hip/Windows
Dessa forma, a partir do estudo de caso realizado com o SASHE, no foi possvel comparar
a documentao recuperada com a documentao original do sistema, uma vez que esta ltima
no existe. No entanto, as informaes recuperadas atravs da aplicao do mtodo Fusion-RE/I
mostraram-se consistentes com os relatrios existentes, embora a arquitetura proposta
inicialmente para o sistema SASHE (Figura 5.3a), no tenha tido todos os seus componentes
implementados. A arquitetura recuperada, que retrata a real implementao do sistema SASHE
1.0 mostrada na Figura 5.4a. Os documentos recuperados confirmaram a arquitetura proposta
para o sistema Hip (Figura 5.3b), documentada em Nunes et al. (1996) e totalmente
implementada na verso atual. A Figura 5.4b apresenta a arquitetura recuperada do Hip,
elaborada em camadas para melhor visualizao.
97
5.3 Uma proposta de adequao do Fusion-RE/I a

sistemas OO
Como descrito na Seo 5.1, alguns pontos, na aplicao do mtodo, foram crticos. Isso devido,
principalmente, ao paradigma de implementao do sistema utilizado no estudo de caso
(SASHE). Como anteriormente o mtodo no havia sido aplicado a nenhum sistema com tal
caracterstica, vrios fatores que no haviam sido previstos influenciaram o processo.
Nesta seo proposta uma reorganizao das etapas previstas no mtodo Fusion-RE/I, a
fim de melhorar a adequao do mtodo a sistemas orientados a objetos. Nesta nova proposta,
dois pontos so modificados:
definio de Temas; e
recuperao do Modelo de Objetos.
Tanto no Fusion-RE/I como no Fusion-RE, o objetivo da definio de Temas, que agrupem

as funcionalidades identificadas no sistema, nortear a construo do Modelo de Objetos, pois
se pretende recuperar uma modelagem OO para um sistema que foi originalmente concebido sob
outro paradigma. Como foi argumentado na Seo 5.1 (Quadro 5.2), a definio de Temas perde
o significado a partir do momento que o Modelo de Objetos deixa de ser uma abstrao
resultante da anlise de funcionalidades e passa a ser recuperado do cdigo fonte, retratando o
Modelo de Objetos realmente implementado.
Nesta nova proposta, os Temas apenas sero definidos caso haja a necessidade de se
particionar o Modelo de Objetos Real, devido ao seu tamanho e sua complexidade. Assim, os
objetos podem ser organizados em vrios modelos, consistentes entre si, facilitando dessa forma,
a leitura e o entendimento da modelagem. Porm, deve-se ressaltar que embora a diviso do
Modelo de Objetos deva levar em conta a funcionalidade do sistema, os Temas devem se
adequar implementao existente. Sob essa nova viso, os temas deixam de agrupar assuntos
identificados atravs da interao com a interface, para agrupar classes e relacionamentos que
implementam um determinado aspecto do sistema.
Sendo assim, cabe ao engenheiro de software responsvel pelo processo de engenharia
reversa, determinar a necessidade ou no da definio de Temas durante a aplicao do mtodo.
A definio de Temas pode ser a ltima tarefa da primeira etapa (Recuperao de Vises
98
Funcionais), mas pode continuar juntamente com a recuperao do Modelo de Objetos, pois
como dito anteriormente, os temas devem se adequar ao Modelo de Objetos implementado.
Outro aspecto observado na realizao do estudo de caso com o SASHE a validade da
recuperao do Modelo de Objetos durante a etapa de recuperao de vises funcionais.
Retomando, a recuperao das vises funcionais feita unicamente atravs das informaes j
existentes sobre o sistema e da manipulao da interface do software. Dessa forma, o Modelo de
Objetos recuperado, segundo o mtodo Fusion-RE/I, uma abstrao construda a partir das
informaes coletadas nos passos anteriores (ver Quadro 2.6), sem que haja nenhum contato com
o cdigo fonte.
Conforme discutido (Seo 5.1), essa modelagem isenta da implementao pode ser
vantajosa ou no, dependendo do objetivo definido para o processo de engenharia reversa. Nesta
proposta (Quadro 5.3), assumimos que o sistema alvo orientado a objetos e que objetivo da
engenharia reversa recuperar uma modelagem que seja fiel implementao, semelhante ao
estudo de caso desenvolvido. Sendo assim, a recuperao do Modelo de Objetos passa a ser a
primeira tarefa (a.) da segunda etapa do mtodo (Recuperao de Vises Estruturais). Dessa
forma, o Modelo de Objetos deixa de ser abstrado da funcionalidade para ser recuperado do
cdigo fonte do sistema. Assim garantimos que o Modelo de Objetos realmente reflete o sistema
implementado.
Quadro 5.3 - Modificaes propostas para o Fusion-RE/I
Etapa 1. Recuperao de Vises Funcionais
a. Obteno de informaes existentes sobre o sistema

b. Recuperao do modelo de anlise
b1. Elaborao do Modelo de Ciclo de Vida
b2. Elaborao do Modelo de Operaes

b3. Definio de Temas (caso seja necessrio)
Etapa 2. Recuperao de Vises Estruturais
a. Recuperao do Modelo de Objetos

a1. Ajuste dos Temas definidos (caso seja necessrio)
b. Elaborao do Quadro de procedimentos de implementao
b1. Elaborao do Quadro de Chamadas
b2. Elaborao do Quadro ndice de Procedimentos
c. Elaborao do Quadro de Operaes - Procedimentos de Implementao
99
De fato, a tarefa de se recuperar o Modelo de Objetos a partir do cdigo fonte teve que ser
realizada no estudo de caso feito com o SASHE, pois para a recuperao do restante das
informaes estruturais prescritas pelo Fusion-RE/I necessrio ter o conhecimento da
arquitetura do cdigo OO.
No Quadro 5.3 apresentado um resumo das etapas do mtodo Fusion-RE/I com as
modificaes propostas.
As setas indicam os pontos onde houve modificaes em relao proposta original do
Fusion-RE/I (ver Quadro 2.6). Independente da mudana de passos proposta, fato que a
interao com a interface, ao invs da manipulao do cdigo fonte, facilita consideravelmente a
recuperao dos Modelos de Ciclo de Vida e de Operaes. Alm disso, conforme discutido na
Seo 5.1, consegue-se um ganho de familiaridade com o domnio do sistema, uma vez que a
interface um dos elementos que evidencia esse domnio.

Neste captulo foram abordados os pontos positivos e os pontos crticos da aplicao do FusionRE/I a um sistema orientado a objetos, assim como os aspectos de validao da documentao
recuperada atravs da engenharia reversa. Tambm foi apresentada uma nova proposta de
adequao do mtodo Fusion-RE/I para sistemas sob o paradigma de orientao a objetos. No
prximo captulo, so feitas as concluses deste trabalho e apresentados possveis trabalhos
futuros.
100
Captulo 6
Concluso
Este trabalho teve como um dos seus objetivos principais a elaborao de uma proposta para a
adequao do sistema SASHE ao domnio da documentao de engenharia reversa de software,
de forma que fosse proporcionada maior agilidade para o acesso dessa documentao e que
tambm fossem estabelecidos links representativos, que guiassem o usurio durante a
navegao da documentao de engenharia reversa, explicitando os relacionamentos entre os
documentos.
Foi realizado um experimento, de forma que a anlise dos resultados embasasse essa
proposta. Tal experimento consistiu da utilizao e aplicao de engenharia reversa ao sistema
SASHE, um sistema hipermdia prottipo existente desenvolvido no ICMC-USP. Sendo que o
ambiente SASHE baseia-se no modelo MCA (Casanova et al., 1991), um modelo interno de
estruturao de ns que auxilia a organizao das informaes, esse modelo tambm foi
estudado para que obtivssemos os subsdios necessrios ao processo de entendimento do
SASHE.
Para que a documentao atendesse ao paradigma OO, o processo de engenharia reversa
orientou-se pelo mtodo Fusion-RE/I (Costa, 1997). Foi realizado um estudo prvio desse
mtodo, viabilizando sua aplicao ao sistema SASHE. Tambm foram estudados os conceitos
de uma linguagem padro de modelagem OO, a UML (Rational, 1997a), cuja potencialidade de
ser independente da utilizao de qualquer mtodo sob o paradigma OO, pde ser comprovada.
101
Captulo 6 - Concluso
Para que a UML pudesse ser utilizada neste trabalho, foram propostos possveis mapeamentos
entre os modelos utilizados pelo mtodo Fusion-RE/I e os modelos propostos pela UML.
Para o incio da construo da hiperbase composta pelos documentos recuperados do
sistema SASHE, foi realizada uma modelagem conceitual do domnio de engenharia reversa,
baseada nas etapas propostas pelo mtodo Fusion-RE/I. Tal modelagem foi feita utilizando-se o
mtodo de projeto de aplicaes hipermdia OOHDM.
Tendo como base a modelagem em OOHDM, foi iniciada a construo, propriamente dita,
da hiperbase no SASHE. Uma vez que o SASHE baseado no modelo MCA, a modelagem feita
previamente teve que ser ajustada para que os ns fossem organizados adequadamente.
A maior parte da documentao recuperada do SASHE foi efetivamente inserida na
hiperbase, sendo que essa experincia proporcionou o conhecimento necessrio para a sugesto
de pontos de ajuste para o sistema SASHE, visando proporcionar um melhor suporte autoria e
navegao de hiperbases contendo documentos de engenharia reversa.
6.1 Contribuies deste Trabalho

Durante o andamento deste trabalho, constatamos que, de fato, existe a necessidade de um meio
de acesso mais gil aos documentos de engenharia reversa, isso devido ao grande volume de
documentao manipulada durante e aps o processo, e tambm ao grande nmero de
relacionamentos existentes entre os documentos. As modificaes para a adequao do sistema
SASHE ao domnio da documentao de engenharia reversa propostas, juntamente com as
caractersticas j existentes no SASHE, viriam suprir essa necessidade, facilitando tanto na
autoria da hiperbase, permitindo que os relacionamentos entre os ns fossem estabelecidos j na
autoria, como na navegao, provendo controles para guiar o usurio atravs dos documentos e
apontar os relacionamentos entre os modelos, sem que o usurio tenha necessidade de
conhecimento prvio da documentao.
Tambm com a realizao da engenharia reversa, foram recuperadas a documentao de
anlise e importantes informaes estruturais sobre o sistema SASHE. No incio do estudo de
caso com o SASHE, no existia nenhuma documentao de anlise sobre o sistema, e pouca
documentao sobre sua funcionalidade e sua estrutura. A documentao recuperada e publicada
102
em Feltrim e Fortes (1999) poder servir como guia para novos usurios do sistema e tambm
auxiliar engenheiros de software em futuras manutenes.
Tambm podemos citar outras contribuies que no eram o foco principal deste trabalho,
mas que foram concludas durante o seu desenvolvimento.
A aplicao do mtodo de engenharia reversa Fusion-RE/I, da sua fase inicial at a sua
concluso, em um sistema orientado a objetos, proporcionou um contexto propcio anlise de
alguns pontos crticos da aplicao do mtodo a sistemas OO. Tambm permitiu a constatao de
aspectos do Fusion-RE/I que permanecem sendo vantajosos, mesmo quando aplicado a sistemas
OO. Foi realizada uma avaliao crtica de todas as etapas propostas pelo mtodo e foram
propostas algumas modificaes na ordem de suas etapas, a fim suprir os pontos crticos
apontados e de favorecer sua aplicao a sistemas OO (Feltrim et al., 1999).
A proposta de mapeamento feita para os modelos do Fusion-RE/I, de forma que fossem
representados em UML pode vir a ser o ponto inicial para um completo mapeamento do
Fusion-RE/I para a notao UML.
A modelagem do domnio de engenharia reversa realizada em OOHDM pode ser vista como
uma apresentao dos requisitos funcionais identificados no processo de engenharia reversa que
possam ser suportados por um sistema hipermdia. Essa modelagem foi uma tentativa de
formalizar o relacionamento das atividades de engenharia reversa, seus subprodutos e interaes
(Feltrim; Fortes 1998b). Como base para o estabelecimento das atividades envolvidas e dos
modelos gerados ao final do processo, nos apoiamos no mtodo Fusion-RE/I, que viria a ser
efetivamente utilizado posteriormente na engenharia reversa do sistema SASHE.
6.2 Sugestes para Futuras Pesquisas

Um trabalho futuro que se apresenta bastante interessante a generalizao da interface do
SASHE proposta para atender o domnio de engenharia reversa. A nova interface proposta neste
trabalho foi baseada na resoluo dos problemas encontrados durante a manipulao da
hiperbase de engenharia reversa. Sendo assim, est fortemente ligada s etapas e aos produtos
gerados pelo mtodo de engenharia reversa utilizado, o Fusion-RE/I. Um estudo aprofundado do
processo de engenharia reversa, tendo como foco o estabelecimento de fases genricas do
103
processo e de atributos de ns generalizados, poderia resultar em uma interface que atendesse o

domnio de documentos de engenharia reversa sem restringi-la a um ou outro mtodo.
A efetiva implementao dessa interface ao sistema SASHE vir suprir a necessidade de um
sistema adequado de autoria e navegao de documentos resultantes do processo de engenharia
reversa.
Outro trabalho futuro que ficou evidenciada sua necessidade durante a realizao deste
mestrado consiste na definio de um mtodo de engenharia reversa para sistemas
implementados sob o paradigma de orientao a objetos. Os sistemas OO possuem muitas
caractersticas intrnsecas ao paradigma que necessitam de um tratamento especfico. Embora
tenha sido possvel a aplicao do Fusion-RE/I a um sistema OO, muitos aspectos de
implementao desse sistema no foram recuperados completamente, em funo do referido
mtodo no apoiar a recuperao de documentos de projeto. A proposta de um mtodo que
recuperasse no s os documentos de anlise, mas tambm os documentos de projeto OO, viria
suprir uma necessidade de fato comprovada.
Como a aplicao do Fusion-RE/I iniciada pela manipulao da interface para a elaborao
do Modelo de Ciclo de Vida e essa tarefa requer um esforo mecnico de interao exaustiva
com todas as opes da interface do software com o usurio, um auxlio automtico que
capturasse essas interaes se apresenta tambm como alvo de futuras pesquisas.
104
Referncias Bibliogrficas
ADELSON, B.; SOLOWAY, E. The Role of Domain Experience in Software Design. IEEE
Transactions on Software Engineering, v.SE-11, n.11., p.1351-1360, 1985.
BIGELOW, J. Hypertext and CASE. IEEE Software, p.23-27, March 1988.
BIGELOW, J.; RILEY, V. Manipulating Source Code in DynamicDesign. ACM Hypertext87
Conf., Proceedings, p.397-408, 1987.
BIGGERSTAFF, T. Design Recovery for Maintenance and Reuse. IEEE Computer, v.22, n.7,
p.36-49, 1989.
BULLOCK, J.C.; GOBLE, C.A. TouristT - Conceptual Hypermedia Tourist Information. ACM
Hypertext97 Conf., Proceedings, p.228-229, 1997.
CASANOVA, M.A.; TUCHERMAN, L; LIMA, M. J.; RANGEL, J. L.; RODRIGUEZ, N. R.;
SOARES, L. F. G. The Nested Context Model for Hyperdocuments. Third ACM
Conference on Hypertext, Proceedings, San Antonio, Texas, p.193-201, 1991.
CASTRO, M.A.S. Infra-Estrutura de Suporte Editorao de Material Didtico Utilizando
Multimdia. Revista Brasileira de Informtica na Educao, n.1, p.61-70, 1997.
CERQUEIRA, A.A.C. HOOT: Integrando Hipermdia e Bancos de Dados Orientados a
Objetos. Dissertao (Mestrado), UFRJ, Rio de Janeiro, Agosto 1997.
CHIKOFSKY, E.J.; CROSS II, J.H. Reverse Engeneering and Design Recovery: A Taxonomy.
IEEE Software, v.7, n.1, p.13-17, 1990.
COLEMAN, D. et al. Desenvolvimento Orientado a Objetos: O Mtodo Fusion. Ed. Campos,
Rio de Janeiro, 1996.
COLEMAN, D.; ARTIM, J.; OHNJEC, V.; RIVAS, E.; RUMBAUGH, J.; WIRFSBROCK, R.
UML: The Language of Blueprints for Software?. ACM Sigplan Notices, n.32, p.201-205,
New York, 1997.
105
COSTA, R.M. Um mtodo de Engenharia Reversa para Auxiliar a Manuteno de Software.

Dissertao (Mestrado), ICMCUSP, So Carlos, 1997. 100p.
DEBAUD, J-M.; MOOPEN, B.; RUGABER, S. Domain Analysis and Reverse Engineering.
In: International Conference on Software Maintenance, Victoria. Proceedings, p.326-335,
1994.
ERIKSSON, H.; MAGNUS, P. UML Toolkit. Wiley, New York, 1998.
FELTRIM, V.D.; FORTES, R.P.M. Uma modelagem do domnio de Engenharia Reversa de
Software utilizando o mtodo OOHDM. Notas do ICMCUSP, Srie Computao, n.40,
So Carlos, Junho 1998a. 23p.
FELTRIM, V.D.; FORTES, R.P.M. Requisitos de Hiperdocumentos de suporte ao domnio de
Engenharia Reversa de Software. In: Workshop de Engenharia de Requisitos, Anais,
Maring, p.159-167, Outubro 1998b.
FELTRIM, V.D.; FORTES, R.P.M. Documentao do sistema SASHE recuperada por meio de
Engenharia Reversa. Relatrio Tcnico do ICMCUSP, Srie Computao, n.90,
So Carlos, Julho 1999. 254p.
FELTRIM, V.D.; FORTES, R.P.M.; SILVA, W.F. Aspectos de Validao do Mtodo de
Engenharia Reversa Fusion-RE/I aplicado a um Sistema Hipermdia. In: XIII Simpsio
Brasileiro de Engenharia de Software, Anais, Florianpolis, p.257-272, Outubro 1999.
GARG, P.K.; SCACCHI, W. ISHIS - Designing an Intelligent Software Hypertext System.
IEEE Expert, p.52-63, Fall 1989.
GARZOTTO, F.; PAOLINI, P.; SCHWABE, D. HDM - A Model-Based Approach to Hypertext
Application Design. ACM Transactions on Information Systems, v.11, n.1, p.1-26, January
1993.
GREENBAUM, J.; KYNG M. (eds), Design at work: Cooperative of Computer Systems.
Lawrence Erlbaum, Hillsdale, NJ, 1991.
HAREL, D. Statecharts: A Visual Formalism for Complex Systems. Science of Computer
Programming, v.8, p.231-274, 1987.
HAREL, D.; GERY, E. Executable Object Modeling With Statecharts. Computer, n.30, p.31-&,
1997.
JUBILEU, A.P.; SANCHES, R. Um Processo de Aquisio de Conhecimento Explcito para
Apoiar o Mtodo de Engenharia Reversa Fusion-RE/I. In: IV Workshop de Teses em
Engenharia de Software, Anais, Florianpolis, p.79-83, Outubro 1999.
MASIERO, P.C. Anlise Orientada a Objetos: Uma Introduo ao Mtodo Fusion. In: IX
Simpsio Brasileiro de Engenharia de Software. Documento preparado como apoio ao
tutorial homnimo, Recife, 1995.
106
MEIRA, S.M.; CABRAL, R.S. Id: Um Sistema de Hipertexto Configurvel e Orientado a

Objetos para Integrar Documentos de Software. VIII Simpsio Brasileiro de Engenharia de
Software, Anais, Curitiba, p.283-296, 1994.
NIELSEN, J. Multimedia and Hypertext - The Internet and Beyond. Academic Press, London,
United Kingdom, 1995.
NUNES, M.G.V.; HASEGAWA, R.; VIEIRA, F.M.C. Hip/Windows: Um Ambiente de Autoria
de Hiperbases Multimdia, Relatrio Tcnico do ICMCUSP, n.38, So Carlos, 1996. 34p.
NUNES, M.G.V.; FORTES, R.P.M. Roteiros em Aplicaes no Ensino: a Questo do Controle
do Leitor. In: Workshop em Sistemas Multimdia e Hipermdia, III., Anais, So Carlos,
p.15-27, 1997.
NUNES, M.G.V.; FORTES, R.P.M.; NICOLETTI, M.C. Flexible Guided-tours in Hypertexts: a
way of controlling the user in learning applications. In: World Multiconference on
Systemics, Cybernetics and Informatics SCI97/ISAS97, Proceedings, Caracas-Venezuela,
1997a.
NUNES, M.G.V.; HASEGAWA, R.; VIEIRA, F.M.C.; SANTOS, G.H.R.; FORTES, R.P.M.
SASHE: Sistema de Autoria e Suporte Hipermdia para Ensino. Notas do ICMCUSP, n.33,
So Carlos, 1997b. 22p.
OXFORD, Dictionary of Computing Oxford, University Press, 1986.
PENTEADO, R.A.D. Um mtodo para Engenharia Reversa Orientado a Objetos. Tese
(Doutorado), IFSCUSP, So Carlos, 1996. 251p.
PRESSMAN, R. S. Engenharia de Software. 3o ed., Makron Books, 1995.
QUINAIA, M.A. Diretrizes para Reengenharia de Software com Caractersticas de Software
Legado. Dissertao (Mestrado), ICMCUSP, So Carlos, 1998. 111p.
RATIONAL Software Corporation. UML Summary, 1997a. (http://www.rational.com/UML)
RATIONAL Software Corporation. UML Notation Guide, 1997b.
(http://www.rational.com/UML)
RATIONAL Software Corporation. UML Semantics, 1997c. (http://www.rational.com/UML)
RATIONAL Software Corporation, 1999. (http://www.rational.com/rose).
RIZK, A.; SUTCLIFFE, D. Distributed Link Service in the Aquarelle Project. ACM
Hypertext97 Conf., Proceedings, p.208-209, 1997.
ROSSI, G. Um Mtodo Orientado a Objetos para o Projeto de Aplicaes Hipermdia. Tese
(Doutorado). Departamento de Informtica Pontifcia Universidade Catlica, Rio de Janeiro,
1996. 205p.
107
RUGABER, S. Program Comprehension for Reverse Engineering. In: AAAI Workshop on AI

and Automated Program Understanding, San Jose, California, p.106-110. July 1992.
(http://www.cc.gatech.edu/reverse/papers.html)
RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W. Object
Oriented Modeling and Design. Prentice Hall, 1991.
SALEH, K.; BOUJARWAH, A. Communications Software Reverse Engineering: A SemiAutomatic approach. Information and Software Technology, Oxford, n.38, p.379-390, 1996.
SCHACH, S.R. The Economic Impact of Reuse on Maintanance. Journal Software
Maintanance: Research and Practice, v.6, n.4, p.185-196, 1994.
SCHNEIDEWIND, N.F. The State of Software Maitanance. IEEE Trans. on Software
Engineering, v.13, n.3, p.303-310, 1987.
SCHWABE, D.; ROSSI, G. The Object-Oriented Hypermedia Design Model. Communications
of the ACM, v.38, n.8, p.45-46, 1995.
SCHWABE, D.; ROSSI, G.; BARBOSA, S.D.J. Systematic Hypermedia Application Design
with OOHDM. In: Hypertext'96. Proceedings. Washington DC, USA, p.116-128,
March 1996.
SOARES, L.F.G. et al. HyperProp: Uma Viso Geral. In: I Workshop em Sistemas Hipermdia
Distribudos, Anais, ICMCUSP, So Carlos, p.1-12, 1995.
STI. Scientific Toolworks, Inc., 1999. (http://www.scitools.com)
TILLEY, S.R.; SMITH, D.B. On Using the Web as Infrastructure for Reengineering. 5th
Workshop on Program Comprehension (IWPC'97), Proceedings, p.170-173, Michigan,
1997.
108

Dissert PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Dissert PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Apoio Documentao de

Engenharia Reversa de Software

Valria Delisandra Feltrim

Dissertao1 apresentada ao Instituto de Cincias Matemticas e de Computao - USP, como

Trabalho realizado com o apoio financeiro da FAPESP, #97/12999-8.

Aos meus pais, Feltrim e Lourdes,

Ao Joo Caldas, por seu amor e apoio constantes.

amiga Gisele, por me ensinar a acreditar em mim.

s minhas companheiras de repblica, Luciana, Tatiana e Thelma, por compartilharem

A todos os amigos do ICMC, pela amizade e pelos momentos de descontrao vividos

Fapesp, pelo apoio financeiro.

A todos que, direta ou indiretamente, contriburam para a concluso deste trabalho.

2.3 Por que UML? ............................................................................................................. 19

2.5 Consideraes Finais.................................................................................................... 38

3 O Suporte de Sistemas Hipermdia................................................................41

3.2 O mtodo OOHDM ...................................................................................................... 48

3.3.2 Esquema de Classes Navegacionais .................................................................................................52

3.4 A hiperbase construda no SASHE................................................................................54

4 Engenharia Reversa aplicada ao Sistema SASHE ........................................65

Modelo de Ciclo de Vida .................................................................................................................66

4.2 Mtricas do processo de Engenharia Reversa realizado.................................................81

5 Avaliao geral do Fusion-RE/I .....................................................................87

6 Concluso ...................................................................................................... 101

Referncias Bibliogrficas................................................................................ 105

Figura 2.1 - Processo de Engenharia Progressiva x Engenharia Reversa .................................... 9

Figura 4.2 - Refinamento da opo Hiperbase e da operao Abrir....................................68

Quadro 2.1 - Representao do esquema para descrio das operaes.................................... 14

O usurio de sistemas hipermdia pode ser: leitor e autor.

1.4 Organizao do Trabalho

Captulo 2 - Engenharia Reversa

2.1 Conceitos de Engenharia Reversa

Captulo 2 - Engenharia Reversa

Figura 2.1 - Processo de Engenharia Progressiva x Engenharia Reversa

Captulo 2 - Engenharia Reversa

Captulo 2 - Engenharia Reversa

2.2 O Mtodo Fusion-RE/I

Modelo de Ciclo de Vida

Figura 2.2 - Viso Geral do Mtodo Fusion-RE/I

Captulo 2 - Engenharia Reversa

2.2.1 O Mtodo Fusion : Uma Viso Introdutria

Figura 2.3 - Viso Geral do Mtodo Fusion (Masiero, 1995)

Captulo 2 - Engenharia Reversa

A anlise deve iniciar em um alto nvel de abstrao, recomendando-se que os detalhes

Captulo 2 - Engenharia Reversa

os recebem, pr-condies e resultados da operao, descritos como ps-condies (Penteado,

2.2.2 Recuperao de Vises Funcionais

Captulo 2 - Engenharia Reversa

obter outras informaes relevantes, como o domnio do sistema, linguagem de implementao,

Captulo 2 - Engenharia Reversa

b.1. Elaborar o Modelo de Ciclo de Vida do Sistema

Captulo 2 - Engenharia Reversa

so obtidas atravs da observao da interface, identificando os eventos de sada gerados pela

Captulo 2 - Engenharia Reversa

2.2.3 Recuperao de Vises Estruturais

Captulo 2 - Engenharia Reversa

Para a elaborao desse quadro utiliza-se todos os quadros de chamadas obtidos

2.3 Por que UML?

Captulo 2 - Engenharia Reversa

Captulo 2 - Engenharia Reversa

b) Diagramas de Caso de Uso

Captulo 2 - Engenharia Reversa

2.4 Representao dos Modelos do Mtodo FusionRE/I em UML

Captulo 2 - Engenharia Reversa

int entidade::f scanf (FILE f p, const char f ormat, int *item)