REVERSE ENGINEERING SOFTWARE

1
REVERSE ENGINEERING SOFTWARE

• MWO Dean Floyd
• CFICSE 1999

2
Introduction

• Definitions
• Why Reverse Engineer?
• Using Object-Oriented Technology for Reverse
  Engineering
• Tools

3
DEFINITIONS (Reverse Engineering and Design
Recovery A Taxonomy Elliot J Chikofsky and
James H Cross II)

• Reverse EngineeringThe process of analyzing a
  system to
• a. identify the systems components and their
  interrelationships and
• b. create representations of the system in
  another form or at a higher level of abstraction.
• Reverse Engineering in and of itself does not
  involve changing the subject system or creating a
  new system based on the reverse engineered
  system. It is a process of examination, not a
  process of change or replication.

4
DEFINITIONS (continued)
Two common sub areas of reverse engineering are
Redocumentation and Design Recovery.
REDOCUMENTATION The creation or revision of a
semantically equivalent representation within the
same relative abstraction level. The intent is
to recover documentation about a subject system
that existed or should have existed. DESIGN
RECOVERY Addition of domain knowledge, external
information, and deduction or fuzzy reasoning to
the observations of a system to identify
meaningful higher level abstractions beyond those
obtained directly by examining the system itself.
5
DEFINITIONS (continued)
RESTRUCTURING the transformation from one
representation form to another at the same
relative abstraction level, while preserving the
subject systems external behavior.
While restructuring creates new versions that
implement or propose change to the subject
system it does not normally involve modifications
because of new requirements.
It is often used as a form of preventive
maintenance to improve the physical state of a
system.
Many consider redocumentation to be an
unintrusive, weak form of restructuring.
6
DEFINITIONS(continued)
Reengineering the examination and alteration of
a subject system to reconstitute it in a new form
and the subsequent implementation of the new form.
Generally includes some form of reverse
engineering followed by some form of forward
engineering or restructuring.
May include modifications with respect to new
requirements not met by the original system.
7
What Are We Trying To Do?

• Cope with Complexity - need to extract relevant
  information so that the process and product can
  be controlled in systems evolution.
• Generate Alternate Views - to aid with
  comprehension - (control-flow diagrams, structure
  charts, entity-relationship diagrams)
• Recover Lost Information - modifications to older
  systems are often not well documented - reverse
  engineering (design recovery) allows us to gain
  an understanding of how these systems work.

