Software Restructuring

ROBERT S. ARNOLD
Invited Paper

Perhaps the most common of all software engineering activities ORIGINAL PROGRAM FRAGMENT:
is the modification of software. Unfortunately, software modifica- 000100 EDIT-COST-INDICATORS.
tion-especially during software main tenance-often leaves behind 000110 IF C NOT EQUAL TO " A " OR '8" MOVE 'X" TO COST-INDICATOR
0001 20 GO TO EDIT-COST-INDICATORS-EXIT.
software that is difficult to understand for those other than its 000130 IF C EQUAL TO " A " AND CS EQUAL TO 1 MOVE 0 TO
author. The result is software that is harder to change, less reliable 000140 PGNT ADD1 TO PGNT MOVE '007" TO SPAG.
when it is changed, and progressively less likely to be changed. 000150 MOVE ALL NINES TO ZCOD ADD 1 TO NLCNT
000160 ADD SPC TO CUM-SPC PERFORM OK-RECD-PRINT THROUGH
Software restructuring is a field that seeks to reverse these effects 0001 70 OK-RECD-SUB-PRINT GO TO EDIT-COST-INDICATORS-EXIT.
on software. ___ _ _
nnnim IF c EOUAL TO " 8 - AND cs EOUAL TO 1 MOVE o TO PGNT ADD 1
- __.
0001 90 TO FGNT MOVE "007; TO SPAG MOVE ~ 9 9 9 TO
" ZCOD.
This paper is a brief tutorial on software restructuring. The paper 000200 ADD 1 TO NLCNT ADD SPC TO CUM-SPC
discusses what restructuring is, advantages and disadvantages of 000210 PERFORM OK-RECD-PRINT THROUGH OK-RECD-SUB-PRINT
restructuring, tools and case studies, and future possibilities. The 000220 GO TO EDIT-COST-INDICATORS-EXIT.
000230 IF C EQUAL TO " A " OR ' 6 " AND CS NOT EQUAL TO 1 ADD 1
reader is assumed to have a general appreciation for building and 000240 TO PGNT MOVE "010" TO SPAG ADD 2 TO NLCNT
maintaining software systems. After reading this paper, the reader 000250 ADD SPC TO CUM-SPC PERFORM NOT-OK-RECD-PRINT
000260 EDIT-COST-INDICATORS-EXIT.
should have a feel for the strengths, weaknesses, and capabilities 000270 EXIT.
of software restructuring technology.
RESTRUCTURED PROGRAM FRAGMENT.

0001 00 EDIT-COST-INDICATORS-1 080.

I. INTRODUCTION 000110 IF COST-INDICATOR = " A " OR 'B".
0001 20 IF SUB-COST-INDICATOR = 1,
A. The Concept of Software Restructuring 000130 MOVE 0 TO PAGE-COUNT.
000140 ADD 1 TO PAGE-COUNT,
0001 50 MOVE '007" TO SPECIAL-AGENT,
Software restructuring i s the modification of software to 0001
_. 60
..
. MOVE "99999" TO ZIP-CODE.
000170 ADDI TO NEW-LINE-COUNT,
make the software easier to understand and to change, or 0001BO ADD SPECIAL-COST TO CUMULATIVE-COST
000190 PERFORM OK-RECD-PRINT-1470 THROUGH
less susceptible to error when future changes are made. 000200 OK-RECD-PRINT-1580.
"Software" includes external and internal documentation OOO210 ELSE
000220 ADD 1 TO PAGE-COUNT.
concerning source code, as well as the source code itself. 000230 MOVE "010" TO SPECIAL-AGENT,
000240 ADD 2 TO NEW-LINE-COUNT,
This definition of software restructuring excludes soft- 000250 ADD SPECIAL-COST TO CUMULATIVE-COST,
ware changes for other purposes, such as code optimiza- 000260 PERFORM NOT-OK-RECD-PRINT-1760.
000270 ELSE
tion. Code optimization does imply "restructuring" in a 000260 MOVE " X " TO COST-INDICATOR.
000290 EDIT-COST-INDICATORS-EXIT-1 260.
sense, but normally does not concern the key element-for 000300 EXIT.
this paper-of improving software maintainability. Fig. 1. Software restructuring of a COBOL program. (From
Some examples of software restructuring are pretty print- [25], p. 129.)
ing (spaces and aligns software statements so that they are
easier to comprehend as logical units); manual restructur- some cost indicators (see line IOO), but other details, such
ing according to coding style standards (infuses software as the meaning of the cost indicators being edited, are
with standard, recognizable structure); editing documen- unclear. Its variables are not mnemonic. (What does
tation for readability (makes the documentation easier to "SPAG" mean in line 140?)More than one statement per
read, possibly improving software maintainability); creat- line, lack of consistent indentation, and splitting of state-
ing an index for some software documentation (makes it ments across physical lines makes following thecontrol flow
easier to locate information about software); and so on. difficult. The program has literal constants (e.g., "007"),
Fig. 1 illustrates software restructuring. The original pro- instead of symbolic constants (e.g., SPECIAL-AGENTwith
gram is hard to maintain. Its purpose i s apparently to edit aconstant valueof "007"), which makes the program harder
to change.
Manuscript received August 8, 1988; revised October 18, 1988. The restructured program has fixed many of these prob-
In preparing this paper, the author has reused and updated much lems. From quick inspection, the purpose of the program
of the material in [5]. All views are the author's only, and do not hassomethingtodowith accumulatingcosts related to spe-
necessarily reflect those of the Software Productivity Consortium. cial agents. (JamesBond's-agent 007's-expense account-
The author is with the Software Productivity Consortium, Hern-
don, V A 22070 USA. ing program?) Statements appear on one line. The control
I E E E Log Number 8926704. flow has been simplified and indentation makes thecontrol

00159219/89/0400-0607$01.000 1989 IEEE

PROCEEDINGS OF THE IEEE, VOL. 77, NO. 4, APRIL 1989 607

