In Proceedings of the 5th Working Conference on Reverse Engineering, Oct. 1998, pp.

125-134,
IEEE.

PACK R AT: A Software Reengineering Case Study

Gerald C. Gannod Gora Sudindranath, Mark E. Fagnani
Computer Science and Engineering and Betty H. C. Chengy
Arizona State University Computer Science and Engineering
Box 875406 Michigan State University
Tempe, AZ 85287-5406 3115 Engineering Building
East Lansing, MI 48824-1226

E-mail: fgannod,sudindra,fagnanim,chengbg@cse.msu.edu

Abstract Software reverse engineering is the process of analyz-

ing the components and component interrelationships of
Reengineering is the process of examination, under-
a software system in order to describe that system at a
standing, and alteration of a system with the intent of im- level of abstraction higher than that of the original sys-
plementing the system in a new form. Many approaches tem [2]. Reengineering is the process of examination, un-
for design recovery or reverse engineering have been sug-
derstanding, and alteration of a system with the intent of
gested, most with some type of support tool. Since a implementing the system in a new form [2]. Software
project’s time constraints may prohibit use of sophisticated reengineering is considered to be a better solution for han-
techniques and/or tools due to the learning curves associ- dling legacy code when compared to re-developing soft-
ated with the techniques and tools, methods that can be ap- ware from the original requirements.
plied in lieu of complex support tools may be required. This
This paper presents a case study that illustrates how a
paper describes a case study project involving the reengi- combination of object-oriented (OO) and structured analy-
neering of a network application used by Texas Instruments sis and structured design (SA/SD) techniques can be used
to monitor network traffic in a local area network.
in tandem to reengineer an existing application that is used
1 Introduction by Texas Instruments to analyze traffic on local area net-
works. The remainder of this paper is organized as fol-
Software maintenance is considered to be the most lows. Section 2 presents background information regard-
costly phase of the software lifecycle. It has been estimated ing software maintenance and software reengineering. The
that approximately 60 percent of the effort in software de- application and domain are described in Section 3. The
velopment is in software maintenance [1]. Given that soft- methods used for software reengineering are introduced in
ware maintenance is an inevitable activity, successful soft- Section 4 and applied in Section 5. Section 6 describes re-
ware maintenance of large systems depends on several fac- lated work, and Section 7 draws conclusions and suggests
tors including the existence of accurate documentation of further investigations.
the system design. In some cases, software and documen-
tation fail to be consistent in that the documentation, and 2 Background
subsequently the designs, are rarely updated to reflect mod- This section gives background information in the area of
ifications made to the system. In other cases the original software maintenance and semi-formal analysis and design
system does not have any type of existing documentation techniques.
and, as such, any rationale behind the decisions made dur-
ing the implementation of the system are lost. In either
2.1 Software Maintenance
case, the lack of a consistent design has many impacts on Figure 1 contains a graphical depiction of a process
the effectiveness of any efforts to maintain and modify ex- model for reverse engineering and reengineering [3]. The
isting systems. process model is captured by two sectioned triangles,
where each section in a triangle represents a different level
This work was performed while this author was a Ph.D. student at
of abstraction. The higher levels in the model are concepts
Michigan State University. and requirements. The lower levels include designs and im-
y Please address all correspondences to this author. plementations. Entry into this reengineering process model
begins with system A, where Abstraction (or reverse engi- internetworking protocol stacks [8]. In this section we de-
neering) is performed to a level of detail appropriate to the scribe the original PACK R AT system, and then the modi-
task being performed. For instance, if a system is to be fications that were required due to the changing needs of
reengineered in response to efficiency constraints, then ab- Texas Instruments.
straction to the design level may be appropriate. This task
can also be considered a process of design recovery. The 3.1 Original System
next step is Alteration, where the system is configured into
a new form at the same level of abstraction. Finally, Re- PACK R AT is a network traffic monitoring application
finement of the new form into an implementation can be that was implemented for the Microsoft Windows 95 en-
performed to create system B. vironment. The original system implementation provided
a facility for communicating with the network interface
Alteration
driver via the Windows 95 Network Device Interface Spec-
ification (NDIS) interface. A graphical user interface
‘‘Reverse Engineering’’ Concept ‘‘Forward Engineering’’ (GUI) provided users with options for analyzing Medium
Abstraction Refinement Access Control (MAC) layer statistics, such as type and
Requirements
number of frames captured per second. Additional op-
Design erations facilitated examination of decoded data captured
Implementation
from the network. No system documentation existed for
System A System B
the development of the original PACK R AT system. The
source code for this system was approximately 5,500 lines
Figure 1: Reverse Engineering Process Model of code and supported several users from the software de-
velopment team at the Texas Instruments Network Busi-
This paper describes a case study investigation into the ness Unit.
reengineering of a network application. The context of
the investigations are applicable to all phases of the Byrne 3.2 New Requirements
reengineering process model [3] and span all levels of ab-
straction. Several modifications of the PACK R AT system were
2.2 Semi-Formal Analysis and Design requested by the customers and consisted primarily of
changes to two specific areas: user interface changes and
Object-oriented development techniques encompass network packet decoding enhancements [8]. The more sig-
analysis, design, and implementation. The Object Mod- nificant modification requirements for PACK R AT involved
eling Technique (OMT) [5] is commonly used in indus- support for the decoding of several Transmission Control
try and academia. OMT comprises three complementary Protocol/Internet Protocol (TCP/IP) application protocols
models, each of which are simple to use and understand. such as Simple Network Management Protocol (SNMP)
The object model describes the static, structural aspects Version 1, Telnet, and Domain Name Service (DNS).
of the system. The object model captures the objects of The user interface changes dealt with visual presentation
the system and the relationships between the objects. The and ease of use issues, including the translation and dis-
dynamic model depicts the temporal and behavioral as- play of numeric and character-based Internet Protocol (IP)
pects of the system. Finally, the functional model describes addresses as well as Organizationally Unique Identifiers
the services provided by the system. Respectively, entity- (OUIs). In this paper we focus primarily upon the reengi-
relationship diagrams, state transition diagrams, and data neering of the network packet decoding functionality since
flow diagrams are used to represent the object, dynamic, the modifications, from a reengineering point of view, were
and functional models, and each model is only used to more significant with respect to design recovery and sys-
capture a specific perspective of the system. With recent tem re-implementation.
work [6, 7], rigorous analysis of each of the models is pos- In addition to the requirements described above, sev-
sible, thus enabling consistency and completeness checks eral constraints were placed on the reengineering project.
at the model level prior to the implementation phase. These constraints were largely environmental; the original
3 Application PACK R AT tool was implemented in the C programming
language for Intel-based machines running the Windows
The PACK R AT tool monitors network traffic in order 95 operating system. One of the constraints on the project
to provide debugging information to developers during the was time-based; the project from original proposal to de-
development of Ethernet drivers [8]. Currently, the PACK - livery was limited to fifteen weeks, where all five members
R AT tool is being used to investigate the development of had other commitments in addition to this project.
3.3 Reengineering Development Team The method used to perform the case study described in
this paper is based on a combined top-down and bottom-up
The reengineering development team consisted of five approach for design recovery. Recent investigations have
members, each of varying levels of software engineering suggested that this kind of approach is reasonable [11, 12].
experience. Although each member had experience with For this project, the technique used for design recovery
OMT, they had limited exposure to software maintenance involved three distinct steps. First, a high-level concept
and reengineering. As such, a short tutorial on the methods model for the system was developed and refined based on
for reengineering was required. The methods, as described customer interviews and empirical investigations involving
in Section 4, were developed with the intention of being the existing system. Second, a low-level source model, in
lightweight in the amount of new techniques that would the form of a call graph, was constructed. Finally, an iter-
have to be learned by the developers. The primary goal of ative top-down and bottom-up abstraction and encapsula-
these techniques was to leverage the experience the team tion step was performed. In this step, the low-level models
members had obtained from previous software analysis and were abstracted into higher-level entities and then verified
design projects. against refinements of the high-level models that were con-
structed in the first step.
4 Method Many reengineering approaches have focused on the re-
In this section we present the methods used for design covery of objects from existing code [13, 14]. In order to
recovery and modification, and discuss the overall con- facilitate the recovery of an object-oriented model from the
straints on the project. existing system, the use of the OMT method was combined
with the SA/SD technique. For the high-level models of
4.1 Process Overview the system, OMT was used as the modeling notation. At
the very low-levels of design, SA/SD was used as the mod-
In the context of the reengineering process model pre- eling notation. The integrating mechanism between OMT
sented in Section 2, the investigations described in this pa- and SA/SD is the data-flow diagram, a model used by both
per are depicted by the diagram shown in Figure 2. Specif- techniques. As such, the developers found this approach to
ically, this paper describes a case study that involved three be sufficient and effective.
distinct phases of investigation: 1) a design recovery, or ab- Although many tools exist that support the activities
straction step, 2) a design modification, or alteration step, described above, including Rigi [15], and the Reflexion
and 3) a design implementation, or refinement step. In the Model (RM)-Tool [11], it was determined that due to time
diagram, the phases are depicted by the dashed arrows that constraints and to avoid the learning curve associated with
originate from the implementation level to the design level using a new support tool, that a simple source code browser
in System A, from the design level of System A to the de- would be used to derive the source models, and that the en-
sign level of System B, and from the design level of System capsulation of models into higher-level entities would be
B to the implementation level of System B, respectively. performed manually. In retrospect, as described in Sec-
tion 5.4, the developers found that the results obtained due
Concept to this decision were the source of some confusion about
the functionality represented by the recovered design.
Requirements
4.3 Design Modification
Design