8
How Do We Do It?
One way we can do this is by integrating object
oriented technology into an older unstructured
system. This would enable us to build a model of
the system in order to make it easier to reason
about modifications. (Lessen the complexity,
Generate alternate views)
The Following portion of this presentation is
extracted from the paper Re-engineering of old
systems to an object-oriented architecture. by
Ivar Jacobson and Fredrik Lindstrom.
9
Complete change in Implementation Technique - no
change in Functionality
Primitive Description Elements
Analysis Objects
Design Objects
10
Complete change in Implementation Technique - no
change in Functionality
Three main steps of the Re-engineering process
1. Prepare an analysis model 2. Map each
analysis object to the implementation of the old
system 3. Redesign the system using forward
engineering techniques for object-oriented system
development.
Note step 3 is the implementation of the
analysis model and will not be discussed in this
presentation
11
Prepare an Analysis Model
Assimilate Existing Info about System (Description
Elements) Subset of these elements are those
which represent the true system (source code or
documentation which is consistent with the source
code) called Primitive description elements
The analysis model resulting from finding objects
in the description elements can be regarded as a
graph. There are a number of analysis objects
connected to one another with a set of directed
edges which all imply some kind of dependency of
the terminal object.
12
Map Each Analysis Object to the Implementation of
the Old System
PRIMITIVE
ANALYSIS MODEL
OLD SYSTEM
Two Constraints 1. All analysis objects must be
motivated by at least one primitive description
element. 2. All edges in the analysis model must
be motivated by at least one primitive
description element. The analysis objects,
description elements(primitive and non-primitive)
and guidance from system experts are used to map
the analysis objects to the implementation of the
old system.
13
What next?
Once the analysis model has been successfully
mapped to the old system it is ready for
implementation using object oriented forward
engineering techniques.
It is generally unrealistic to replace a large
older system by a completely new system due to
the amount of resources required. We must have a
way to gradually replace older system parts.
14
Gradual Replacement
Existing implementation is gradually replaced
with object-oriented
15
Partial Re-engineering with no Change in
Functionality
The main steps of this process are 1. Identify
the part of the system that will be reimplemented
using object oriented techniques. 2. Prepare an
analysis model of the part to be exchanged and
its environment. 3. Map each object to the old
implementation of the system. 4. Iterate the
previous steps until the interface between the
part to be exchanged and the rest of the existing
system is acceptable.
16
Partial Re-engineering with no Change in
Functionality
The main steps (continued) 5. In
parallel 5.1 Design the new subsystem and its
interface to the rest of the old system. 5.2
Modify the old system and add an interface to the
new subsystem. 6. Integrate and test the new
subsystem and the modified old system.
17
Partial Re-engineering with no Change in
Functionality
Environment of part to be exchanged
Part to be exchanged
The goal is to make the object-oriented
application believe that the whole system
consists of objects.
OBJECT-ORIENTED DESIGN
18
Partial Re-engineering with no Change in
Functionality
The main steps of this process are 1. Identify
the part of the system that will be reimplemented
using object oriented techniques. 2. Prepare an
analysis model of the part to be exchanged and
its environment. 3. Map each object to the old
implementation of the system. 4. Iterate the
previous steps until the interface between the
part to be exchanged and the rest of the existing
system is acceptable.
19
Identify the Part of the Old System to be
Reimplemented Using Object-Oriented Techniques
Create two new subsets of the primitive
description elements
Dx - Which will contain the elements we wish to
exchange and Denv - which contains the elements
which are in the environment of Dx.
(An element is in the environment of Dx if it is
not already part of the Dx subset and it is
adjacent to elements of Dx in a dependency graph.)
20
Identify the Part of the Old System to be
Reimplemented Using Object-Oriented Techniques
A graph showing the dependencies between the
primitive description elements is required. It
can be Implicit - (exists in the minds of
technical experts) or Explicit - (exists in a
readable form)
A readable form is always preferable Technical
experts will make this task substantially easier
21
Partial Re-engineering with no Change in
Functionality
The main steps of this process are 1. Identify
the part of the system that will be reimplemented
using object oriented techniques. 2. Prepare an
analysis model of the part to be exchanged and
its environment. 3. Map each object to the old
implementation of the system. 4. Iterate the
previous steps until the interface between the
part to be exchanged and the rest of the existing
system is acceptable.
22
Prepare an Analysis Model of the Part to be
Exchanged and its Environment
Requirement Specification
MANUALS
This step is similar to that when we changed the
complete implementation but now we only have to
concentrate our efforts on a limited part of the
description elements. We prepare an analysis
model representing the union of elements we wish
to change(Dx) and those in their
environment(Denv).
Existing Documentation
23
Partial Re-engineering with no Change in
Functionality
The main steps of this process are 1. Identify
the part of the system that will be reimplemented
using object oriented techniques. 2. Prepare an
analysis model of the part to be exchanged and
its environment. 3. Map each object to the old
implementation of the system. 4. Iterate the
previous steps until the interface between the
part to be exchanged and the rest of the existing
system is acceptable.
24
Map each Analysis Object to the Implementation of
the Old System
Environment of part to be exchanged
EXISTING SYSTEM
(Aenv)
(Denv)
(Ax)
(Dx)
Part to be exchanged
The analysis model gets divided into two
subsets (Ax) - representing the part of the model
which will be definitely implemented with the new
technique. (Aenv)- representing objects which Ax
is related to. These objects will serve as
wrappers of the old system.
25
Partial Re-engineering with no Change in
Functionality
The main steps of this process are 1. Identify
the part of the system that will be reimplemented
using object oriented techniques. 2. Prepare an
analysis model of the part to be exchanged and
its environment. 3. Map each object to the old
implementation of the system. 4. Iterate the
previous steps until the interface between the
part to be exchanged and the rest of the existing
system is acceptable.
26
Evaluate the Interface
Now that a better understanding of the system has
been gained we must evaluate the interface
between the old and the new subsystems. As a
goal, the cut between subsystems should be made
so that only one of them manages the state of an
object and works as a server to the other
subsystems. Through changing the set Dx it is
possible to get a set Dx that through Denv, gives
a better interface between the old and new
subsystems. When we do this we have to repeat
the previous steps until we have an interface
that is acceptable.
(Dx- Description elements to be changed) (Denv
- Description elements in the environment of Dx)
27
Partial Re-engineering with no Change in
Functionality
The main steps (continued) 5. In
parallel 5.1 Design the new subsystem and its
interface to the rest of the old system. 5.2
Modify the old system and add an interface to the
new subsystem. 6. Integrate and test the new
subsystem and the modified old system.
28
Design the New Sub system and Its Interface to
the Old System.
The objects in Aenv are implemented with a set of
classes that allow the object to communicate with
the old system. The other objects of the
application only see objects. The objects of
Aenv behave like objects from the new subsystem
and like old software from the old system The
encapsulation property of objects makes it
possible to successively move the plane further
into the old system. Thus it is possible to
gradually replace the old system
29
Partial Re-engineering with no Change in
Functionality
The main steps (continued) 5. In
parallel 5.1 Design the new subsystem and its
interface to the rest of the old system. 5.2
Modify the old system and add an interface to the
new subsystem. 6. Integrate and test the new
subsystem and the modified old system.
30
Modify the Old System and Add an Interface to the
New System
In this step all parts in old system that
communicate with Dx, those with call procedures
or uses data in Dx, are replaced.
Instead of their original code , they have to use
the interface to the new system.
The set Denv contains these parts.
We should also modify the system so that a call
or an access to the parts in Dx results in an
error. An activation of them would mean we have
missed redirecting communication meant for the
new subsystem.
31
Partial Re-engineering with no Change in
Functionality
The main steps (continued) 5. In
parallel 5.1 Design the new subsystem and its
interface to the rest of the old system. 5.2
Modify the old system and add an interface to the
new subsystem. 6. Integrate and test the new
subsystem and the modified old system.
32
So What Has This Done For Us?
As discussed under, What are we trying to do?,
We have been attempting to lessen the complexity
of the system. To what end? To facilitate
system maintenance. 80 of maintenance involves
adding functionality. Can we do that more easily
now?
33
Re-engineering with a Change of Functionality
EXISTING SYSTEM
ANALYSIS MODEL
OBJECT-ORIENTED IMPLEMENTATION
This is the normal forward engineering process.
Changes are added to the analysis model and then
implemented using object oriented technique.
34
Re-engineering with a Change of Functionality
Change analysis model in accordance with
requirements. - New objects and edges are added
as required - Objects identified from the old
system are either deleted or receive new
attributes and edges.
The new analysis model can be partitioned into
three subgraphs 1. All the new objects 2. The
changed objects 3. The unchanged objects.
35
Is There anything to help us do this?
TOOLS
36
TOOLS ARCHITECTURE MODEL (Robert Arnold of the
Software Productivity Consortium)
Parser Semantic Analyzer
View Composer
Software Work Product
New View(s) of product