flow easy to follow. Variables have more meaningful names Upgrading software along with upgrading software
(e.g., SPECIAL-AGENT instead of SPAG). Literal constants engineering practices
like ”007” still remain, but their purpose is easier to fathom Implementing standards for software structure
(e.g., since “007” i s assigned to SPECIAL-AGENT, 007 Making bugs easier to locate
appears to be the number of a special agent). Extending system lifetime by retaining a system’s flex-
Several terms related to software restructuring have ibility through good structure
appeared. Software reengineering, software renewal [51], Preparing software as input for software analysis tools
software renovation, software rejuvenation [16], [IA, soft- Preparing software for conversion
ware improvement [25], [26], software recycling [52], and so * Preparing to add new features to software
on, have approximatelythe same intent as software restruc- Preserving software’s asset value to an organization
turing: modifying or adding to software to make it easier
Software restructuring i s an integral part of achieving many
to understand and to change.
goals in software maintenance and in corporate planning
Reverse engineering i s the recoveryof information about
for software change.
software to make the software easier to understand and to
change. For example, creating design diagramsfor a system
C. What “Structure“ i s the Target of Restructuring?
whose design diagrams are out of date i s a reverse engi-
neering technique. Software restructuring i s not just concerned with objec-
Reverse engineering and software restructuring are tively observablelmeasurable aspects of software structure.
related. Reverse engineering connotes adding new infor- It i s also concerned with people’s perceptions of software
mation to software where such information previously did structure. When asked about the understandability of a
not exist, or was hopelessly inaccurate. Software restruc- piece of software, most software engineers will not base
turing connotes taking existing information and refashion- their answer exclusively on measurements of objective soft-
ing it so it can be more easily understood. However, since ware aspects; they also look at at least part of the software.
the process of refashioning information often incorporates The point here i s that in considering restructuring, one
new insights about software, for this paper we consider needs to consider that the structure (ideas about the soft-
reverse engineering a part of software restructuring. ware) in people’s heads matters as much as the objective
structure of software itself. For software restructuring,
“structure” i s determined by at least two things: the soft-
B. Why Be Concerned About Software Restructuring? ware and the perceiver. Thus anything that can influence
With continued change, software tends to become less the software’s state or the perceiver’s state might influence
“structured” [31]. This is manifested by out-of-date docu- software structure. The succeeding discussion will use the
mentation, code which does not conform to standards, term “software structure” with both these aspects of struc-
increased time for programmers to understand code, ture in mind.
increased ripple effect of changes, and so on. These can- Fig. 2 presents some of the factors influencing people’s
and usually do-imply higher software maintenance costs. perceptions of software structure. The clearest influence
Software restructuring is an important option for putting
high software maintenance costs under control. The idea
EWIRONMENT
i s to modify software-or programmer‘s perceptions of
software structure-so one can understand and control it MANAGEMENT: POLICIES
anew.
There are many other reasons why software engineers SOFTWARE ENGINEERS
should be aware of software restructuring:

Regaining understanding of software by instilling soft-

ware with known, easily traceable structure. This has
the side benefits of
easier documentation,
easier testing,
easier auditing,
potentialI y reduced software com plexity,
potentially greater programmer productivity,
reduced dependence on individuals who alone
understand poorly structure software, Fig. 2. Factors influencing perceptions of software struc-
increased interchangeability of people maintaining ture.
software, and
greater programmer job satisfaction due to on software structure comes from the software code itself,
decreased frustration in working with poorly struc- at the core of Fig. 2. Next, the in-line software documen-
tured software. tation-often the primary documentation programmers
Creating software whose structure more closely depend on [22]-can have a strong influence on a pro-
resembles the structure taught to newer generations grammer’s perception of structure. Other documentation,
of programmers when available, up-to-date, easily referenced, clearly writ-
Reducingthe amount of time needed for maintenance ten, and s o on, can also influence a programmer’s percep-
programmers to become familiar with a system tion of structure. Next come the set of available software

608 P R O C E E D I N G S OF THE IEEE, VOL. 77, N O . 4, APRIL 1989

tools (or programming environment) which can illuminate D. Software Restructuring i s a Means to an End
different views of the software for the programmer. For
Software restructuring should not be an end in itself.
example, program traces can show dynamic execution
Restructuring should be related to locally defined goals,
behavior, algorithm animation can help programmers
and achieving goals should be related to perceived soft-
understand the dynamic strategy behind an algorithm,
ware value. If restructuring cannot be justified in terms of
global variable cross referencers can help programmers
higher goals, then thesegoals should be rethought, or more
understand the interactions between modules, and pretty
information collected, before the decision to restructure i s
printers can make reading code much more appealing.
made.
In the middle layer of Fig. 2 i s the programmer, the’lother
For example, if the problem i s slow performance of user-
side”of software structure. If the programmer is not trained
requested changes in a software maintenance shop then
to look for certain aspects of structure, his or her percep-
maintenance management’s higher goal of satisfactory
tion of structure will be influenced.
software service is affected. The reason for the slow per-
Because programmers’ perceptions differ (even in the
formance could be hard-to-modify software (in which case
same programmer at different times’), the notion of soft-
software restructuring may be advisable), or unrestrained
ware structure i s not constant, but dynamic. In fact, failure
user requests for change (in which case software restruc-
to have written notions of structure (such as structural stan-
turing may not be advisable), among other reasons. Further
dards) which programmers are aware of, or failure to allow
information i s needed before one decides to restructure.
programmers to refresh their notions of structure by view-
But if restructuring i s selected, it is because of the goal of
ing software in various ways, can lead to a net loss of struc-
satisfactory software service and not restructuring for its
ture. For example, program patches are insidious structure-
own sake.
reducers becausethe reason for the patch is often lost when
A major goal of software restructuring i s to preserve or
the patch’s author leaves. I n effect, the programmer has
increase software value. Software value can be measured
promoted in the software his or her structural view without
externally or internally:
telling others of this view, resulting in a net loss of software External softwarevalue i s thecost savings the software
structure for others.
provides to the user community, relative to other, non-
At the next higher layer of Fig. 2 is the management layer,
software means of satisfying user needs. For users, suc-
which can sensitize a programmer to aspects of software
cessful software maintenance i s typified by few-preferably
structure. For example, management can emphasize soft-
no-visible bugs in the software and rapid response to, and
ware quality as embodied in a set of standards. If a pro-
implementation of, user requests for system change. As
grammer’s performance review is tied to how well these
noted earlier, systems undergoing maintenance often
standards are met, then the programmers’ perceptions of
become progressively more difficult to change. If this pro-
software will likely be influenced!
gressive software ossification ever begins affecting the
The highest layerof Fig. 2 istheenvironment surrounding
user’s expectation of delivered software capability, the
the lower levels. This includes physical facilities, degree of
influence on software maintenance tasks by computer
users, lack of availability of hardware, and s o on. All can
-
external value of the software may decrease.
Internal software value involves at least three kinds of
cost savings: 1)the maintenance cost savings that the soft-
influence a programmer’s attitude, which in turn can influ-
ware form provides relative to some other software form,
ence his or her perception of software structure.
2) the cost savings incurred by reusing parts of the software
By changing the state of items at any of the levels i n Fig.
in other systems, and 3) the cost savings due to an extended
2, “software structure”can be influenced. Thus, approaches
software lifetime (which delays the introduction of a
that influence any layer($ of Fig. 2 are all candidate software
replacement system). If software restructuring reduces
restructuring approaches.
maintenance costs, increases the software‘s potential for
For example, reducing programmer turnover-a prob-
reuse in other software, and extends the software’s lifetime,
lem of the management layer of Fig. 2-may be viewed as
the internal value of the current software should increase!
a structure-preserving technique. Since programmers have
There is little reason to believe that the same definition
invaluable insight into the behavior of software, high turn-
of value i s used by all maintenance environments. Software
over of programmers can lead to information loss about the
value can be measured in other ways, such as savings in
software. High turnover does not allow enough timeto pass
calendar time to implement software changes, increase in
on this information before a person leaves. The result is a
maintainer morale, increase in management respect for
progressivenet loss i n software structure, which i s typically
software maintenance, and s o on.
manifested by software changes becoming harder to imple-
But having some definition of software value can mate-
ment. The basic problem of preserving information among
rially affect decisions to restructure. Any decision to use a
programmers may be ameliorated by decreasing program-
software restructuring approach should try to quantify the
mer tu r nover.
added software value, as locally defined, which the
Unfortunately, few authors-anywhere-define their
approach will provide.
notions of software structure in their papers or books. The
reader should realize the structure^" in restructuring is
often implicit,with the discussioncontext hinting at what E. Software Restructuring and Software Maintenance
structure is intended. Software restructuring i s most often applied to software
undergoing maintenance, for this i s where the lack of soft-
ware structure becomes most evident (and expensive).
’For example, if a programmer returns to software he (or she) has
written years earlier, it may initially appear strange and difficult to Throughout this paper, software will be con-
understand. sidered in the context of software maintenance.

ARNOLD: SOFTWARE RESTRUCTURING 609

 However, software restructuring is also applicable dur- style manual may require that certain coding structures be
ing software development. This occurs especially when avoided (e.g., ALTER statements in COBOL) and that stan-
development activities are undertaken in an environment dard keywords be used. This approach i s mostly manual,
resembling "traditional" software maintenance (i.e., no but i s often used with automated tools such as pretty print-
quality assurance, deadline-driven, little if any testing, no ers and control flow restructurers. Some COBOL restruc-
code reviews, etc.). This can result in software becoming turers (see below) allow their output code to be tailored to
less and less structured. better conform to local style guideline's.
To take a plausible example, in a large software project Restructuringwith a preprocessor ([29] and others): The
that has little reused code that takes several calendar years idea here is to replace sections of code with statements in
to build, and has little quality assurance, the potential for another, presumably easier-to-understand, language. The
unstructured softwaretoward project end can [Link] new statements can be automatically expanded into state-
development activities prior to delivery could center on ments of the original language. This approach has the
corrections to errors uncovered by tests and on enhance- advantage of allowing software to be selectively restruc- ,
ments requested by users due to changed needs since the tured, with statements recognized by the preprocessor,
system was contracted. If development i s deadline-driven, while leaving the remaining software unchanged. This i s
the changes may be hurried and resemble patches, which important because some people are leery of restructuring
can lead to worse software structure. In this situation, soft- approaches that restructure more than i s apparently nec-
ware restructuring might be advisable before the system i s essary.
accepted for maintenance. (b) Packagesheusable code: These approaches use
software packages, or reusable code, to replace poorly
11. STATE OF THE ARTIN SOFTWARE RESTRUCTURING structured software, or add to software.
TECHNOLOGY Restructuring code for reusability DO]: This technique
takesexistingcodeand puts it in aformfor [Link]
As noted earlier, by changing the state of items at any of
involves "cleaning up" software interfaces (e.g., removing
the levels in Fig. 2, "software structure" can be influenced.
superfluous parameters, reducing procedural side effects,
We can study restructuring approaches by the levels of Fig.
and so on). Another aspect of this technique i s changing
2 addressed by each approach.
a system to accept reusable code. Several examples of this
This section briefly describes restructuring approaches.
follow.
The approaches are divided into techniques, methodolo- 9 Buy a package to replace an old system [16]: Some-
gies, and reverse engineering. Techniques (Section Il-A)
times the best way to "restructure" a system i s to replace
pertain to making changes at one (or a few) of the levels in
it with a system with known structure. Restructuring i s not
Fig. 2. Methodologies (Section Il-B)can pertain to all levels.
the only way to solve problems with a system that i s hard
Reverseengineering(Section11-C)pertainsto repopulating,
to understand, hard to change, and unreliable when
or bringing up-to-date, information in any of the levels.
changed. Since most packages do not make their source
Twocaveats: this section i s not intended to beexhaustive.
code available to users for modification, modifications to
It is intended to give the reader a feel for a wide range of
the packages must be done-at potentially substantial cost
restructuring approaches. Also, the classifications are not
and on the vendor's timetable-through the package ven-
exclusive; some approaches could be placed in more than
dor.
one section. Buy a softwarepackage to replace an old system; then
extend thepackage[76]: If it is risky or expensive to modify
A. Techniques
a system, a package may exist that both does the system's
A"technique" for this list i s a restructuring approach that function and can be extended for new use. This i s a straight-
pertains to one (or a few) levels of Fig. 2. The restructuring forward approach, provided a suitable, adequately docu-
techniques presented here correspond to the innermost mented package can be found. Again, getting the package
five levels: code, documentation, programming environ- supplier's source code for the package can be a problem.
mentltools, software engineers, and managementlpolicies. Getting information on how the package works can be a
1) Code: Code-oriented restructuring techniques per- bigger problem.
tain to modifying code directly, mostly without relying on Buy a package to replace part o f an old system [16]: As
information in the other levels. In the following sections the title implies, this approach replaces a software part that
they are divided into techniques based on coding style, is particularly in need of restructuring. The approach
packages and reusable code, control flow, and data. depends on being able to find a suitable replacement pack-
a) Coding style: These restructuring approaches mod- age. The concerns raised above about vendor packages still
ifycode to make it easier to understand, often without alter- apply.
ing control structure or data structure. System sandwich approach 1161: This is an ingenious
Pretty printing a n d code formatting: This restructuring approach for retaining the benefits of code that i s so badly
technique textually restructures code by applying spacing structured it must be treated as a black box. The idea is to
between logical subparts, indentation of nested state- sandwich the old system between a new front-end interface
ments, one statement per line, and so on. This often can be (e.g., written in a fourth generation language) and a new
done totally automatically and may be available as a com- back-end data base. The front-end interacts with the user.
piler option for output listings. It also issues calls to the black box to compute information
Coding style standardization: This restructuring tech- not currently available from the back-end data base. The
niquetextually restructurescode by modifyingcode tocon- black box system computes its outputs and directs it to the
form to coding standard style guidelines. For example, a back-end database. The front-end and back-end can directly