Implementation The primary goal of the method described in Section 4.2

System A System B
is to provide developers with a detailed understanding of
the existing system. With this understanding, the develop-
Figure 2: Project Context Diagram ers could then modify the existing design in such a way that
would facilitate the incorporation of the requested modifi-
4.2 Multi-level Approach to Design Recovery cations to the system.
The next step in the process was to change the design
Several techniques have been suggested for recovering of the current system by analyzing the modification re-
designs from existing systems. These techniques range quirements requested by the project customer. These re-
from formal approaches [9], to semi-formal functional ab- quirements allowed the developers to identify the context
straction [10], and structural abstraction [11]. The repre- for the requested modifications and to focus their efforts
sentations constructed by these techniques are often biased on impacted subsystems. Specifically, this step involved
by the implementations, and as such, do not always corre- three distinct phases. First, a requirements analysis was
spond to existing high-level models. performed that addressed the new requirements for the sys-
tem. Second, an impact analysis was performed on the re- Figures 3 and 4 depict the high-level object and func-
covered design to identify the parts of the system that were tional models of the PACK R AT system, respectively. Fig-
to be modified based on the new requirements. Finally, the ure 3 is the model of the various objects extracted from the
recovered design was modified in order to incorporate the system based on empirical observations and developer in-
new requirements into the functionality of the existing sys- terviews. The object model shows classes as labeled rect-
tem. For each of these phases, analysis and modeling were angles and relationships between classes as lines. In the
performed in the context of the OMT notation. notation, the diamond symbol at one end of a line is used
4.4 System Modification to indicate an aggregation relationship. As indicated by
Figure 3, PACK R AT is an aggregation of global data and
Modification of the recovered designs to incorporate various GUI components (i.e., Frame Window, View Win-
new requirements is referred to as the alteration step [3]. dow, etc.).
After a design has been altered to incorporate new re-
quirements or constraints, traditional software develop- PackRat
System
ment techniques can be used to develop the code that sat-
isfies the modified design. An implicit constraint in the
development phase of the project was to reuse the existing Frame Globals
Window
source code. In addition, the system was to target the same
operating system (Windows 95) and source language (C). View
Window
5 Case Study Details
In this section we summarize the application of the MDI Frame Dialog Box Menu Windows
Window Control Toolbar
methods described in Section 4 as they were applied to the
PACK R AT system.
MDI Child Windows
5.1 Design Recovery Window Toolbar
Button
As mentioned previously, the design recovery phase of Figure 3: High-level Object Model
PACK R AT consisted of three distinct steps: creation of
a high-level concept model, construction of a low-level
A functional model, or data flow diagram, uses circles
source code model, and finally, a top-down, bottom-up
to denote process, labeled arcs to denote data flow, labeled
refinement of the resulting models until a medium-level
parallel lines to denote data stores, and rectangles to indi-
model was derived. The first two steps were performed
cate external entities or actors. Figure 4 is a data flow dia-
concurrently; the iterative third step was completed after
gram that shows three high-level PACK R AT modules: Win-
both high-level and low-level models were constructed.
Main, Core Process, and Core Process Management. Win-
5.1.1 High-Level Models Main is the primary driver for PACK R AT and is responsi-
The high-level concept models for the PACK R AT sys- ble for the initialization of GUI components and acting as a
tem were constructed using two sources of information. communication mechanism between the GUI components
The first source of information was a result of data collec- of the application. Core Process is another major compo-
tion from an empirical analysis of the existing system. This nent of the system that handles all output interaction with
consisted of operating PACK R AT in a manner similar to the user, performs all data manipulation associated with
that of the typical user population and observing the output processing packets, and interacts with the network device.
of the system. For instance, a typical scenario would con- Core Process Management is primarily concerned with the
sist of selecting a network device, capturing packets, and initialization and termination of the system.
then viewing decoded information (output). From observ- 5.1.2 Low-Level Model
ing the various types of output of the system, the develop-
ers were able to abstract the output into classes that shared The low-level source model, shown in Figure 5, depicts
common characteristics (i.e., output in the same window, the call graph of the original PACK R AT system. In the dia-
output at the same time, etc.). gram, a vertex represents a function, with the lines between
The second source of information that was used to con- vertices indicating a calling relationship. Specifically, a
struct the high-level models was data gathered from inter- vertex B connected by a line to another vertex A, where B
views with the developers of the original software. How- lies below A in the graph, is called-by A. Using a source
ever, in gathering design information from the original de- browser (i.e., a program that facilitates hypertext source
veloper, a conscious effort was made to recognize imple- code traversal, where procedure calls serve as hypertext
mentation bias. links), the developers constructed a call graph that repre-
 WinMain