• Format
• Graphics
• Documentation
• Metrics
• Logic
• Reports

Information Base
System Documents User Manuals System Experts
37
RIGI
University of Victoria Hausi A.
Muller Development Environment Rigiedit
38
RIGI

• In the Rigi system, artifacts are stored in an
  underlying repository and manipulated through
  rigiedit, which provides editing, manipulation,
  annotation, hypertext, and exploration
  capabilities. Rigi also includes parsers which
  extract artifacts from the subject software. A
  domain model specifies the entity types and
  relationships of interest. The input stream is
  fed into rigiedit to visually represent the
  initial graph.

39
RIGI

• To manage the complexity of the graph, rigiedit
  allows you to select, filter, layout, and edit
  the graph to identify pertinent subsystems
  (automatically or manually collapse related
  artifacts into subsystems). These subsystems
  typically represent concepts such as abstract
  data types or personnel assignments.

40
RIGI

• The newly created, simpler, hierarchical graph
  can be navigated, analyzed, and presented using
  various automatic or user-guided graphical
  layouts. Rigi can save different perspectives of
  this hierarchy in a reloadable view.

41
GDPro
Developed by Advanced Software Development
Environment Reverse Engineering Application
42
Full Reverse Engineering for Java, C and
IDL GDPro automatically produces detailed design
diagrams, depicting various aspects of the design
of existing Java, C and IDL code. These designs
are clearly laid out using GDPros automatic
diagram layout abilities. Over a million lines of
code can be reverse engineered. It provides a
variety of means that allow you to filter exactly
what portions of your code are included in
reverse engineering, making processing much
faster and models much clearer. A variety of
reports can be created from the
reverse-engineered code, including reports on
design quality.
GDPro
43
GDPro vs. The Competition Automatic Diagram
Layout
GDPro features sophisticated automatic diagram
layout. After drawing diagrams, or following
reverse engineering of source code, GDPro will
automatically layout the resulting diagram,
providing clean, clear models.
44
GDPro vs. The Competition Automatic Diagram
Layout
Other products produce "spaghetti diagrams" that
are unreadable and of little value.
45
Summary

• Definitions - Reverse vs. Reengineering
• Why Reverse Engineer?
• - Reduce complexity
• - Aid with SW Maintenance
• Using Object-Oriented Technology for Reverse
  Engineering
• - Reengineering a large system by parts.
• Tools - RIGI - GDPro