610 PROCEEDINGS OF THE IEEE, VOL. 77, NO. 4, APRIL 1989

communicate for report generation purposes. The old sys- The result of this will usually be a program with different
tem i s used primarily for its outputs to the back-end data- structure from the original.
base. d) Data: Historically, restructuring of software tends to
c) Control flow: Much of the concern for software connote restructuring of its control structure. But possi-
restructuring began with a concern for making a program’s bilities for restructuring data are important too. One exam-
control flow easier to follow. This category contains algo- ple isputtingthe relationsof a relational data baseintothird
rithms and procedures for restructuring program control normal form. This has the advantage of reducing the need
flow graphs, and tools for restructuring programs. The to propagate updates in a data base when data records are
restructuring tools are mostly oriented to COBOL, for this updated. Another example crops up i n multidatabase envi-
i s where most commercial interest in restructuring has ronments. In such environments each database can have
[Link] tools typically offer much morethan justthe abil- its own schema. Often, there are data items that mean
ity to restructure code. For example, many tools offer style approximately the same thing, but are named differently in
standardization,measurements of the code before and after each schema. To reduce the dependence of programs on
restructuring (e.g., number of goto‘s), and/or automatically the idiosyncrasies of data names with each database, the
generated documentation (e.g., depicting control flow rela- schemas might be restructured into a master schema that
tionships among program elements) about the code. Since can hide lower level schema naming conventions. Pro-
competition is motivating constant improvements the tool grams can then be restructured to make queries using the
marketers should be consulted for latest information. No master schema. This increases program understandability
evaluation is implied by the presence or absence of a tool/ because programmers only have to know what data items
approach in this list. in the master schema mean, rather than having to know the
Earlygoto-less approach [ I l l : This approach i s famous semantic nuances for each database.
for showing “goto’s” are not theoretically necessary to cre- 2) Documentation: Documentation is often the first place
ate a computer program. The proof is by construction and programmers turn to before modifying code. Documen-
contains a way to restructure software. tation helps the programmer understand code, plan and
Giantcasestatementapproach[7JThis i s another con- perform modifications, and perform testing. Unfortu-
structiveway to remove goto’s. The resulting program looks nately, documentation often goes out-of-date and then is
like a giant case statement. never referred to. Missing or inconsistent documentation
Boolean flagapproach [%I: This is a procedure for cre- seems to be a constant complaint from maintenance pro-
ating a “structured” flowgraph by introducing Boolean grammers.
var ia b Ie(s). Upgrade documentation: Examples of this are adding
Duplication of coding approach [58]: This approach in-line code comments, making comments more accurate,
eliminates goto’s to shared sections of code by duplicating expanding on cryptic commentary, and so on. Upgrading
the shared code and eliminating the sharing. This approach documentation and reverse engineering (discussed below)
will not work for some looping programs. can overlap. The loose distinction we make i s that upgrad-
Baker’s graph-theoretic approach 181: This is the algo- ing documentation takes existing documentation and
rithm behind the tool “struct” for restructuring FORTRAN updates it, often without creating new forms of documen-
programs. Goto’s are allowed on a limited basis. tation. Reverse engineering may create new forms of doc-
Refined case statement approach [33]: This approach umentation as well.
introduces some procedures and heuristics to make the System modularization: System modularization con-
program resulting from the giant case statement approach cerns how to decompose a proposed system into logically
easier to read and understand. This approach has some meaningful modules, or re-decompose an existing system
mathematical foundations in the work in [37l. into modules. System modularization currently requires
RETROFIT (tm) [35]: A tool for restructuring COBOL much human judgment. Principles for manually perform-
programs. Marketed by the Catalyst Group of Peat Marwick ing modularization are available [41]-[43].Some work on
Main & Co., Chicago, Illinois. automating the modularization of systems has recently
SUPERSTRUCTURE (tm) [38]: A tool for restructuring been reported [52].
COBOL programs. Marketed by the Software Productivity 3) Programming Environments/Tools: A programming
Tools Division of Computer Data Systems, Inc., of Rock- environment provides a set of tools to assist the program-
ville, Maryland, through a recent acquisition of the pre- mer in building, browsing and modifying software. Often
vious marketer, Group Operations, Washington, D.C. the environment is used not just for programming, but for
RECORDER (tm) [IS]: A tool for restructuring COBOL designing and creating requirements. In some environ-
programs. Marketed by Language Technology, Salem, Mas- ments the tools are integrated, where the environment pro-
sachusetts. vides support for sharing data among the tools.
Cobol Structuring Facility (tm) [34]: A tool for restruc- * Upgrade the programming environment: Examples of
turing COBOL programs. Marketed by IBM, Bethesda, this are adding windows to the programming interface,
Maryland. improving interaction of tools, replacing hard-to-useoper-
DeltdSTRUCTURIZER (tm): A tool for restructuring ating system command languages, and so on. These mea-
COBOL programs. Marketed by Delta Software Technol- sures do not directly restructure target software, but they
ogie AG, Switzerland. can increase the ability of a programmer to deal with soft-
Double conversion: This approach takes a program in
language A, uses an automated conversion tool to translate -
ware.
Programming environments/workstations ([9], [57]and
the program into language B, then uses another automated others): Programming environments offer more compre-
conversion tool to reconvert the program into language A. hensive support for programming needs than do tool col-

ARNOLD: SOFTWARE RESTRUCTURING 61 1

lections. For example, the programming environment may hard to understand by the general programming com-
allow tools to be easily combined in a control procedure munity may persist.
to create new tools. The programming workstation offers Reduce turnover: When a person leaves an organiza-
increased computing power to the programmer, along with tion, a wealth of perceptions about software walks out the
new programming interfaces (e.g., windows). door. Steps to reduce turnover can help keep strong the
8 Software metrics ([IO], 1231, 1391, [47J and others): The group’s consciousness about software structure.
restructuring idea here is: 1) measure the software with a 5) Management and Policies: Management and policies
software metric (or a set of software metrics); 2) from the can have a great impact on what people do with software,
metric’s value, answer the question, “Is the software prop- and therefore how software i s perceived.
erty measured by the metric satisfactory?”; 3) if not, Programming standards and style guidelines ([28] and
restructure the software and go to step 1); 4) if so, you are others): This idea seems widely accepted, but surprisingly
done. may not be put widely into practice [59].
Standards checkers and other aids: These are tools that Inspections and walkthroughs ([18], [20] and others):
take a program and automatically report which software This i s one of the most effective practices for making soft-
standards the program does and does not meet. Based on ware understandable and structure more recognizable.
the reported violations, the code may be modified
(restructured) to remove the violations. B. Methodologies
Tool collections (1561 and others): There i s a growing
A methodology i s typically a set of steps for improving
number of tool collections that may be used to illuminate
software at several of the levels shown in Fig. 2. A meth-
aspects of software structure. For example, MAP [56] will
odology helps direct the use of other, more specific,
display the structure chart for a COBOL system, display a
restructuring techniques.
unit interface chart, highlight procedures in the structure
System rejuvenation [16]: System rejuvenation i s
chart that contain selected statements, display possible ref-
defined as “using an existing system as the basis for a new
erences of modifications to selected variables, and so on.
strategic system.” This i s a methodology that involves
MAP is nowavailableasVIA/INSIGHTfromVIASOFT, Phoe-
cleaning u p the existing system, making it more efficient
nix, Arizona.
Program transformation systems [44]: These systems (sometimes restructuring introduces a performance over-
head), and putting the rejuvenated system into use.
involve automatic changes to software. The changes are
Software Improvement Program [26], pq: This is an
accomplished with rules called transformations. This
ambitious, management-intensive way to both restructure
approach i s related to the rule-based systems of artificial
software and upgrade the software engineering practices
intelligence.
Fourth generation languages ([24]and others): Though of a maintenance environment. It consists of detailed tech-
nical guidance for planning the restructuring of software
not generally thought of as restructuring tools, fourth gen-
and improving the programming environment in which
eration languages offer significant benefits to the set of
software i s built.
applications that may be rewritten in them. These benefits
Incremental restructuring [4]: Incremental restructuring
include ease of change, usability by end users, and quick
is a restructuring approach without as much management
development of small systems.
overhead as the Software Improvement Program. The
4) Software Engineers:The benefits of software structure
approach allows “structure” to be defined by users (rather
must be perceived before they can be practically realized.
than being built into the restructuring approach); restruc-
Software problems (such as difficulty in modifying source
turing is done i n small, manageable parts. Also, a system
code)-problems that normally suggest software modifi-
can have the benefits of restructuring without having to be
cation-oriented restructuring solutions-may only be
totally restructured. The approach is specifically designed
symptomatic of nonsoftware problems that impair or lose
to avoid introducing poor structure as a result of mainte-
programmer’s perceptions about software structure. Soft-
nance.
ware restructuring is, in a very real sense, concerned with
Software renewal[Sl]: Software renewal i s an approach
improving programmer’s perceptions about software.
Train programmers: Some common examples of this not so much for modifying code as for upgrading system
documentation, system specifications, and system tests.
are the training courses in ”structured programming”
adopted by some companies, instruction on how to use
C. Reverse Engineering
existing tools to accomplish tasks, and advice from fellow
programmers on how software works. The reverse engineering techniques here emphasize
Hire new programmers, more experienced with the recovering design information about existing code.
existing software application: This is a most direct way to Recreating complete documentation (including require-
gain fresh insight into software structure. For example, if ments documents) on existing code is often exorbitantly
existing programmers are having difficulties modifying a expensive and tends not to be done (e.g., see [45]).
windowing package to run on a new operating system, hir- Strategies for understanding software [19], [32]: This
ing a system programmer already experiencedwith the win- approach suggests several heuristics for programmers to
dowing package and with installing it might beadvised. Even apply in trying to understand software that lacks up to date
if the windowing package and the operating system are documentation. The steps in [I91 are to learn the structure
poorly documented so that they are difficult to understand, and organization of the program, determine what the pro-
the new programmer’s experience could compensate for
these disadvantages. Of course, this may be only a short- -
gram i s doing, and document the program.
Design recovery [73, 121, [13], [40]: These approaches
term solution because the problem of the software being suggest specific forms for recreated design information. I n

612 PROCEEDINGS OF THE IEEE, VOL. 77, NO. 4, APRIL 1989

some cases, automated tools are used to recreate the doc-
umentation.
* Conversion [52]: This approach creates information
about a system as the system i s being converted. The new
information i s used to assist the programmer in converting
the system and in documenting the new system.
Orisinal program5 Recoded Programs
Ill. A SOFTWARE RESTRUCTURINGCASESTUDY

w
Whenever one considers a restructuring technique, one
is naturallycuriousaboutwhat resultsothers haveachieved. \leacurementc

Supposing that the technique i s a code restructuring tool,

one can go to the tool vendor and inquire about the tool.
Naturally one expects to get glowing praises and referrals
to the most satisfied customers. The next source of infor-
mation might be a users‘ group for the tool. Here one can
expect more realistic appraisals of a tool’s practical value. Changed original Changed recoded
programs programs
But the appraisals, though valuable, are very subjective.
Other users gained experience with the tools in their envi-
ronments with their programs; whether similar results will
happen in one’s own environment i s unclear, given that
environments and programs can differ dramatically.
Recently an attempt was made to compare the usefulness
of maintaining restructured code with original code.
Though methodological problems (discussed below) can
hStud) Recultc

Fig. 3. Planfor studying the effectivenessof a restructuring

be found in the study, the approach and results represent
tool [21].
a noteworthy contribution to the measurement of restruc-
turing efficacy.
The study, conducted by the Defense Logistics Agency’ Table 1 Programs Selected to Be Restructured
(DLA) of Columbus, Ohio, was an evaluation of a particular Program
COBOL restructuring tool, RECODER (tm), from Language ID for Study Program Name Structured?*
Technology3, Salem, Massachusetts [21]. The goal of the PROCl Policy Tables No
study was to investigate claims made by the vendor about PROCZ Prog. Data Ref. File Update No
the restructuring abilities of the tool and to ”evaluate the PROC3 Family & Cat. Chgs. to SCF No
effects of the restructuring process on production code PROG4 Defense Inactive Item Prog. No
PROCS Stratification No
managed by DLA.” PROC6 NON-NSN Demand Hist. Update Yes
Fig. 3 presents the study plan. Six programs were selected
‘Based o n i n t e r n a l DLA assessment.
by DLA to be restructured. Most of these programs were
considered “unstructured.” (See Table 1.) The programs
werethen restructured using [Link] dards and structure conventions. Programmers using the
were to workon the restructured code weregiven a training recoded versions “acquired increased knowledge levels
course taught by Language Technology. A set of measure- and skills over those who worked with the unstructured
ments of recoded versus original programs was taken. The versions.” Programmers generally felt that the documen-
same set of changes were applied to both recoded and orig- tation generated by RECODER was helpful in understand-
inal programs. Different programmers were used to per- ing the recoded versions.
form the changes. (No programmer was allowed to modify There were several negative observations: Several pro-
a program he or she wrote originally.) Measurements of the grams could not be restructured on the first attempt with
recoded and original software were taken again. (SeeTable RECODER.4Theprogrammers expressed concern about the
2.) Programmers were interviewed to get feedback about documentation style of programs produced by RECODER.
using the restructuring tool and about modifying the The recoded programs had significant increases in resource
restructured programs. utilization, such ascompiletime, load modulesize,and CPU
The study resulted in several assessments. On the pos- resources. Programmers generally had to change para-
itive side, restructuring was generally beneficial: The graph names in the recoded versions to more meaningful
recoded programs were easier to modify. (SeeTable 3.) The names. Programs of poor quality to begin with were not
time to test the modified restructured programs was about considerably improved by restructuring. Some clean up of
the same as for the original programs. (See Table 4.) The these programs prior to restructuring resulted in improve-
recoded versions had better consistency in the coding style ments in the code.
and documentation than the original versions. The recoded
versions had significantly reduced violations in local stan- 4Thisostensiblydenied thevendor’sclaim that anANSI standard
COBOL could be restructured totally automatically. The problem
lay with the standard, rather than the vendor, as the ANSI standard
’Dr. M. Colter analyzed the study results and wrote the final leaves room for interpretation and an instance of differing inter-
report. pretations was uncovered here. Language Technology has since
’Language Technology is to be commended for taking the risk madechanges so that thegiven programscan be restructured auto-
of exposing their tool for such scrutiny. matically.

A R N O L D : SOFTWARE R E S T R U C T U R I N G 613
Table 2 Sample Measurements Taken on Programs and IV. SOFTWARE RESTRUCTURINGLESSONS LEARNED
Programmers
A. RestructuredCode Takes Some Getting Used To
Measure When Taken
When code i s restructured, it i s unfamiliar to program-
Number of source lines Beforelafter
recodi ng mers until they get used to its style. This depends on the
Number of statements Beforelafter style and supporting documentation created in the restruc-
recoding turing process. Often programmers react negatively at first
Number of standards violations Beforelafter to restructured code, but later like the code because its style
recoding
i s regular and predictable. Depending on the restructuring
Compile service units, without Beforelafter
optimization recoding algorithm, the coding style of the restructured program may
Compile service units, with Beforelafter reflect modern programming practices-something which
optimization recoding i s a plus when hiring programmers recentlygraduated from
Load module size, without Beforelafter curricula that stressed such program structuring princi-
optimization recoding
Load module size, with Beforelafter
ples. Older programmers not used to such principles can
optimization recoding find the restructured code uncomfortable to deal with.
Execution (CPU) time Beforelafter
recoding
Revision time After performing a
B. Restructuring Code for Large Systems i s Often not
modification on
original and Enough
recoded
programs
For software many thousands of lines long, restructuring
Test time After performing a code to impart regularity and predictability in coding style
test on modified i s helpful, but modularization to further increase system
original and comprehensibility i s desirable. As noted earlier, modular-
recoded ization of code as part of its restructuring is still largely man-
programs
ual.

Table 3 Time to Modify Original and Recoded Programs* C. We Need RestructuredDocumentation Too
Program When code i s automatically restructured, the in-line doc-
ID for Study Original Program Recoded Program
umentation can lose its relevance because the restructured
PROCI a 4 code does not pose the same documentation referents.
PROCZ 1 1 Since in poorly structured code the in-line documentation
PROG3 3 3
PROG4 1 1
is often the final documentation (apart from the code itself)
PROC5 a 3 that the programmer depends on, the in-line documen-
PROC6 2 1 tation can be valuable to retain. Few restructuring tools
‘All times are in man-hours. attempt to modify inline code documentation so it can be
transferred to restructured code.

Table 4 Time to Test Original and Recoded Programs*

D. The Programming Environment Affects How We
Program Perceive Software Structure
ID for Study Original Program Recoded Program
Collections of tools, such as MAP mentioned above, allow
PROCI 1 1
PROG2 .5 1 different views of a program to be displayed one at a time.
PROG3 1 1 When aprogrammer movesfrom oneviewtothe next, how-
PROG4 2 .5 ever, he or she is confronted with two problems: l) retain-
PROG5 1 1 ing the information presented by each view, and 2) main-
PROG6 1 1
taining relationships between the views.
‘All times are in man-hours. In termsof programmer understanding of software struc-
ture, the mental context switching needed as one moves
from view to view can interfere with the gradual build-up
As the report points out; several experimental method- of understanding about software. For example, a serial view
ologyimprovementsare [Link] the study’sdesign, of programming-e.g.,viewthrough an editor, view of com-
it i s not clear how much of these results are attributable to piler output, view of program output, view of debugger out-
RECODER in particular, versus restructuring tools in gen- put-may have a high context switching overhead in the
eral. Noother restructuring [Link] programmer‘s head. This could impair the programmer’s
ability of the programmers was not made clear; the effect ability to integrate the multiple views when solving restruc-
of programmer ability-a significant experimental variable turing problems.
to control-on the results i s not clear. Not enough pro- Allowing programmers to see many software structure
grams were selected to provide statistically significant dimensions at once [54], with multiple windows or screens,
results. Nevertheless, the study i s a worthwhile start for the may be more effective in restructuring than the typical serial
more rigorous investigation of the pros and cons of soft- views of software structure [50]. This ability ought to be
ware restructuring. “standard equipment” in programming environments.