InitApplication
InitInstance
LoadWindowPos

LoadConfigVals

HexDumpWndProc

DecodeWndproc

DebugWndProc
MainWndProc
TBFrameProc

ListWndProc
CleanUp

DlgConfigCapture
GetConfigString

SaveWindowPos

PostQuitMessage

DisplayTypeStats

DisplayNdisStats
SaveConfigVals

WritePacketFile

HavePacketData

ReadPacketFile

DisplaySizeStats

DoNewList
DlgOpenNDIS

DoHexDump
SavePackets
UpdateStatus

StopCapture

StartCapture

LoadPackets
NewFrame

CloseNDIS

DoDecode
SetTimer

KillTimer

DlgAbout
SetConfigString

PktReturnRxBuffer

InitGetPacket
RecordStats

PktGetErrorCode
PassFilter

OpenNDIS
NewList

PktcloseNDIS

DecodeBPDU

Summarize
PrintError

ClearStats

DecodeType
EndDialog
wsDlgInit

PktOid
time
PktGetRxBuffer

PktOpenNDIS

InitDriverList

SummarizeMac
SummarizeType
DecodeARP

DbgPrintf
DecodeIP

SummarizeARP

SummarizeIP
DecodeICMP
DecodeTCP
DecodeUDP

SummarizeUDP

