Deriving an Object Model from Legacy Fortran Code

Gokul V. Subramaniam Eric J. Byrne

Nortel - Northern Telecom Department of Computer Science and Engineering
P.O. Box 833871 The University of Texas at Arlington
Richardson, TX 75083-3871 Box 19015
Phone: 214-685-8214 Arlington, Texas 76019-0015
E-mail: [email protected] Phone : 817-272-2341
E-mail: [email protected]

Abstract ware that was created using earlier software develop-

ment methods. This existing software has undergone
The practice of software development continues to constant change in response to user demands for new
shift towards the use of object-oriented approaches. features, changing technology, and business process
The motivation for this trend is the benefits attributed reengineering efforts. Unfortunately, software tends to
to object-oriented software, including improved main- deteriorate under constant change, becoming increas-
tainability. A s organizations develop new object- ingly difficult to maintain. This is in contrast to soft-
oriented software, they face the problem of maintaining ware built today that can achieve higher quality and
their older software. How can existing non-objected- maintainability than systems built using earlier prac-
oriented software benefit from this new software engi- tices. This juxtaposition of deteriorating software and
neering technology? This paper presents a nine step more effective software engineering methods raises the
process for deriving an object model from existing un- question of how can recent software engineering ad-
structured F O R T R A N source code. Both top-down vances be applied to improve existing software?
and bottom-up approaches are used to derive objects, Existing non-object-oriented software can be reengi-
classes, class attributes and methods, and relationships neered to produce an equivalent (assuming that the
among classes. This process can be used within a functional requirements have not changed) object-
reengineering project to convert legacy F O R T R A N code oriented implementation. The goal of software reengi-
into a new object-oriented implementation written in a neering is to take an existing system and generate from
language such as C++. Experience with using this pro- it a new system, called the target system, that has the
cess is also described. same properties as a system created by modern soft-
ware engineering practices [4]. Here, the properties of
interest are those associated with the concept of object-
oriented software and its benefits.
1. Introduction To take an existing non-object-oriented system and
reengineer it into an object-oriented implementation
It is a natural consequence of the evolution of the it is necessary to be able to derive an object model
software engineering discipline that advances create for the system. Rumbaugh defines an object model as
new technologies. We are now in the middle of such “captur[ing]the static structure of a system by showing
an evolution as object-oriented methods [2, 7, 131 re- the objects in the system, relationships between the ob-
place the traditional functional decomposition meth- jects, and the attributes and operations that character-
ods of the past. It is believed that the use of ize each class of objects” [13]. Several object-oriented
object-oriented approaches provide support for im- reengineering approaches have been presented in the
proved software quality, maintainability, extensibility, literature. The SCORE/RM model provides an eight
and reusability. stage reengineering framework [9]. The first six stages
There exists today a tremendous body of useful soft- consist of reverse engineering and include an “abstrac-

1063-6773/96 $5.00 0 1996 IEEE 3

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 tion” stage where object identification is done. Jacob- ware reengineering case study was performed on an un-
son and Lindstrom describe a reengineering approach structured program written in FORTRAN. This case
where reverse engineering is used to create an object- study helped to test and refine the steps in the pro-
oriented description of the application domain [lo]. cess [15]. The next section briefly discusses a strat-
Their model is expressed as a directed graph where the egy for reengineering unstructured source code into an
nodes stand for analysis objects and the edges repre- object-oriented implementation. Afterwards, the pro-
sent dependencies between the analysis objects. Sneed cess itself is presented. Finally, the case study in which
defined a method called REORG that uses ten steps to the process was applied is described.
transform a procedurally structured COBOL program
into object-oriented COBOL [14]. However, these ar-
2. A Reengineering Strategy
ticles do not describe algorithms for deriving object
models.
The process used to conduct a reengineering project
As a first step towards deriving complete object
is strongly influenced by the strategy that is used to
models some research efforts have developed techniques
renovate the software [3, 41. One possible strategy is
for identifying potential objects and classes by analyz-
shown in Figure 1. This strategy is based on the as-
ing source code. Liu and Wilde proposed two algo-
sumption that there are no changes to the functional
rithms to identify candidate objects in a procedural
requirements for the software. The existing and target
program, one algorithm used global data items, and
systems will behave identically from a user’s viewpoint
the other used data type information from function in-
and will differ only in their designs and implementa-
terfaces [12]. Silva-Lepe’s approach views a program
tions. If changes to the system requirements are to be
as a low level model of an application domain in terms
implemented as part of a project, a different strategy
of the services required [113. Data structures and type
will be needed.
declarations (C language) are used to postulate initial
classes of objects. Next, a behavioral analysis is per- Final
formed to assign functions in the program as methods
to the classes identified. Achee and Carver proposed If Object \
a “greedy” approach to object identification [l]. Their
approach evaluates the parameters to subroutines in a Forward
FORTRAN-77 program to determine sets of attributes. Engineenng Engineering
(using object model (using object-
Methods are generated by considering each statement
in the source code. Tan and Ling developed an aug-
mented object model for expressing objects in a pro-
gram [MI, This approach is based on data flow analysis Application Domain Existing System
t
Target 00-System
to classify objects. Next, classes and their relation- Knowledge (i.e code, docs, etc.)
ships are formed to model the objects. This approach
is domain-specific to data intensive business programs Figure 1. A Reengineering Strategy
(COBOL). Canfora, Cimitile, and Munro proposed an
object identification technique that uses a statistical The strategy shown in Figure 1 divides the reengi-
technique to provide a set of well-formed candidate ob- neering process into two major activities. The first ac-
jects [8].This technique is based on analysis of the use tivity derives an object model from the existing source
of global variables. code. This object model must describe the system in
This paper addresses the problem of how to re. sufficient detail such that it can be used to construct a
verse engineer unstructured source code to derive an new object-oriented implementation. The process pre-
object model. A nine step process is presented that sented in the next section (See Figure 2.) describes how
combines both top-down and bottom-up strategies to this first activity can be achieved. The second activity
identify objects, classes including attributes and meth- in this strategy produces the object-oriented target sys-
ods, and relationships among classes. The resulting tem by implementing the derived object-oriented de-
object model contains sufficient detail to guide the re- sign. This second activity will not be discussed further
implementation of a system into an object-oriented lan- in this paper.
guage such as C++. Several strategies for deriving The process for deriving object models presented in
objects and classes are used. This helps to produce this paper assumes the existing source code is written
a more suitable object model than that produced by in a procedural language, such as FORTRAN. The ex-
just a single strategy. To evaluate this approach a soft- isting source code may be unstructured. The resulting

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 object model captures the static structure of a system 3.1. Preparation
by showing classes, their attributes and methods, and
the relationships between classes. In preparation for the reverse engineering activity all
source code and relevant documentation for the system
3. Object Model Derivation Process must be collected. The code is analyzed to collect ba-
sic implementation level information about the system.
Table 1suggests information to record for each module.
The ability to derive an object model from unstruc-
tured source code is based on the concepts and princi-
(A detailed description of analysis tasks and informa-
tion to collect is given in [5]. See [S]for the analysis
ples of object-oriented development approaches. Two
document completed during the case study.) The anal-
fundamental concepts are the notion of class and ob-
ysis results are recorded in an Analysis Document for
ject. A class is an abstraction of a set of entities that
use during the reverse engineering activity.
share a common structure, behavior, and relationships
to other entities. An object is an instance of a class.
Figure 2 shows a diagram of the steps in the object I Information DescriDtion
I I
model derivation process. A three phased approach is
used. The goal of the first phase (Steps 1 , 2 , and 3) is to
I Module Subroutine or function name.
identify potential objects and classes. This is achieved I File Name of source code file where I
module is defined.
by applying forward engineering style object-oriented
analysis to the system documentation together with Metrics Size (LOC), complexity, struc-
bottom-up source code analysis techniques. The result tureness, etc.
is a set of classes and objects to be considered for inclu- Parameters Explain the purpose of each input
sion in the object model. The goal of the second phase and output parameter.
(Steps 4,5, 6 and 7) is to produce well-defined classes. Purpose Describe the purpose or function-
This is achieved by evaluating the source code and sys- ality of the module.
tem information to identify attributes and methods for Variables Identify and explain each lo-
each class. This results in reasonably complete defini- cal variable. Global variables
tions for each class. The third and final phase (Steps and elements from COMMON
8 and 9) produces the final derived object model. This BLOCKS are also identified. In-
is achieved by determining the relationships between dicate whether global variables
classes and refining any inheritance hierarchies to make are used or set.
full use of the object-oriented style.
Table 1. Module Analysis Data
Evaluate Vinual Functions
Object Madel Performing this implementation level analysis helps
Determine Relationships
Between Classes
(Inheritance and Aggregation) the personnel involved in the project to become famil-
Step 8 iar with the system. Some of the analysis can be auto-
mated such as collection of metrics and cross reference
information. However, the act of trying to create a
description of each module and each data item, forces
the reengineer to develop a better understanding of the

L
source code. The knowledge gained during this task is
Source code,
invaluable during the reengineering process.
Analysis Document

Analyze SOUM code

3.2. Process Steps
Analyze application to identify potential 1ocClasses Class
knowledge to objects and classes. Step3 Mapping
identify potenrial
objects and classes.
step 2 Step 1 : I d e n t i f y Potential Classes and

+ +-
Domain
step 1

Knowledge
Oher
Documents
1
and Classes
Objects (First Approach)

The purpose of this step is to create an initial list of

potential classes and objects. The term potential indi-
Figure 2. Object Model Derivation Steps cates that these items will be considered for inclusion in
the final object model. In this step, application domain

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 knowledge and existing system artifacts are analyzed. but both use the object selection criteria to derive po-
Existing system artifacts include: existing documen- tential classes and objects. To be considered a legit-
tation, the Analysis Document (Section 3.1), and the imate class for inclusion, a potential class should sat-
source code. The results of this step (la and l b ) is a isfy all (or almost all) of the selection characteristics as
list of potential objects and classes. mentioned in Step 1. The decision for inclusion of po-
Within this step, potential classes and objects are tential classes can be subjective, and later evaluations
identified by applying Object Selection Criteria that are may cause a class to be discarded or reinstated.
defined in popular object-oriented development meth-
ods. When analyzing documents and source code com- Step 2 : Identify Potential Objects and
ments, potential objects and classes manifest them- Classes (Second Approach)
selves as External Entities, Things, Occurrences or
Events, Roles, Organizational Units, Places, and Struc- This step identifies additional potential objects and
tures (Section 3.3.3 in [7]). The selection characteris- classes by examining the flow of information between
tics that should be used to consider each potential ob- modules. Information is exchanged between modules
ject for inclusion are Retained information, Needed ser- via parameter passing and/or the use of global data
vices, Multiple attributes, Common attributes, Com- items. Knowledge about the use of parameters and
mon operations and Domain-based Requirements (Sec- global data items is produced during the source code
tion 3.3.4 in [7]). Rumbaugh (Section 8.4.2 in [13]) analysis completed prior to Step 1 l(Section 3.1). The
gives an Elimination Criteria to filter the list of poten- object identification process explained in this step can
tial classes. be used for those systems that are global data intensive.
The source code and Analysis Document are used to
aid this step. The output of this step is an extended
Step l a : Analyze Documentation
list of potential classes and objects with attributes.
Begin by examining the existing system documenta-
tion and the Analysis Document. Apply the object se- Data Shared Through Parameter Passage
lection criteria in association with any understanding
of the application domain to identify potential classes Achee and Carver describe an algorithm for identifying
and objects. Comments found in the source code are potential objects in FORTRAN-77 code [l].Each mod-
also analyzed. However, source code statements are ule is considered to be a unit of functionality, the actual
not evaluated at this time. Knowledge of the source parameters are then necessary to perform the function
of the given module. Based on these guidelines, their
code can bias the analysis with implementation spe-
algorithm seeks to obtain the smallest set of parame-
cific details. The use of the object selection criteria is
ters needed to obtain the strongest cohesive unit. This
a top-down approach. The source code will be analyzed
later using bottom-up techniques. results in the identification of both potential objects
and their methods. This algorithm can be used when
modules do exchange information via parameters.
Step l b : Evaluate Program Identifiers
Begin by examining the existing source code for mean- Data Shared Through Global Data
ingful names of variables, data declarations, and pa- In FORTRAN programs that make heavy use of global
rameters. The names of such data items can suggest data (COMMON BLOCKs), subroutines may contain
potential objects or classes. However, recognizing that few or no parameters. In such cases, potential objects
a name is meaningful depends on knowledge of the ap- and classes can be identified based on the organization
plication domain and source code. Table 2 suggests of, and information about, the global data (i.e COM-
sources of potential objects and classes. The first col- MON BLOCKs in FORTRAN). The data item passed
umn suggests categories of variables and data types via COMMON BLOCKs in FORTRAN and the mod-
that might be useful. The second column suggest cat- ules that access these global data items are candidate
egories of variables that are not good sources. Finally, encapsulations that can be mapped to classes and ob-
column three recommends where to look for potential jects.
class attributes. The usage of COMMON BLOCK elements within
It should be noted that it is the use of domain knowl- different modules must be determined. Sometimes the
edge in conjunction with the object selection criteria organization of a COMMON BLOCK bears a resem-
that helps to identify potential classes and objects. blance to a class declaration. The grouping and usage
Steps l a and l b analyze different information sources, patterns of COMMON BLOCK elements can suggest

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 Class Sources Attribute
Consider ' ' Do Not Consider Sources
Input variables and data types. Loop v&iables - Counters, ' ' Conditional variables and their
data types.
Output variables and data types. Temporary storage variables. Value specific variables and con-
stant data types.
Array names. ' "' Debugger specific variables. Variables and data types repre-
senting different states.
Global data declarations (COM- Buffers.
MON BLOCKS) and variables.
Actual parameters. Formal parameters.

Table 2. Sources of Classes and Attributes

potential objects and classes. The syntax of COMMON To identify concrete classes wd consolidate dupli-
BLOCKS can be analyzed to detect potential objects cate classes and objects the results of Steps 1 and 2
and classes. For example, consider the following COM- must be compared and evaluated. For example, con-
MON BLOCK: sider tbe ADVS COMMON BLOCK discussed previ-
ously. This block is a potential class with Chree at-
COMMON /ADVS/ ALNT, AROOM(4), ASTREN(4) tributes. In addition, this class may have several in-
stances, but these instances (i.e. objects) are unnamed,
Potential Class Name : ADVS based on the results of Step 2. Whereas, the top-down
Potential Object Instances : 4 approach used in Step 1 may have identified several
potential objects by name but not described specific
The above declaration is similar to a class declara-
attributes. The problem becomes how to associate the
tion. The name of the block, ADVS represents a class
concept (i.e. object name) identified in Step 1with the
declaration. The arrays, AROOM and ASTREN are
attribute groups identified in Step 2. Domain knowl-
potential attributes. The size of each array suggests the
edge and the Analysis Document can be used to estab-
number of object instantiations of this potential class.
lish such associations.
The element ALNT is also a potential attribute. How-
ever, that fact that ALNT is not an array raises ques- Potential objects that do not seem to be instances
tions. Further evaluation of the potential attributes of any potential class identified thus far must be re-
in later steps may determine that ALNT is implemen- evaluated. First, compare such an object to the candi-
tation specific leading to its removal from the ADVS date abstract classes. An unmapped object may prove
class. to be an as yet unrecognized instance of such a class.
Second, if necessary, a new class can be created based
on that one object.
Step 3 : Map Candidate Objects To
Candidate Classes These first three steps try to be exhaustive in the
identification of potential objects and classes. It is not
useful at this point to reject potential objects or classes
The purpose of this step is to organize the list of
that have small overlaps or violate good information
potential objects and classes identified in Steps 1 and
hiding practices. Liu and Wilde in their approach to
2. Within this step four issues are addressed. First,
identifying objects suggest that the fuzziness in the def-
concrete classes are recognized by determining which
inition of potential objects and classes might be the
objects are instances of those classes. Second, dupli-
result of undesirable characteristics in the underlying
cate classes and objects identified during Steps 1 and 2
design [12]. The emerging object model will be refined
are detected and consolidated. Third, potential classes
in later steps.
to which no objects can be associated are recognized
as candidate abstract classes. Finally, objects that do
not seem to be an instance of any potential class are Step 4 : Identify Attributes
re-evaluated. The result of this step is a list of potea-
tial concrete and abstract classes, where each object is The purpose of this step is to identify a list of PO-
recognized as an instance of a specific concrete class. tential attributes for each class recognized in Step 3.

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 Class attributes are characteristics that are used by Evaluate Module Cohesion
every instance of that class (i.e. objects). Different in-
The first task is to examine the cohesion of the pro-
stances of the same class may have different values for
gram modules. A cohesive module performs a single
a given attribute. Some potential attributes may have
function. There may be cases when functions in the ex-
been identified during Steps 1 and 2, however, the iden-
isting system representation may have been combined
tification of attributes is not the focus of those steps.
to form a single module. However, there may be no
Within this step, potential attributes are specifically
relevant justification for this grouping. Modules with
sought after.
low cohesion need to be identified and may need to be
To identify potential class attributes the Analy-
divided into cohesive functions.
sis Document (Section 3.1) and global data struc-
tures (i.e. COMMON BLOCKS) are further evalu-
ated. The descriptions of global variables (i.e. COM- Classify Functions
MON BLOCKS) and function parameters in the Anal- Modules become one or more cohesive functions and
ysis Document are analyzed using an Attribute Selec- these functions will later become methods in class def-
tion Criteria, such as the criteria given by Rumbaugh initions. Once this list of functions has been identified,
(Sections 8.4.6-7 in [13]). Attribute Selection Criteria the next task is to classify each function by examining
given by any other Object-Oriented methods can also the data items manipulated and using knowledge of the
be used to aid this process. application domain. Possible function categories are:
The attributes for the classes identified in Step 2 are
derived from the COMMON BLOCK structures asso- Behavior Functions (BFNs) : Functions that can
ciated with those classes. Using the example given in be encapsulated as a method within a specific
Step 2 to identify the class, ADVS from the COMMON class.
BLOCK:
Association Functions (AFNs) : Functions that
COMMON /ADVS/ ALNT, AROOM(4), ASTREN(4) can be associated with more than one class. Such
Potential Class Name : ADVS functions represent associations between these
Potential Object Instances : 4 classes.
Potential Attributes : AROOM, ASTREN, ALNT Unassigned Functions (UFNs) : Functions that
cannot be readily identified as belonging t o either
Here every element in the COMMON BLOCK be-
of the above categories.
comes a potential attribute for that class. Since at-
tributes in the COMMON BLOCK should be a char- A “Behavior Function” is identified when there ex-
acteristic of every object instance of the class that is ists a function that manipulates (uses or sets) data
represented by this COMMON BLOCK, any non-array items associated with a single specific class.
element may seem counter-intuitive at this point to be An “Association Function” is identified when there
an attribute. It is better to record all candidate at- exists a function that manipulates (uses or sets) data
tributes at this point. A process to eliminate unwanted items associated with more than one class. Potential
attributes is given in Step 7a. association functions should be re-inspected for cohe-
Recognizing and assigning attributes to classes is not sion. It may be possible to further divide such a func-
a straight forward activity. Further, it can be strongly tion into sub-functions that can each become individual
affected by an understanding of the application do- methods.
main. Potential attributes can be easily found in the An “Unassigned Function” is recognized when there
source code, but assigning them to classes is more com- exists a function that uses none of the data items as-
plex. Fortunately, attributes seldom affect the basic sociated with any class.
structure of a problem 1131. Descriptions of modules recorded in the Analysis
Document can be used to help classify functions. Such
Step 5 : Identify Methods descriptions, if done properly, will explain the seman-
tics of a module. This information is useful for classi-
The modules in the existing system are analyzed to fying a module as a particular type of function.
identify methods (also, called operations) to be associ-
ated with classes. In some cases, an entire module may
Identify Potential (Pure) Virtual Functions
be treated as a method. Other times, different pieces
of functionality within a module will be separated to The final task in identifying methods is to examine
form different methods. the functions to detect potential pure virtual functions.

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 Pure virtual functions are defined within an abstract Step 7 : Refine Class Definitions
class. This abstract class acts as a base class in an in-
heritance hierarchy from which other concrete derived The purpose of this step is to evaluate and refine
classes inherit and are instantiated. The subclasses im- the collection of attributes and methods that have been
plement their own version of a virtual function. Such assigned to each class. This is done in two sub-steps.
functions aid in choosing the appropriate implementa-
tion of the function at run time (polymorphism). Step 7a : Refine Attributes
To identify potential virtual functions, analyze mod-
ules that have several implementations of the same op- Some of the attributes identified thus far may be im-
eration. Such modules typically invoke a particular plementation specific, i.e. dependent on the existing
implementation of a common operation based on some source code. There are several potential causes for this
condition. Computed GOTO’s in FORTRAN are a situation including the fact that attributes are derived
typical source of potential virtual functions. Such func- from program identifiers. All attributes assigned thus
tions resemble polymorphic behavior in the object ori- far to a class must be re-examined. The results of the
ented paradigm. software analysis done prior to Step 1 along with any
A separate list of potential virtual functions should application domain knowledge can be used to help iden-
be made. The feasibility of implementing these as vir- tify additional attributes or eliminate implementation
tual functions will be examined in Step 9. dependent attributes.
The final result of this step is a Function Classifica- Global (COMMON BLOCK) data declarations in
tion Table. This table contains the name of each func- FORTRAN have patterns that can be analyzed to elim-
tion and the class(es) with which it is associated. A inate potential implementation specific attributes. The
BFN will have a single class corresponding to its name global data declaration in FORTRAN has the following
in the table. An AFN will have two or more classes forms that are of significance to us in identifying classes
corresponding to its name in the table. A UFN will be and attributes : (A) Common blocks that have arrays
be associated with no class. Potential virtual functions of data variables, and (B) Common blocks that do not
should be marked as well for later consideration. have any data variable arrays. For example, COM-
MON BLOCKs with the former form can be used to
identify attributes.
Step 6 : Re-evaluate Unassigned Functions
COMMON /ADVS/ ALNT, AROOM(4), ASTREN(4)
The purpose of this step is to removed unassigned
functions from the emerging object model. Such func- An analysis of this COMMON BLOCK might re-
tions exist at this point because they could not be read- veal that ADVS can be modeled as a class. The el-
ily encapsulated within a class. However, it is not desir- ements AROOM and ASTREN are attributes of that
able to have independent (i.e. orphan) functions within class. The pair AROOM(i) and ASTREN(i) denote ob-
the resultant object model. Each unassigned function jects or instantiations of this class. The element ALNT
can be handled in one of several ways. may turn out to be a constant value that holds the
maximum array size. Therefore, ALNT is implementa-
1. Review the application domain knowledge to de- tion dependent and is not a potential attribute. There
termine whether the unassigned function can be may be cases where an attribute may have the same
added as a method to an existing class. value across all object instances and used by the class
methods to provide some functionality. Such attributes
2. If the unassigned function is called by another should be retained.
function that has already been assigned as a On the other hand, a COMMON BLOCK of the
method to a class, add the unassigned function latter form shown below may serve to identify elements
to that class as a private method. that should not be modeled as class attributes.

3. Create a new class and encapsulate the function COMMON /INDEX/ GUNK, GARLIC, SWORD
as a method for this class. Use this approach only
if the creation of this new class will enhance the The COMMON BLOCKs of the latter form do not
object model. have data arrays. Keeping the definition of an attribute
in mind (given in Step 4), they cannot be used by a
The result of applying this step is to eliminate the list class that has more than one object instance. An anal-
of unassigned functions. ysis of the source code may reveal that each element in

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 such a global data is used as a constant literal value. functions in the object model. This step occurs last,
However, their names do serve to help identify poten- since it is necessary to first refine the class definitions
tial objects. and identify inheritance relationships (Steps 7 and 8).
Another useful guideline are those variables that are The result of applying this step is to assign virtual
packaged in a COMMON BLOCK, and still not used functions to abstract classes as deferred polymorphic
or set in the methods associated with class that this methods.
BLOCK represents. This could be the result of an ex- One approach to determine if a function is virtual is
isting system implementation dependency and should to examine COMPUTED GOTO statements in FOR-
not force the new design to retain all of the COMMON TRAN code. A function is said to be polymorphic in
BLOCK variables as attributes. nature if in a construct:
GOTO (100, 200, 300) A
Step 7b : Refine Methods
Association functions identified in Step 5 can be as- 100 a . I .

signed to one of several different classes. Each asso-

ciation function must be assigned as a method to a
single class. The choice of which class to assign such a 200 . . * I

function is dependent on the application and the judg-

ment of the designer. One guideline that can be used
to determine which class to associate with a function is 300 ....
the direction of association. The class that is acted on (a) “A” is an attribute of a superclass or an abstrakt
should encapsulate the function as a public method. class that has already been identified and (b) the FOR-
TRAN statements at the specific line numbers (i.e.
Step 8 : Determine Class R e l a t i o n s h i p s 100, 200, 300) can be represented as member functions
associated with the subclasses of the superclass.
The purpose of this step is to evaluate and improve
the emerging object model. At this point, potential LOGICAL FUNCTION RAPPLI (RI)
classes and their methods have been identified. Ob-
jects, i.e. instances of these classes, have also been COMMON /ROOMS/ RLNT, RDESC(S), REXIT(3)
identified. These classes need to be examined to iden-
tify possible inheritance and aggregation relationships GOTO (100, 200, 300) RI
that might exist.
Inheritance is used to abstract common functions 100 RNUM = RI
thus eliminating redundancy in the object-oriented de- C ROOM DESCRIPTION FOR KITCHEN
sign. Aggregation between classes is recognized by an- IF(qOPEN(WIND0)) WFLAG * 1
alyzing the “consists-of” relationship among classes. It CALL WINSUB(WFLAG)
should be noted that aggregation is a specialization of RETURN
association and hence there may be cases when an ag-
gregation is mapped into an association relationship. 200 RNUM * RI
The designer must judge whether to leave a “consists- C ROOM DESCRIPTION FOR LIVING ROOM
of” relationship between classes as an association rela- IF(QOPEN(DO0R)) DFLAG = 1
tionship or to model the relationship using aggregation. CALL DSWB (DFLAC)
The result of this step is a consolidated set of classes RETURN
that make use of inheritance relationships and aggre- 300 ....
gation. In addition, the expected instAnntiations (i.e. The module, RAPPLI(R1) is called with various Val-
objects) of each class are stated. ues of RI (1, 2 or 3) which causes control to be trans-
fered to a particular function in the module. Each
Step 9 : Re-evaluate Potential (Pure) function performs a different action but the concept
Virtual Functions behind each function is the same. Hence, a method
that represents this concept can be included in a base
The purpose of this step is to evaluate the virtual class and sub-classes that inherit from that class can
functions identified in Step 5 . The intent is to deter- provide their own implementation of this function. A
mine whether these functions can be included as virtual similar way to identify polymorphic behavior from an

10

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 existing system with a procedural program representa- of such a complex class hierarchy and a plethora of
tion is addressed by Silva-Lepe [ll]. COMPUTED GOTO statements present in the ex-
isting system, several virtual functions were present
3.3. An Object-Oriented Design in the object-oriented design that exhibited polymor-
phism (six virtual functions that had as many as 127
The process steps described in Section 3.2 and shown different implementations). To validate the derived ob-
in Figure 2 can be iterated to polish the information ject model, the class declarations and parts of the tar-
produced by each step. Iteration is done to make use of get system were implemented in C++.
improved knowledge and understanding of the system The experience gained by applying this process
and its emerging object model. helped to identify several important lessons. First, the
With the completion of Step 9 the object model for preparation activity (See Section 3.1) was viewed as
the system is now ready. This model can be represented a key factor in the success of the project, This was
using any of several diagramming notations, such as a tedious activity to perform manually. However, the
that used by OMT [13]. Because the model has been analysis results proved to be invaluable. The knowl-
derived from source code, it is possible to construct edge and understanding of the system gained by per-
either class diagrams or instance diagrams. forming the analysis was useful when conducting later
steps. Second, the use of both top-down and bottom-
up strategies (Steps 1 and 2) to identify potential ob-
4. Case Study
jects and classes contributed significantly towards the
construction of a meaningful object model. Bottom-
The object model derivation process, described in up object identification was difficult due to the un-
the previous section, was applied within a reengineer- structureness of the code and its heavy dependence on
ing case study. The goal of the case study was to reengi- COMMON BLOCKs for information passing. Finally,
neer an old unstructured FORTRAN application into the emerging object model served to improve under-
a C++ implementation with an object-oriented archi- standing of the existing system. This improved under-
tecture. A full report on the case study and results is standing aided with further refinements to the object
given in [15]. model. The final object model presented a clear repre-
The existing system, d l e d Dungeon, was an old sentation of the system and its components.
adventure-based game. This system was developed in
the mid-1970’s in a language called MDL and origi-
nally ran on a PDP-10. Later, it was translated to 5. Conclusions
FORTRAN-IV and over the years has been ported
to several platforms (PDP-11, other DEC computew, If existing software is to benefit from advances in
PC/DOS and most recently to LINUX). The system object-oriented methods, the software must be re-
consisted of two executable programs, two data files, designed and re-implemented using an object-oriented
21 FORTRAN source code files, and one C source code approach. This paper has presented a nine step pro-
file. Dungeon consisted of 96 subroutines containing cess for deriving an object model from unstructured,
a total of 5,404 LOC (executable statements). The non-object-oriented source code. The resulting object-
code was unstructured with over 1,000 GOTO control oriented design can be used to implement a new version
transfer points. Program information was passed be- of the system.
tween subroutines via COMMON BLOCKs only. Dun- Experience with applying the process suggests that
geon appears to have been developed without the use of the basic approach works quite well. The use of both
any structured development method and was deemed top-down and bottom-up strategies helps to detect
a good candidate system for a reengineering effort. meaningful objects and classes. The results produced
The object model derivation process was applied by bottom-up techniques tend to be biased by the orig-
to the existing system to produce an object-oriented inal implementation. The use of top-down strategies
design for Dungeon. The object-oriented design con- provide a basis for evaluating the bottom-up results
tained 141 concrete classes and five abstract base and help to eliminate existing source code influences
classes. The object model had several inheritance re- from the emerging object model. The sequence of
lationships and a complex class hierarchy. The class process steps produces a full object model, complete
hierarchy exhibited several tiers (levels) of inheritance. with class relationships including inheritance and vir-
The hierarchy varied from three subclasses inheriting tual functions. However, the process is tedious to ap-
from one superclass to as many as sixty subclasses ply manually. It is expected that the process will scale
inheriting from one superclass. Due to the presence up to larger systems, but automated assistance for the

11

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.
 process steps will be necessary. For instance, auto- [lo] Jacobson, Ivar; Lindstrom, Fredrik, “Re-
mated algorithms for bottom-up object identification engineering of Old Systems to an Object-
techniques and for identifying potential methods are oriented Architecture”, Conference o n Object-
required. Defining more complete guidelines and al- Oriented Programming Systems, Languages,
gorithms for conducting each step will require further and Applications (OOPSLA), ACM Sigplan
research and experience. Notices, Vol. 26, No. 11, (November 1991),
pp340 - 350.
References [ll] Silva-Lepe, Ignacio, “An Empirical Method for
Identifying Objects and Their Responsibilities
[l] Achee, B. L., Carver, Doris L., “A Greedy Ap- in a Procedural Program”, T O O L S Europe’93
proach to Object Identification in Imperative
(Technology of Object-Oriented Languages and
Code”, 3rd Workshop o n Program Comprehen-
Systems), 1993, pp. 136 - 145.
sion, Washington, D.C., November 14-15, 1994,
pp. 4 - 11. [12] Liu, Sying-Syang; Wilde, Norman, “Identify-
ing Objects in a Conventional Procedural Lan-
[2] Booch, Grady, Object- Oriented
guage: An Example of Data Design Recov-
Analysis and Design with Applications, Ben-
ery”, Conference o n Software Maintenance, San
jamin/Cummings, Redwood City, CA, 1994.
Diego, CA, November 26-29,1990, pp. 266 - 271.
[3] Byrne, Eric J., Gustafson, David A., “A Soft-
ware Re-engineering Process Model,” Computer [13] Rumbaugh, James; Michael Blaha, William
Software €d Applications Conference (COMP- Premerlani, Frederick Eddy, and William
S A C ) , Chicago, IL, September 21-25, 1992, pp. Lorensen, Object-Oriented Modeling and De-
25 - 30. sign, Prentice Hall, Englewood Cliffs, New Jer-
sey, 1991.
[4] Byrne, Eric, J., “A Conceptual Foundation for
Software Re-engineering,” Conference on Soft- [14] Sneed, Harry M., “Migration of Procedurally
ware Maintenance, Orlando, FL, November 9- Oriented COBOL Programs in an Object-
12, 1992, pp. 226 - 235. Oriented Architecture,” Conference o n Software
Maintenance, Orlando, Florida, November 9 -
[5] Byrne, Eric J. Generating Process Models for 12, 1992, pp. 105 - 116.
Software Reengineering Projects, Ph.D. Disser-
tation, Department of Computing and Informa- [15] Subramaniam, Gokul V., Reengineering of an
tion Sciences, Kansas State University, 1993. Unstructured System to an Object Oriented Ar-
chitecture, Master’s Project Report, Depart-
[6] Byrne, Eric J., Subramaniam, Gokul V., Gum- ment of Computer Science and Engineering,
makonda, Muralidhar, PROMISE Reengineer- University of Texas at Arlington, 1995.
ing Project: Dungeon V2.52 - Analysis Doc-
ument, Department of Computer Science and [16] Tan, Hee Beng Kuan; Ling, Tok Wang, “Re-
Engineering, University of Texas at Arlington, covery of Object-Oriented Design from Exist-
TR-CSE-96-001, 1996. ing Data-Intensive Business Programs”, Infor-
mation and Software Technology, Vol. 37, No.
[7] Coad, Peter; Yourdon, Edward, Object-
2, (February 1995), pp. 67 - 77.
Oriented Analysis, Yourdon Press Computing
Series, Yourdon Press, (2nd Ed.), Englewood
Cliffs, New Jersey, 1991.
[8] Canfora, G., Cimitile, A., Munro, M., “An
Improved Algorithm for Identifying Objects in
Code,” Software - Practice and Experience, Vol.
26, No. 1, January 1996, pp. 25 - 48.
[9] Colbrook, A., Smythe, C., Darlison, A., “Data
Abstraction in a Software Re-engineering Ref-
erence Model,” Conference on Software Main-
tenance, San Diego, CA, November 26-29,1990,
pp. 2 - 11.

12

Authorized licensed use limited to: N.C. State University Libraries - Acquisitions & Discovery S. Downloaded on January 13,2023 at 23:45:16 UTC from IEEE Xplore. Restrictions apply.