614 PROCEEDINGS OF THE IEEE, VOL. 77, NO. 4, APRIL 1989

E. Payoff o f Restructuringcan be Quantified and evaluated as to leverage, suitability in the local environ-
Predicted ment, and so on. Finally, a restructuring approach i s used
and evaluated.
Restructuring software alone does not assure a payoff. If
the software is never modified, inspected, or reused again,
then there i s little opportunity to realize the potential gains G. Take Steps to Preserve Software Structure After
Restructuring
of restructuring.
When selectinga restructuringapproach for practical use, Software restructuring should beviewed as part of a more
it is important to determine the approach’s leverage-the comprehensive solution to poor software structure. Once
ability of an approach to deliver effective results given the software is structured, presumably one would like it to stay
dollars invested. There are at least four factors that deter- structured with each software change. Here is where prac-
mine the leverage of a restructuring approach: tices that foster good software structure come in-practices
like defining and using software standards, giving pro-
The dollars invested to set up the approach
grammerstools for checking conformance to software stan-
The staff and facilities neededto support the approach
dards, performing code reviews, performing software tests
The expected return of the approach
with known degree of test coverage, quality assurance, and
The time frame for the return
so on.
The idea is, if the expected time frame for the return i s sat- Qualityassuranceand restructuringare more relatedthan
isfactory (e.g., does not exceed the expected remaining life- one might think. Quality assurance applied from the begin-
time of the software), and the expected return (possibly ning of maintenance can reduce the need for restructuring
including nonquantifiable benefits such as staff morale) sig- later on. If restructuring is required, quality assurance can
nificantly exceeds the return on the way maintenance i s help keep the software structured.
currently performed, then consider applying the restruc-
turing approach. For some quantified models of this, see V. FUTURE WORK
[I21 and [4].
Many software restructuring advances remain to be
The time frame for the quantifiable return for most found. Hereare some interestingtopics for future research:
restructuring approaches is on theorder of months toyears. Deciding when a n d where to restructure: Restructur-
True, the effects of restructuring may appear immediately
ing tools often go hand-in-handwith software metrics tools.
in the software itself, but the residual effects on mainte-
The software metrics tools gather metrics that can help
nance economics can take much longerto appear, and even decidewhere and when to restructure. Despite research on
then must be considered with other factors before one can systematic interpretation of metrics values and how to turn
be sure improvements were due primarily to restructuring.
these interpretations into justifiable management actions
(e.g., see [3]), there i s still much work in guiding people in
F. Systematically Decide How to Solve Problems With making restructuring decisions. What i s needed are quan-
Restructuring titative restructuring criteria based on validated metrics,
The software restructuringaction plan i n Table5outlines along with practical results demonstrating efficacy.
a way to select, apply, and evaluate a restructuring Using restructuring for standardizing: An important
approach. The idea i s first to discover the local, real main- application of restructuring tools is to impose coding style
tenance problems. From these problems, one decides standards. Tools are becoming increasingly parameterized
whether restructuring is the right approach at all. If so, then to allow users more control in the style of programs pro-
knowledge about the maintenance problems can be used duced. More work i s needed to increase the tool’s ability
to select from Section II a set of candidate restructuring to accommodate many different standards.
approaches. According to the target level of software, local Restructuring o f documentation: One problem with
maintenance goals, and s o on, candidate restructuring automated restructuring techniques that modify code is
approaches may be selected. These approaches are then they don’t restructure in-line documentation (i.e., rewrite
program comments) along with the code. This means that
Table 5 An Action Plan for Software Restructuring manual labor to restructure documentation i s nearly always
needed after applying a restructuring approach. Automat-
1) Talk to maintainers about their perceptions of maintenance ing the restructuring of documentation i s important for
problems.
2) Identify current tasks where restructuring software might save making restructuring more cost-effective.
staff time, reduce the maintenance budget, or achieve some Modularization a n d design level information: Design
other significant benefit. level information i n the past was often not on-line, and
3) Match an appropriate restructuring approach to the most hence not readily available for analysis and restructuring.
pressing maintenance problems. A restructuring approach
should be selected to have most impact on the tasks identified
Some CASE tools produce design information in thecourse
in step 2). of building software, and this information i s available to
4) Do a feasibility analysis and a technology transfer analysis of restructuring tools. Relatively little work has been done in
the intended restructuring approach. A technology transfer using this information for restructuring purposes.
analysis examines the social and psychological issues Automatically restructuring systems by modularization
affecting acceptance and use of the restructuring approach
in the workplace. is nearly uncharted territory. A Ph.D dissertation by Sob-
5) Select a restructuring technique, plan its use, and use it. rinho [53] has started work in this area. More recently, [52]
6) Monitor the restructuring effort, preferably by collecting data has discussed another approach for remodularization. It i s
and applying measures of structure and of maintenance unclear how effective these approaches are compared to
performance, and evaluate the results.
manual remodularization. More work on new automatic (or

ARNOLD: SOFTWARE RESTRUCTURING 615

semi-automatic) modularization approaches is needed, restructuring effectiveness, work is needed in areas such
along with studies demonstrating their effectiveness. as restructuring of documentation to correspond with
Graphicalprogramming: Graphical programming (e.g., restructured code, design restructuring, automatic appl i-
[a]) offers a relatively new way to visualize, specify, and cation of software standards, automatic system modulari-
build software. Graphical programming may help alleviate zation, and tools to reveal new aspects of software struc-
some lower-level problems such as hard-to-understand ture, such as graphical programming and software
control flow, and so change concern for software structure evolution animation.
to other dimensions. Graphical programs could become a
target output for reverse engineering tools.
Making available parts o f restructuring tools: Software ACKNOWLEDGMENTS
restructuring tools are often highly proprietary. Users can The author wishes to thank Language Technology, Peat
adjust the restructuring process by using only the options Marwick Main & Co., Group Operations (now part of Com-
madeavailable in thetool’s interface. Sometimes users may puter Data Systems, Inc.), IBM Corporation, Adpac, and
want to build their own special-purposerestructuring tools. Lexeme Corporation for information o n the current status
Users might benefit from reusing parts used to build a pro- of their restructuring and restructuring-related tools. The
prietary tool. The idea here is that it may be profitable for author also thanks N. Schneidewind, D. Nettles, and B.
both vendor and tool user to have “open architecture Nejmeh, and an anonymous referee for their comments for
restructuring” tools. Users would have the option of using improving the paper.
the complete package (i.e., the original tool), or using parts The following are Registered Trademarks: RECODER (of
of the tool to accomplish restructuring. How to repackage Language Technology, Inc.), RETROFIT (of Peat Marwick
tools into reusable parts useful to other restructuring tool Main & Co.), DeltdSTRUCTURIZER(of Delta SoftwareTech-
builders is an open question. nologie AG), COBOL Structuring Facility(of I B M Corp.), VIA/
Displaying software evolution: One reason program- INSIGHT (of Viasoft, Inc.), and SUPERSTRUCTURE(of Com-
mers have little clues about hard-to-understand software puter Data Systems, Inc.)
i s that programmers have few tools for conveniently tracing
how the software evolved to its current form. True, one can
examine configuration management records, but a lot of REFERENCES
detective work i s often needed to recreate the program- P. Antonini, P. Benedusi, C. Cantone, and A. Cimitile “Main-
mer’s mindset about the software that was changed. Evo- tenance and reverse engineering: low-level design docu-
lution replay tools deserve consideration as ways to ments production and improvement,” in Proc. Conference
on SoftwareMaintenance-7987, IEEE Computer Society, 1987.
enhance understanding of software structure. G. Arango, [Link], P. Freeman, and C. Pidgeon, “TMM: Soft-
ware maintenance by transformation,” /€€€Software, vol. 3,
no. 3, May 1986.
VI. SUMMARY R. S. Arnold, ”On the generation and use of quantitative cri-
teria for assessing software maintenancequality,” Ph.D. Qis-
Softwarerestructuring i s a tooi for meeting maintenance sertation, Computer Science Department, University of
goals and for increasing and preserving software structure. Maryland, College Park, 1983.
Software restructuring is part of a larger solution for main- -,“Techniques and strategies for restructuring software,”
taining the value of software as the software evolves. Notes for a software restructuring seminar conducted by R.
S. Arnold, May 1985.
Because software structure depends on programmer per- -,“An introduction to software restructuring,” in Tutorial
ceptions as well as the software state, software structure i s OR SoftwareRestructurjng. Washington, DC: IEEE Computer
dynamic. Steps must be taken to preserve structure in the Society, 1986.
minds of programmers, otherwise structure will be lost with -, Tutorialon Software Restructuring. New York, NY: IEEE
Computer Society, 1986.
programmer turnover. E. Ashcroft and [Link], “The translation of ’goto’ programs
There i s a wide variety of restructuring approaches, rang- in ‘while’ programs,” in Proceedings of the 7977 /F/P Con-
ing from approaches that do not modify software at all, but gress. Amsterdam, The Netherlands: North-Holland, 1971,
modify programmer perceptions of software, to those pp. 250-260.
approaches that do modify software. The limit to what i s a B. Baker, “An algorithm for structuring flowgraphs,”]. ACM,
vol. 24, no. 1, pp. 98-120, Jan. 1977.
software restructuring approach is a gray area. D. R. Barstow, H. E. Shrobe, and E. Sandewall, lnteractive Pro-
There i s a lackof quantitative information about software grammingEnvironments. New York, NY: McGraw-Hill, 1984.
restructuring. What we do know suggests restructuring V. Basili, Tutorial on Models and Metrics for Software Man-
leverage (the ability of a restructuring approach to “deliver” agementand Engineering. Washington, DC: IEEE Computer
Society, 1980.
given the dollars invested) tends to come in the medium C. Bohm and G. Jacopini, ”Flow diagrams, Turing machines,
to long term (months toyears). Even then, the effort to main- and languages with only two formation rules,” Commun.
tain software structure must be diligent, which may trans- ACM, vol. 9, no. 5, pp. 366-371, May 1966.
late to higher quality assurance costs per maintenance L. Brice, “Existing computer applications. Maintain or rede-
change. Later, thesecosts are hoped to be justified through sign: How to decide?“ in Proc. of the ComputerMeasurement
Group, Dec. 1981. Reprinted in [6].
increased software flexibility (able to perform enhance- R. N. Britcher and J. J. Craig, “Using modern design practices
ments faster), reliability (fewer introduced bugs with each to upgrade aging software systems,” lEEESoftware,vol. 3, no.
fix), lifetime (through extended usefulness to the enter- 3, May 1986.
prise), and reusability (due to the known software structure M. H. Brown and R. Sedgewick, “Techniques for algorithm
animation,” /€€€Software,vol. 2, no. 1, pp. 28-39, Jan.1985.
instilled in the software). E. Bush, “The automatic restructuring of COBOL,” in Pro-
Software restructuring presents a very interesting ceedings of the Conf. on Software Maintenance-1985
research area. Besides the need for quantitative studies of (Washington, DC), IEEE Computer Society, pp. 35-41, 1985.

616 PROCEEDINGS OF THE IEEE, VOL. 77, NO. 4, APRIL 1989