SummarizeICMP
SummarizeTCP
Figure 5: System Call Graph

dles events for the main window), ListWinProc (handles

User events for the List Window), DebugWinProc (handles
User events for the Status Window), HexDumpWinProc (han-
Program Output
Input
dles events for the Hex Dump Window), and DecodeWin-
message Proc (handles events for the Decode Window). Most of the
Core
WinMain
Process data processing for PACK R AT occurs in functions called by
message
initialization these event handlers, as can be seen in Figure 5.
data
acknowledgement frames
registry
After analyzing the various event handlers, it was de-
data
Core Process
Registery Network
termined that two particular routines, the ListWinProc
Management
registry
data
and DecodeWinProc, had redundant behavior. These two
event handlers were responsible for decoding packets that
Figure 4: High-level Functional Model were related to the packets listed in separate windows. The
ListWinProc performed decoding on packets for a scrol-
sents the entire PACK R AT system. The call graph served lable list used for selecting packets. Information for each
as the entry point for the low-level reverse engineering and entry in the list included packet size, source/destination IP
design recovery process. address, and an index uniquely identifying that packet. The
The root module in the hierarchy of Figure 5 is Win- DecodeWinProc performed more extensive decoding on
Main, which maps directly to the high-level concept model packets that were selected from a different scrollable list.
(in Figure 4). Below WinMain, there exists a number of The decoded information had a dependency on the proto-
functions devoted to handling events for a particular win- col of the selected packet, but there were fields that were
dow in the GUI. Among these are MainWinProc (han- similar to fields decoded by the ListWinProc handler such
as frame type, source/destination IP address, size of packet,
and transport layer protocol, among others. Packet
Global data was a particularly prominent feature of User Files
program output
packet info
the PACK R AT system and consisted of various items that packet info
packet info
were critical to the operation of PACK R AT. Among such
user input Network
data were the capture buffer or Frame List that was used debug info,
Children message Main franes
to store captured packets, various packet statistics, and Window
message Window
Process frame index, Process
a pointer to the most recently captured frame. Figure 6
message
shows an object model of a subset of the global data items. message
The object modeling of the global data provided a level WinMain message selection value
message
of abstraction that facilitated the use of global data as
“classes”, thus providing a disciplined policy for access ack
instance selection value
and modification of the global data. This model became handle
of particular interest during the modification phase, as de- config Global config
Shutdown
Startup Data
scribed in Section 5.2.1.
registry
update registry
5.1.3 Medium-Level Model update
registry System
data Registry
The next step was to construct a medium-level design
model from the high-level concept and low-level source
models. The approach involved two concurrent tasks: ab- Figure 7: Medium Level Data Flow Diagram
straction of the low-level source model of Figure 5 into
higher-level entities, and refinement of the high-level con-
cept model in Figure 4 into lower-level entities. Both of
WinMain
these tasks were performed iteratively until they resulted
Startup

WinMain
in a single, medium-level model. The result of these activ-
ities is shown in Figure 7.

InitApplication
InitInstance

There were several levels of abstraction between the

medium-level and low-level models. Due to space con-
LoadConfigVals
LoadWindowPos

MainWndProc

straints, we focus on only one intermediate level of abstrac-

TBFrameProc

HexDumpWndProc

DecodeWndproc

DebugWndProc
CleanUp

ListWndProc
tion. Figure 8 shows the relationship between the medium-

DecodeFrame
level (Figure 7) and low-level models (Figure 5), where the
SaveWindowPos

DlgConfigCapture

DisplayTypeStats

DisplaySizeStats

DoNewList
GetConfigString

SaveConfigVals

WritePacketFile

HavePacketData

ReadPacketFile

DlgOpenNDIS

DisplayNdisStats
SavePackets

DoHexDump
UpdateStatus

StopCapture

StartCapture

LoadPackets

DlgAbout

CloseNDIS
NewFrame

dotted lines enclosing groups of functions were abstracted

SetConfigString

into corresponding modules of the medium-level model (in

Summarize_DecodeFrame
Decode BPDU
DecodeType
PktReturnRxBuffer

InitGetPacket

DbgPrintf
RecordStats

OpenNDIS

PktGetErrorCode
PassFilter
NewList

PktcloseNDIS
PrintError

ClearStats
PktOid
wsDlgInit

Figure 7).
Summarize_DecodeType
PktGetRxBuffer

InitDriverList
PktOpenNDIS

FltStrtoData

Decode BPDU
FltDatatoStr

DecodeARP

DecodeIP

DbgPrintf

RatFile
Shutdown
Summarize_DecodeIP

Main Window
Summarize_DecodeARP
DecodeICMP

DecodeTCP
DecodeUDP

RatFile RatFile Protocol Process

Header Record Frame List Structures
Summarize_DecodeICMP

Summarize_DecodeUDP

Summarize_DecodeTCP

1+ Children Window
Process
1 1+
Frame 1 Decodes

Figure 8: Call graph abstraction

Figure 6: Subset of Global Data Object Model
functions called by InitInstance were abstracted into the
Several features of the call graph in Figure 5 facilitated Startup module.
the abstraction of the various procedures into the mod- Another cue provided by the call graph was a result of
ules shown in Figure 8. First, naming conventions pro- comparing the in-degree and out-degree of a vertex. If
vided the initial cues about the partitioning of the sys- there exist vertices with a large difference in out-degree
tem into initialization routines and shutdown routines. As and in-degree, then they can be considered to be candi-
such, the Cleanup function and all functions that it di- dates for module drivers. Thus, the vertex (procedure) and
rectly or indirectly calls were abstracted into the Shutdown all of its calls can be abstracted into higher-level modules.
module. Similarly, InitApplication, InitInstance, and all Based on this criterion, MainWinProc and all of the func-
tions it calls were abstracted into the Main Window Process the Frame List. Next, the frame is decoded according to
module of the medium-level model. the protocol embedded in the frame. Finally, the decoded
The final cue that was used to abstract procedures frame data is displayed to the user.
into higher-level modules was provided by the informa- As shown in Figure 6, the original PACK R AT system re-
tion obtained from creating the high-level concept models. lied heavily on the use of global variables and direct access
Using this information, all child window event handlers to a buffer for storing raw (undecoded) frames, a technique
such as ListWinProc, DecodeWinProc, DebugWinProc, for encapsulating the old system was needed in order to
and HexDumpWinProc were abstracted into the Children avoid affecting previously implemented functionality. As
Window Process module of the medium-level model. such, an object-oriented wrapper was created in the form
The recovery of a design using reverse engineering tech- of a list that encapsulated frame-related information.
niques can facilitate many software maintenance activi- The wrapper, called the Decode List, is essentially an
ties, including the modification of systems to incorporate ordered aggregation of Decode Information nodes, each
new requirements. Using the techniques described in Sec- of which contains all of the data (decoded and otherwise)
tion 4.2, the development team found that the recovered pertaining to a particular captured frame. The Decode
design formed a solid basis for the next step of the reengi- List, shown in Figure 9, would is instantiated whenever a
neering process, the design modification phase. new set of frames is loaded into the Frame List class of the
old system. Each node is an individual object whose struc-
5.2 Design Modification
ture is based on the TCP/IP protocol stack. That is, each
This section describes the modifications needed to add node is an aggregate of structures that correspond to the
the application layer protocols to the decode ability of the layers of abstraction present in the TCP/IP protocol stack.
PACK R AT system. The technique used to introduce modi- The instances of the structures were designed as subclasses
fications into the system was based on a two-step process. and thus the exact composition of each node is dependent
First, the recovered models described in Section 5.1 were on the protocol sequence used by the frame to which it cor-
analyzed to determine what modifications, if any, could be responds. The structures that correspond to the Data Link,
made in order to facilitate the extension of system func- Network, and Transport layers contain all of the decoded
tionality. In essence, the models were analyzed in order information relating to those layers. The Application In-
to determine if any system restructuring could be used to formation class encapsulates information about the appli-
increase system extensibility. Second, the recovered mod- cation layer and contains general information about the ap-
els were analyzed to determine the impact of changes due plication portion of a frame. This information is used by
to the new decoding requirements. The impact analysis the application decode modules in their individual decode
involved determining what parts of high-level, medium- processes. In Figure 9, the Frame class corresponds to the
level, and low-level models that needed modification in or- physical layer and has a direct relationship to the frames in
der to provide the newly requested functionality. the Frame List in Figure 6. Specifically, this class serves
The proposed modifications, specifically, the addition of as a high level interface to the Frame List class of Figure 6
routines to support the SNMP, DNS, and Telnet protocols, and makes the Frame List an implicit part of the Decode
presented two major design challenges. First, a bridge be- List shown in Figure 9. In this respect the Decode List
tween the old and new systems that facilitated the use of replaces the original function of the Frame List, because
the old system as a “black box” was desired. It was deter- it mediates any interaction with the Frame List once the
mined that the existence of such a bridge would facilitate Decode List has been initialized.
the separation of new functionality from previous function- Another design challenge in the system was to sup-
ality both in concept and in the implementation. The sec- port system extensibility so that new application protocols
ond design challenge was to find a mechanism for incorpo- could be decoded by the PACK R AT system. By construct-
rating several new application layer protocols to the decod- ing the Decode List class as described above, all future
ing ability of PACK R AT that was extensible and minimized extensions could access data in a uniform manner, thus
the modifications to the structure of the system. The re- separating the functionality of the old system, the current
mainder of this section discusses each of these challenges modifications, and all future modifications.
in detail.
5.2.2 Adding Application Layer Functionality
5.2.1 Addressing the Design Challenges
Based on the requirements, the addition of application
The PACK R AT system uses a three step process for layer decoding was of primary importance. Figure 10 de-
translating and displaying network frame information to tails the upper levels of the application decode modules
users. First, frame data is captured from the network via and their place within the Decode Module. The nature of
the NDIS interface and placed into a global list, known as the interaction between the system and the decode modules
 contained in a design document constructed by the devel-
Decode List opment team [16]. The SNMP protocol is defined in such
a way that each SNMP message is an ordered collection of
Decode Information Type/Length/Value (TLV) encoded fields. While the mean-
ing and order of each field is dependent upon the message
Transport Application Network MAC Layer
type, all fields are TLV encoded. One of the challenges
Frame
Information Information Information Information this presented is that by definition all TLV encodings are
of variable length. This means that each variable length
TCP Header
Information
UDP Header
Information
IP Header ARP Header 802.3-LLC message is made up a variable number of variable length
Information Information Header Information
fields.
Figure 11 shows the object model of the SNMP Encod-
ICMP Header BPDU Header
Information Information ing class. The SNMP Encoding Object is an aggregation
of one or more TLV Encoding Objects. Each TLV Value
subclass represents the different formats of an SNMP En-
Figure 9: Decode List Object Model
coding object, thus allowing the software to facilitate the
is based on the Decode List and the output format used by issue of variable length TLV encodings. The advantages of
the display windows. A particular decode submodule is this design include encapsulation, extensibility, and strict
passed a node in the Decode List that corresponds to the adherence to the SNMP standards [17]. The design cur-
frame currently being displayed in the display windows. rently handles only SNMP version one packets, but could
Once a frame has been decoded, the submodule returns a be extended to handle version two of future versions with
text buffer that contains a formatted set of decode informa- minor modifications to the model.
tion. The text buffers from each decode module are then SNMP
concatenated and displayed. Encoding

The Decode Module of the new system contains four TLV

Encoding
separate decode modules. Each of these decode modules
are modified versions of the original decode module and
NULL Signed Numeric Unsigned Numeric String Value
correspond to three application layer protocols: Telnet, Value Value Value
DNS, and SNMP. The fourth module, Determine Applica-
tion Protocol, is used to identify the application frame type, IP Address
Value
OID Value
like DNS, SNMP, and Telnet, before the decoding process
begins. Figure 11: SNMP Object Model

Decode Decode 5.3 Implementation

Information List
Determine
Application
Protocol The implementation phase for the changes to the sys-
Application Type tem, including testing, occurred over a period of approx-
imately four weeks. The primary challenges in introduc-
Decode Summary Decode Decode
Information
ing the required modifications were related specifically to
SNMP
Decode the language and environment constraints placed on the
Information
Decode project. For instance, the language constraint placed upon
Driver
Decode
the development team was that the system be built using
Local Summary Decode
Decode
the C programming language. As such, since the devel-
Buffer Telnet Information opment team chose to perform an object-oriented analy-
sis and design of the modifications, an object-based im-
plementation using the C programming language was re-
Decode
Decode Summary
Decode Information quired.
DNS
Another explicit constraint placed on the project was
that the system be developed for the Windows 95 envi-
Figure 10: Application Decode Data Flow Diagram ronment, which was natural since the original PACK R AT
system was a Windows 95 application. This presented a
Due to space constraints, we focus on the design of the particularly significant challenge to the development team
SNMP module. Descriptions of the remaining modules are since their primary experiences had been limited to a Unix
environment. The development team emphasized the need for a sys-
The final system consisted of approximately 11,500 tematic process to recover and document the design
lines of code, a size that doubles that of the original PACK - prior to re-implementation. The development team
R AT. This fact is attributed to the complexity and number found that the design recovery process and the by-
of modifications required by the customers. The project products significantly reduced the amount of time it
was completed well within the schedule for project deliv- took to re-implement and test the system.
erables and received positive feedback from the customers Software reengineering is a very attractive method for
at Texas Instruments. making enhancements to an existing system. How-
ever, the learning curve for software reengineering is
5.4 Lessons Learned too high to perform and learn at the same. Users of the
Several lessons were learned by the reengineering de- software reengineering process must be knowledge-
velopers of the PACK R AT system. This section highlights able about the techniques and tools before applying
several of those lessons. them to a software system.
The adoption of and adherence to a systematic pro- 6 Related Work
cess for performing reengineering yielded many ben-
efits and was the primary factor in the success of the Several reengineering efforts have been reported in the
project. Specifically, literature. Neighbors [18] described an approach for con-
– The design recovery step facilitated gaining an structing reusable components from large existing systems
understanding of how the required modifications by identifying the tightly coupled subsystems contained in
fit into the context of the original system. the system. The approach is primarily based on the use of
informal and experimental methods and the main objective
– The design recovery step was useful for gaining
was to make observations about the experiences encoun-
an in-depth understanding of the PACK R AT sys-
tered with a few large systems. Lewis and McConnell [19]
tem in a short amount of time. The recovered
describe a reengineering process and its application to a
design artifacts such as call graphs, object mod-
real-time embedded system. The seven step process de-
els, and data flow diagrams, provided a mecha-
scribes high-level milestones that range from reverse engi-
nism for discovering information about system
neering and reengineering to retargeting and final test. The
structure and provided context for the individual
reporting of our case study investigation differs from each
source code procedures.
of these in that we describe the reverse engineering and
– The design recovery phase made the code imple-
reengineering activity in detail while Neighbors describes
mentation step much more straightforward and
observations that resulted from performing a reengineering
less prone to errors than trying to re-implement
activity, and Lewis and McConnell describe a high-level
the system without understanding the design
process that includes reverse engineering and reengineer-
first.
ing as a step, but do not emphasize the experiences of per-
A reverse engineering technique that combines the forming the step.
use of an OO design methodology and a SA/SD de-
sign methodology can facilitate the transition of a 7 Conclusion and Future Investigations
system from a procedural style to an object-oriented The ability to analyze software project requirements
style. in order to identify a process model for the subsequent
Use of systematic reengineering methods facilitated development of the software is an invaluable tool for
the completion of the overall project well within the any software developer. For traditional software develop-
schedule for project deliverables. ment, identification of the appropriate process is straight-
The lack of detailed documentation for the original forward as there are several well-documented development
system posed significant challenges in the design re- methodologies available. For software reengineering, the
covery step, particularly, given the time constraints. identification of a process is more difficult since the suite of
available reengineering methodologies has not been stan-
Overall, the lack of software tools to support the
dardized. However, there have been investigations into the
reengineering process made the process more diffi-
generation of project-specific software reengineering pro-
cult, time-consuming, and error-prone. In particular,
cess models [20].
source code analysis tools for generating call graphs
The value of case studies is in their ability to provide a
would have expedited the design recovery stage. To
data point for assessing currently available techniques and
address this concern, we are in the process of devel-
for providing motivation for new techniques and tools. In
oping a suite of tools that support informal and formal
this paper, several interesting and validating lessons were
reverse engineering techniques.
learned: (1) a systematic process for reengineering is a Automated Software Engineering, vol. 3, pp. 139–164, June
fruitful activity, (2) a combined OO and SA/SD approach 1996.
to reverse engineering can facilitate the transition of a sys- [10] A. Quilici, “A Memory-Based Approach to Recognizing
tem from a procedural style to an object-oriented style, and Program Plans,” Communications of the ACM, vol. 37,
(3) the lack of tools to support reengineering can be inhibit- pp. 84–93, May 1994.
ing. In order to address the tools issue, we are investigat- [11] G. C. Murphy and D. Notkin, “Reengineering with Reflex-
ing the creation of a maintenance workbench that incorpo- ion Models: A Case Study,” Computer, vol. 30, pp. 29–36,
rates the use of several classes of support tools including August 1997.
those that produce and verify structural abstractions [15] [12] B. H. C. Cheng and B. Auernheimer, “Applying Formal
and functional abstractions [10, 21]. Methods and Object-Oriented Analysis to Existing Flight
Software engineering courses in a typical undergradu- Software,” in Proceedings of the 18th Annual NASA Soft-
ate program focus mainly upon the construction compo- ware Engineering Workshop, pp. 274–282, NASA, Decem-
nent of the software development lifecycle. In order to bet- ber 1993.
ter prepare the undergraduates with the inevitable software [13] G. C. Gannod and B. H. C. Cheng, “A Two Phase Approach
maintenance activity, we are investigating the creation of to Reverse Engineering Using Formal Methods,” Lecture
software maintenance courses that emphasize the use of Notes in Computer Science: Formal Methods in Program-
reengineering techniques. ming and Their Applications, vol. 735, pp. 335–348, July
1993.
Acknowledgements. The authors would like to thank the [14] R. M. Ogando, S. S. Liu, N. Wilde, and S. S. Yau, “An ob-
following people for their participation in this project: John ject finder for program structure understanding in software
Edwards, Craig Neorr, and Jon Warren from Michigan maintenance,” Software Maintenance: Research and Prac-
tice, vol. 6, pp. 261–283, 1994.
State University, and Lynn M. Kubinec from Texas Instru-
ments. [15] S. R. Tilley, K. Wong, M.-A. Storey, and H. A. Müller, “Pro-
grammable Reverse Engineering,” The International Jour-
nal of Software Engineering and Knowledge Engineering,
References vol. 4, no. 4, pp. 501–520, 1994.
[16] J. Edwards, M. Fagnani, C. Neorr, G. Sudindranath,
[1] M. Hanna, “Maintenance burden begging for a remedy,”
and J. Warren, PACK R AT System Design Document.
Datamation, pp. 53–63, April 1993.
Michigan State University, March 1998. Available at
[2] E. J. Chikofsky and J. H. Cross, “Reverse Engineering and http://web.cps.msu.edu/scps478/S98/Projects/PackRat/web.
Design Recovery: A Taxonomy,” IEEE Software, vol. 7,
[17] M. Miller, Managing Internetworks with SNMP. M & T
pp. 13–17, January 1990.
Books, 1993.
[3] E. J. Byrne, “A Conceptual Foundation for Software Re- [18] J. M. Neighbors, “Finding reusable components in large
engineering,” in Proceedings for the Conference on Soft-
systems,” in Proceedings of the Third IEEE Working Con-
ware Maintenance, pp. 226–235, IEEE, 1992. ference on Reverse Engineering, pp. 2–10, IEEE, November
[4] E. Yourdon and L. Constantine, Structured Analysis and De- 1996.
sign: Fundamentals Discipline of Computer Programs and [19] B. Lewis and D. J. McConnell, “Reengineering Real-Time
System Design. Yourdon Press, 1978. Embedded Software onto a Parallel Processing Platform,”
[5] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and in Proceedings of the Third Working Conference on Reverse
W. Lorensen, Object-Oriented Modeling and Design. En- Engineering, pp. 11–19, November 1996.
glewood Cliffs, New Jersey: Prentice Hall, 1991. [20] E. J. Byrne, “Generating project-specific reengineering pro-
[6] R. H. Bourdeau and B. H. C. Cheng, “A formal semantics cess models,” in Proceedings of the 6th Annual DoD Soft-
of object models,” IEEE Trans. on Software Engineering, ware Technology Conference, April 1994.
vol. 21, pp. 799–821, October 1995. [21] G. C. Gannod and B. H. C. Cheng, “A Formal Automated
[7] Y. Wang and B. H. C. Cheng, “Formalizing and integrat- Approach for Reverse Engineering Programs with Point-
ing the functional model within omt,” in Proceedings of ers,” in Proceedings of the Twelfth IEEE International Au-
the International Conference on Software Engineering and tomated Software Engineering Conference, pp. 219–226,
Knowledge Engineering, June 1998. IEEE, 1997.
[8] L. M. Kubinec, PackRat: A Windows-based Ethernet Snif-
fer. Texas Instruments Network Business Unit, January
1998.
[9] G. C. Gannod and B. H. C. Cheng, “Strongest Postcondition
as the Formal Basis for Reverse Engineering,” Journal of