Better manpower utilization using automatic
restructuring
by GUY de BALBINE
Caine, Farber and Gordon, Inc.
Pasadena, California
IMPROVING THE HUMAN+->SOFTWARE
INTERFACE
INTRODUCTION
Our intent is to introduce the concept of automatic
restructuring as a powerful method for improving the
quality of software developed before the advent of structured programming. The quality improvements we are
concerned with are neither execution time efficiency nor
core size requirements but, rather, higher readability and
clear structured code. These, in turn, should improve the
reliability and reduce the maintenance costs by making
human verification more efficient.
The fact that arbitrary flow diagrams can be mapped
into equivalent structured flow diagrams by introducing
new Boolean variables has been established by Bohm and
J acopini 2 (see Reference 1 for an example of a program
that cannot be restructured without additional Boolean
variables). The first steps toward systematizing this mapping are taken in Reference 9.
In practice, however, we have found that adding Boolean
variables (whose names are meaningless since they would
have Jo be program generated) makes the code often
harder to read. Thus Djikstra's comment4 that "the
exercise to translate an arbitrary flow diagram more or
less mechanically into a jumpless one is not to be recommended" because "the resulting flow diagram cannot be
expected to be more transparent than the original one."
On the other hand, if we allow certain constrained forms
of the GO TO statement, many of the difficulties vanish
and readability can be enhanced. One form of the
constrained GO TO, which we call UNDO is used to exit
from nested structures when necessary, the jump always
being a forward jump to the end of a DO group. This is
similar to the LEAVE statement in BLISS.10
Figure 1 shows an example derived from Reference 1.
With the UNDO construct, a natural straightforward
representation can be obtained.
Based on the hypothesis that the restructuring process
could be applied systematically to existing unstructured
programs and enhance their clarity, we have designed and
implemented a software tool known as the "structuring
engine." We shall now describe in more detail some of our
motivations and the experimental results that we have olr
tained while using the "structuring engine."
Most production software in existence today was
developed using no precise design methodology. The
programming languages generally used (FORTRAN,
COBOL) were invented over a decade ago and have hardly
evolved due to the severe binds imposed by upward compatibility. Maintaining and extending the huge software
inventory is a difficult and inefficient task which is becoming even more so year by year. The software documentation is poor, the logic is often obscure, and the
authors are most likely to be gone or assigned to other
projects. Operational programs still break down with bugs
that have managed to escape the most careful scrutiny.
Modifications and extensions are dreaded and postponed
since they are likely to cause perturbations whose far ranging effects cannot be easily and reliably assessed.
We do not claim to have a panacea that can cure all of
these problems instantly. However, the experience gained
while developing large scale software using structured
programming has shown some of the important factors
that influence software reliability and maintenance costs.
In our experience, the quality of the human+->software interface is one such factor since it influences the efficiency
of all manhours invested at the program level, both during
development and maintenance.
To benefit from a better human - software interface applicable to future software development, as well as to current software, we suggest extending commonly available
programming languages, imposing some constraints to
ensure proper language usage, emphasizing the need for
visual improvement of programs, and providing transitional tools to assist in the conversion of existing software
to meet the new interface specifications.
Language extensions
The only precise, and by definition up-to-date, source of
internal documentation for most software in existence
today lies in the programs themselves. Understanding
what programs accomplish implies an understanding in
319
From the collection of the Computer History Museum (www.computerhistory.org)
320
National Computer Conference, 1975
Language usage
DO FOREVER
DO WHILE (Cll
51
END DO WHILE
IF (C2l
Providing extended languages to permit structured coding is not sufficient to guarantee software clarity.
Programmers can still misuse structured languages to
follow their traditional thought processes, the result being
obscure programs under the guise of structured code.
Rather than resort to building enforcement tools, it is
our belief that the simplicity and intellectual appeal of a
well formed program will generate the necessary motivation among programmers to adopt a new standard of
quality.
ELSE
UNDO
;----
ENDIF
Visual improvement
ENDIF
END 00 FOREVER
Figure I-Example of UNDO usage
the formalism and at the level of detail imposed by the
programming language used as a vehicle for implementation. Thus, any shortcomings of the implementation language have a direct impact on the effort needed to understand what the programs do and to modify and extend
them successfully.
The two most widespread programming languages,
FORTRAN and COBOL, do not contain adequate
mechanisms to support structured coding. The limited
facilities they provide can be exploited very cleverly to
look somewhat like structured code. However, a
substantial effort is needed to maintain proper indentation
and the legibility is never as good as that obtainable with a
structured language.
The obvious step is to build preprocessors to provide the
necessary syntactic extensions and perform some of the
manual chores such as automatic indentation. Several
dozen preprocessors have already been built to translate
various brands of structured FORTRAN into pure
FORTRAN.7 Our effort along these lines has led to the
design and implementation of the S-FORTRAN language
and translator. S-FORTRAN embodies a small but powerful set of structured constructs. S-FORTRAN was
designed to serve both as a target language for restructured programs and as an implementation language for
new programs. It is not only simple but easy to remember
unambiguously. The S-FORTRAN language is succinctly
described in the Appendix.
We do not wish at this point to discuss at length the individual merits of each S-FORTRAN feature and whether
LOOP is a better term than DO FOREVER or should DO
UNTIL test first rather than execute first. These decisions
are mostly conventions. Let us simply express the hope
that a consensus will soon develop so that a "de facto"
standard will prevail. Structured FORTRAN programs
will then be unambiguously understood by all.
Structured coding techniques require that programs be
systematically indented to stress the relationships b~tween
code segments. This hierarchical arrangement allows a
quick grasp of the global as well as the local structure of
the code. Understanding the code no longer requires keeping track of many scattered items such as labels and
transfers. Rather, it means perceiving visual patterns that
can be precisely mapped into our analytical understanding of the solution. Each part and subpart corresponds to a
block of code, carefully delimited to facilitate its verification. Systematic indentation makes it easy to collect the
conditions controlling the execution of each indentation
level down to the code segment being examined.
The power of visual perception can be readily tapped by
developing patterns whenever feasible. Symmetry, lack of
symmetry, block indentation, regularity, recurring patterns, aligned similar items, ... are characteristics that
can be detected at a glance by the eye. Interestingly
enough, these are characteristics whose global nature is
usually hard to detect and utilize automatically with
software tools.
HOW TO BENEFIT FROM THE NEW
INTERFACE
Formulating a better human~software interface is
clearly valuable for software that has not yet been written.
The important point is that such an improvement can also
be applied to a large part of the software inventory in
existence today. It is our belief that this should lead to a
. significant reduction in the maintenance effort by better
utilizing the available manpower.
Until very recently, the main route for modernizing
existing unstructured software was to start over with a
clean top-down design and structured implementation.
Needless to say, such complete manual reprogramming
should not be undertaken without a very careful evaluation of the potential gain versus the effort involved. We
have found that the major obstacles to manual reprogramming are the need for top talent during the redesign phase,
the manpower expenditure, the elapsed time before a new
From the collection of the Computer History Museum (www.computerhistory.org)
Better Manpower Utilization Using Automatic Restructuring
CFG,
PROGRAM
Hie.
CORDEspn~DING
321
PAGE - 13
FeRIT
LI~E
____ FOKTRAf\:_ll_N_E______ M.lMJlEB__
************************ FORIT
2
2____________________ ~
3
4
ENTR-V **************************
C****************** M 5 INC
12 ************************************
______S!J!3RQJ.lJJN!=__ f.Q~H ___ lftH_~!Il_,~, _hilt
IMPLICIT REAL*8 (A-H,O-ZI
___________L ______C__
DIMENSION FNTlll,AIM),8(MI
(;
C
8
q
----ii------------To--9
11
10
12
__D_
C
C
CQNST=~.141593*CCEF
12
14
_________U_
15
14 ---- -------:U;------1"
17
18
__ .LL_
___!',
20
30
21
22
- -- - --COEF;="(;;O/(N+o~5-i --- --51-OS HdCONST)
__________ Ll,.Qr;CHcQ~_SlJ
C=I.0
5=0.0
13
16
************************** LOGIC START ***************************
f:NTi;;;F~Tnl
J= 1
"'1=M+l
N2=N+N+l
---.- ---UEtiiif·- "A FR PR-cfcEDuR-E-oo-ii-----·
-
-t---------------------------~--------------------------
31
__ n
_~_2
100 W~!H*~~~~:~)
_J."_
__5_=(:1*_S_.+_S.l*_C
I
c=c:
J _____.,!~__ .,J+_l___ _
2~
END
WHILE
1_____________________
I
27
--1"6~T
__
.f.Ht1!If. (AFR PROCEDUREOOll
I
26
---------,
---------------\--"
__ _ ___ __ J
24
33
.Ll. 0)
00
I
I
I
I
I
_ ________________
___________________________
1
-- - i - e - - ~ (jr;;;ATjj*o.~
RETURt.;
--(.;::.:.:::.:.::.:.:.:.:.:.:--- -
______ ?_(~______
30
EECCfuuaf CAFR PROCECURE001J
31
C
-------------.-- 32
33'--- . -t-
- -~~-~-tt"'PutE
-2723
--""l,,---25
26
RECURSiVELY
ui;o~6-
I=N2
22
~ 10 --
F6URIER-CbEFF-Iti~NTS
U2=0.0
20
--2C
,------------------------------------------------------------------------------------,
------Hllr".iJ!tlll-nf-..:l.r~lE.-O-J .
I
I
UO=FNTCIJ+Z.O*C*UI-U2
I
-- ---r-------uz-;;Ui-------------------T
I
Ul=UO
I
I
I : I-I
I
'.E1l0
OJ:
Uf:U1L
I
.
. . . . . . . . . . . ______ ______________' ___________________________1
-~-1-
38
----:3"9-40
41
42
1=~:...
~~
:..:.::.:..:~
~
- ATJ}=ttEF-.(FNT i+C*IJl:"U;()
2S
B(J
29
I-CDEF*S*Ul
45
5
46
•
'7
c
-----_._-------_.. _---------_._-------------_.-
*********************** FORMAT STATEMENTS ************************
47
************************ END PROGRAM UNIT ************************
48
END
·!O-_
PROCEDURE CReSS_REFERENCE TABLE
PRCCEfJlJl:!E
LQCAI ION
31
_REFERENCES
- -20
Figure 2-Sample program FORIT before and after restructuring
From the collection of the Computer History Museum (www.computerhistory.org)
322
National Computer Conference, 1975
18:03:30
F~CGPAM
FORTRAN
PROGRA~
CI DEC 74
PAGE
INPUT
LINE
INPUT F'lRTPAN STATEMENT
NU~RER
. c******SURROUTINE
•• **********
~ SIN C
12 ********.*** .... *•• ************.*****
FORIT IFNT.N.M.A.BI
I~PLlClT
RfAL*R
CI~ENS!rN
••• SET
IA H.O-ZI
<NTlll.AIMI.BI~1
CC~STAMS
C(lEF=I.OICN+O.~1
q
IC
11
12
13
14
I ~
16
17
IE
19
COST=3.1415B*COEF
51=051 NI CO~STI
CI=~COSICnNSTI
C=I.O
5=0.0
FNTZ=<NT III
J=I
loll I ='-'+1
N2=N+N+1
••• COMPUTE FOURIER COEFFICIENTS RECURSIVELY
-----~~O~I_ _--'-'70~~~=:~"-':"'-~
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
22
23
24
I=N2
75 UO=FNTC!l+2.0*C*UI-LJ2
L2=UI
2~
UI=LO
26
1= I-I
-----2i-----------iTfI=lf-lic.80
.75 - - - - - - - - - - - - - - - - - - - - - - - - - -
2e
20
30
31
_ _ _ _ _-:3~2
__
34
35
36
37
38
AD AIJI=COEF*IFI'HZ+C"UI-U21
B I J I=CCEF.S*U I
IF I J-~II ~O.lOO.I(;O
°0 (=(I*C-SI*S
S=Cl*,-"-S",,,+S--,-,I*:.>.C_ __
C=C
J=J+I
Gr TO 70
10C AIII=AIII"C.S
RETI'~N
_ _E~~~D_ _ _~~
system is up and running and the penalty for having to go
through a full testing and debugging period again.
As an alternative, we have _developed a method which is
much easier to apply in practice. It consists in keeping the
global design as is, in particular the data structures, and
in automatically transforming every program into an
equivalent structured program, visually improved to make
its reading easier and its understanding more thorough.
This method is supported by a software tool known as the
"structuring engine." We have applied this tool to a variety of FORTRAN programs. We shall now describe the
characteristics of the tool and some of the experimental
results that we have obtained so far.
THE "STRUCTURING ENGINE"
Capabilities
The "structuring engine," as it now exists, is a large task
running on an IBMj370 under VS. It consists of over
30,000 lines of structured PLj 1 code. It will restructure
programs written in FORTRAN including --any language
extensions acceptable by IBM, Univac, CDC and
Honeywell compilers.
Each program or subprogram is restructured independently. The complete flow graph of each program or
subprogram is analyzed to determine the best strategy for
obtaining a well structured program. Machine dependencies are taken into account when building the flow
graph because the interpretation of some statements depends on the particular compiler that the program was
intended for. For instance, values outside the range of a
computed GO TO can be handled in three distinct ways
depending upon the particular compiler implementation.
Such variations are taken into account by the "structuring
engine" which generates the necessary statements to
guarantee consistency in the restructured output.
In general, the restructured programs will bear little resemblance to the original unstructured ones, particularly
if the logic was complex and somewhat twisted to start
with. In the output, the logic flows from top to bottom,
from the single entry to the single exit.
Figure 2 is an example of a simple program before and
after restructuring. Similarly, Figure 3 shows what happens in the case of a heavily folded program.
The restructured programs are equivalent to those from
which they are derived in the sense that they behave
identically at run time. That is, they carry out the same
sequence of operations on the data structures, great care
being taken that the ordering of operations not be
modified. For instance, a three way arithmetic IF cannot
be simply converted into two nested S-FORTRAN IF
statements because the arithmetic expression would then
be evaluated twice. In that case, incorrect results might be
obtained if the arithmetic expression contains calls to aIr
normal functions i.e., functions which do not always
produce the same results from a given set of inputs.
One of the basic processes used in restructuring is
known as node splitting. If a node of the subgraph can be
reached from two different paths that must be separated,
the node is split into two identical nodes so that each path
can have its own copy of the node.
If the node splitting operations were carried out indiscriminately, the resulting S-FORTRAN programs would
often become so large as to be virtually useless. Not only
would clarity be lost but the object program would be
likely not to fit in the target machine. To circumvent that
From the collection of the Computer History Museum (www.computerhistory.org)
Better Manpower Utilization Using Automatic Restructuring
difficulty, the "structuring engine" tries recognizing
proper subgraphs that can be turned into procedures
instead of being duplicated in line. A procedure is simply
a section of code with one entry and one exit. This concept
corresponds to the PERFORMed group in COBOL, but
with additional constraints to guarantee a clean invocation
and a clean return. Once a procedure has been extracted
and given a name, it can be referenced from many locations within the restructured program, including from
other procedures. The example in Figure 2 contains one
procedure, the one in Figure 3 contains two. The decision
whether to expand code in line or create procedures can be
externally controlled using a threshold which indicates
how complex a subgraph must be before it becomes a
procedure. Procedures are not separate subprograms.
Rather, they are segments of code that can be executed
from various locations within a particular program or
subprogram. The EXECUTE command hides the
ASSIGNed GO TO linkage that a FORTRAN programmer
would have to set up otherwise.
To visually improve the resulting code, every statement
is laid out according to its logical indentation level. This
stresses its relationship with other statements in the same
program unit. A box is built around each complete DO
group to enhance the scope of the DO statements. Statements such as UNDO, CYCLE, and RETURN are
followed by an arrow that attracts the attention of the
reader and shows him immediately what implications
tnese statements have on the logic flow. Consecutive comment cards are right adjusted by block in order to make
them as unobtrusive as possible.
Of course, if the modules to be restructured contain
logic errors, the same errors will be found in the structured
output. In general, the "structuring engine" is incapable of
detecting errors except for some obvious language violations. The input programs are supposed to have compiled
correctly so that the errors we are really trying to
eliminate are errors in the logic that cannot be identified
without an intimate understanding of the problem. Only a
programmer aware of the problem being solved can discover and correct these errors.
Emphasis in building the "structuring engine" has been
on reliability rather than efficiency. This has been
achieved through a combination of structured design techniques, self identifiable data structures and dynamic
assertion verification at run time i.e., the constant verification that the assumptions underlying the design are never
violated during production runs.
Experimental results
We are currently applying the "structuring engine" to a
wide variety of unstructured FORTRAN code. Although
our analysis is far from complete, we would like to comment on some of the experimental results that we have obtained so far.
CFG.
INC.
PROGRAM
323
31 JAN 75
PAGE
FORTRAN PROliRAM INPUT
LINE
NU~BER
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
lB
19
20
21
22
23
24
25
26
27
2B
29
30
31
32
33
34
35
36
37
3B
39
40
41
42
43
44
45
46
47
48
49
50
51
5Z
53
54
55
56
57
58
59
60
61
INPUT FORTRAN STATEMENT
,*•••••
C •••••• REF: LSTAT
ALIAS URDB
ELEHENT NAME: OR[)S
••••••••••••••••••••••••• OROB
OR~8
INTEGER FUNCTION LSTATILlNE.FLAGI
IMPLICIT INTEGER I A-YI
ORDB
O~OB
DATA NIV/5/
COMMON/ARRAY/C.lINOWN. (.L:AROIBOI,PICTURI 13201, BUfHR1l5.2001
ORUb
COMMON/DEBUG/DEBUG
D~OB
COHMON /EfNARR/LENGTH,NREf,REfHAX,MAXLlN.EfNLISIl507I,CREF130001
ORDB
CQHMON/RANGE/Kl.K2
OROB
LUGI(.AL HAG
01<08
L=L1 NE
ORDB
TARGET=L INE
ORDS
SwiTCH=1
O~DB
65 KOUNT=1
OROB
70 L-HDDIL
-1.LENGTHI+l
ORDB
L1NOLD=fLDIO,1B.EfNLlSILIl
O~DB
IF ILiNOLD.EU. TARliET IGD TOI1l5,IBO.140,1501. SwITCH
OR Db
I f ILiNOLD.EQ.OIGO TJ 255
OR OS
IF lKOUNT.EQ.LENGTHIGli TO 255
OROB
IF lKOUNT .EQ.1IL1NC-MJDlL-I,LENGTH-1I+1
Of<OB
L=L+L1NC
DRDS
KOUNT=KDUHT+l
DROS
GO TO 70
OROB
115 L1NEW-FLDIlB.IB.EFNLlSIl.1I
OROB
LTEHP-Kl*LINEW+K2
OROB
FLAG I S TRUE IF LINE IS A SUTEHENT EfN
OROB
FALSE IF LINE IS A REFeRENCE TO AN eFN
OROB
I f IFLAG.OR.NREF.LT.OIGD TO 260
OR DB
C
SUlLO CROSS REF LIST
OROS
If lNREF.EQ.REFNAXIGO TO 235
OROS
IF ILiNOWN.GE.MAXLlNIGO TO 195
OROS
OLD EFN FOR CURRENT LINE IS LINOWN
DRDS
IF ISWITCH.LT .4ISWITCri-SWITCH+l
DROB
TARGET -L I NDWN
DROS
L-L1 NDWN
DROB
GO TO 65
OROS
lBO CURLIN-FLOIlB.1B.EFNLISI1i1
DRDB
CURNEW-KI*CURLlN+K2
DROB
GO TO 200
OROB
195 CURNEW=KI*ILlNOWN-HAXLlNI+K2
D~OB
200 NREF-NREF+l
DROB
FLOlO.18,CREFINREfli -LTEMP
OROB
H0I1B.18.CREFINREFII-CURNEW
DRDB
IFlDEBUG.GT .NIVIPUNT UO.NIV.L.TEHP.CURNEw,NREF,CREFINREfI
DRDB
220 FOR.HATC· NIV·.13.': ORoa LTEMP··,[S,· c.URNe .. ··,ls,
DRoa
l ' CREFP,JIt,q"",ulzt
DROB
GO TO 260
ORDB
235 PRj NT 240
DRDB
240 FDRMATllx.10IlH*"28H CROSS REFERENCE TABLE FULL ,9011H*1I
ORDB
NREF--NREF
OROB
GO TO 260
DR DB
1"0 CURNEW-CURLlN+K2
DRD8
GO TO ZOO
DROB
150 CURLIN-HDllB.18.EFNLISILII
D~D8
GO TO 140
DRD8
255 LTEMP-O
ORDB
260 LSTU=UEMP
DRDB
IflDEBUG.GT .NIVIPRINT ~70.Nlv.LlNE.FLAG.LTEHP
ORDB
210 FORKAT(' H[ V'. [3,'': DRoa LINE-', 15,' FLAG&' .Ll.' LSTAT-', '5.
DROS
RETURN
OR DB
END
OR08
Figure 3-Sample program ORDB unstructured (Part I)
Clarity of the restructured programs
A reliable assessment of clarity improvements is obviously quite difficult to obtain until we get some figures
on maintenance costs. The familiarity of the end user with
structured code is a factor as noted in Reference 6. The
cleverness of the "structuring engine" in making the right
choices is obviously another important factor since there
are not one but many solutions to the restructuring
problem. So far, we have found that:
• the majority of the programs (about 90 percent) will
come out extremely clear, at least in our opinion and
in that· of end users that have worked with restructured programs.
• the rest (about 10 percent) will either remain complex
or become lengthy or both. In this group, we find a
number of programs that could be handled more
cleverly by the "structuring engine" and, therefore,
move into the above category. We are obviously building the necessary improvements into the "structuring
engine." Still, there are some programs that will
probably never look very good. They are ill-designed.
The problem that they are supposed to solve should
be reexamined and a complete redesign and
reprogramming of these programs may be necessary.
From the collection of the Computer History Museum (www.computerhistory.org)
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2~
24
25
26
27
28
29
30
31
32
33
34
35
36
37
3B
39
40
41
"2
43
Itlt
45
"6
47
48
49
50
51
5Z
53
54
55
51>
57
58
59
324
National C~mputer Conference, 1975
[~C.
CFG,
03:50:54
,
[~PUT
LlNF
CLTPuT
LINe
TI<l.I~
.. 1 JAfIo 15
r~~ST
JUT~uT
LEVE:L
************** •• ** ••••••
,FORTRAN
L!) TA T
STATlMt~T
ENTRY •••• * •••••••••••••••••••••
c ••••••
RtF: LSTAT
ALIAS
URDS
t:LEME:I.... r ,~AME :UROd
..................
[IIoTE(,tR FJNCT ION LSTAHlINi:,flAGI
[MPLlC iT [NTl:ul:l\ l .. -YI
UATA NIV/5/
CCMM IN / ARRAY II. ,lI NU.N ,('LCARDI 80 I, PIC T Ukl 1 .;>LUI ,oUFf cKI 15,2 Jill
LuM~UN /DtoU(;/DEoUu
~ "MMUN / EFNARi<1 L EN"T H, Nil.cF, REF MAX, MAXL IN, EFNLI S I l:;b 71 ,,,,KeF I
301.101
COMMON IRANC,E/K1,KL
LJG Il:AL fL AG
**.* ••••
c******
8
9
9
10
II
10
12
11
14
12
13
14
15
Ib
PAGE
T URt:D SFOR TRAN PkUukAM
•••• ** ••••••• * ••••••••••••
luG Ie STAR T •••••••••••••••••••••••••••
L =Ll IIoE
TARGET=lINE
owl TeH=1
"uUNT= 1
17
,---------------------------------------------------------------------------------T
18
15
16
17
18
56
19
5b
1~
20
21
22
23
24
25
2b
27
18
liIJJ EllI1£ua
I
L=MOiH L -I,LENGTHI +1
I
LlNULD=FLUludd,HNlISILlI
I
J.t . I Ll NULL/.Ne. T ARC,ET I
I
I I ILlNuL".~~.UI
I
LTEMI'=U
Utli.lU 18
I
(-----------I
fWiUt IKUUNT .E'-I.LENGTH!
I
LT E:MP=U
I
UtiilU 18
<-----------I
28
29
I
I
3u
17
24
25
28
31
32
33
3't
35
36
I
I
I
I
I
I
I
I
I
I
~ll
IM~
f.llfC.UU.
Ull
I
PkuClDURt002!
\
,--------------------------------------------------------------------------,
I
I
I
I
I
IUU i.A.:if ,,,1 TCti
I
I
(.AS.t. 1
I
I
I
I
I
I
I
I
I
lINI:,,·FUI 18.18, EFNLlSILlI
LT tMI'=Kl*L INE~+K2
FLAu IS TRUE IF LINE I, A HATEMHH EFN
FALSE IF LINE IS A kHERtNCi: TlI AN EFN
i t IfLA".UR.NREF.LT.OI
UWl.J 18
I
I
I
I
I
I
tL.llJ.E
I
37
38
I
I
(-------------------30
48
50
31
40
39
4U
41
42
43
4 ..
45
4b
41
4,
4~
33
33
34
35
14
37
38
52
54
52
18
56
50
51
52
')3
54
5,
5b
57
58
59
5b
I
NREf=-NREF
~-------~------------ "~u.J
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
J.t
I
ftiI.! I I
TA~"ET=L1NOWN
L=lINO~N
~UU"T=1
I
I
I
I
I
I
.c.AS,f.
LUKLlN=FlDIl8.ld,EFNLI~ILlI
:
:
~~~~~K~:~~R~!~~~~URE(lO!J
:
I
:
65
66
67
68
6';
J
I
I
~-------~-------- UtillQ
70
:
:
I
I
77
70
N
I
I
I
C.A~t I.~RNEW=CURL IN+K2
64
:
I
:
:
I
I
I
I
:
(.A.>.J; 4
:
~UKLlN=FLDIUj.18,HNUSI1I1
~URi'<l:w=CURLlN+K2
\
fU(;UI~ I AFR PROCEDUREuUd
I
I
1d
I
iJTHER
i f ILIJIIOlD.EU.OI
LTEMP=O
UtiUIl 18
tl.llJ.t
IKUUNT.EQ.LENGTHI
:
:
~~~8P~~
(-------------------I
I
I
:
(.II~~
!I _______ ~I ____________
I
I
I
I
I
I
I
I
!
18
f.l>f.\.Ulf I AFR PROCEDURI:Jul1
~ _______ ~ ________ UtillU Iii
I
I
I
l
61
62
63
74
75
70
IS L1NO~N
~w1TCH·S~ITCH+1
~ _______ ~ ________ UtiUU
71
7L
J
OLD EFN FOR I.UKRE:NT LINt:
IS,dH.H.LT.41
I
I
I
I
18
I
J
:
fll!Ul.f
I
I I
I I
I I
I
CURNi:~aKl. III NOwN-MAXLI NI +K2
f.l>~I~ IAFR PROCEUURt:OOll
I
I
I
I
I
I
I
I
I
I I
I
18
fLHU ILlNO~N.GE.MAXLlNI
~-------~------------ UWlU
I
I
I
I
I
I
I
I
I
I I
BUILD CROSS REf- LIST
1;~REF.EfJ.REFMAXI
P~INT 9002u
60
73
[ 9
I
I
I
:
I
ttlD lE
fl>fLUH I AFR PRUCEOURdiOd
IliBi Il.! ('AU
I
:
I
I
I
:
:I
I
I
I
1 _____________________________________________________ ---------------- _____________ 1
.f;tli:l I I
I.t.tllo! J.!ll f.LLIi.t.llE.t1
I
1 _____________________________________________________ --------------------------_______________ 1
L:>TAT=L TEMP
lDdUG.GT ."IV!
PRINT ~vO.;>v, IIolV,ll"c,fLAG,LTI:MP
1.t.
.f;tlU J.t
KE TUKi'<
<--------Figure 3-Sample program ORDB restructured (Parts II and III)
From the collection of the Computer History Museum (www.computerhistory.org)
Better Manpower Utilization Using Automatic Restructuring
325
Execution characteristics of the restructured
programs
Let us now try to answer some of the most common
questions regarding this automatic restructuring process.
What price do we pay for the improved clarity of the
restructured programs? In particular, how do the restructured programs execute compared to the original ones?
To answer these questions, we must first examine the
various components in the processing chain as shown in
Figure 4. The "structuring engine" transforms unstructured FORTRAN into structured S-FORTRAN. The
resulting S-FORTRAN programs are then translated back
into FORTRAN using the S-FORTRAN to FORTRAN
translator. At that point, we have pure FORTRAN source
code again which can be compiled, loaded and executed.
Thus, the characteristics that we are reporting on involve
not only the "structuring engine" but also the translator
and a compiler.
The core size of the object modules produced from the
restructured programs has been found to always be larger
than that of the original modules, typically by about 20
percent.
We know from Reference 9 that arbitrary programs cannot be restructured without increasing their running time
CfG,
INC.
31 "JA.N 75
STkUCTUREO SFORTRAN PI\Ol;kAI'I
INPUT
OUTPUT
LINE
LINE
NEST
LEI/EL
JUTPUT SF OR fRAN SYA TE:.HENT
. . . . . . . . . . . . . . . . . . . Afk PRQCEOURfOOl PROCEOUkE: ••••••••••••••••••••
8a
89
..
41
42
43
eaQk.t~
lAfk PROCi;uuRl::uOLJ
NREf~NREF+l
90
91
92
93
9.
95
FlOIO,lB.CREf(HREfJJ :&lll:HP
FLO' 18, 18, CREF CHRff J J*CURNEW
.1f COEtiUG.GT.N1VJ
Ull J.E
tWl fJWr.tllll&f
97
~
PRINT 90010. NIV,LTEI1P,CURNEW,NREF,CREfiNREFJ
•••••••••••••••••• AFIC. f'KuCEDURf002 PRoe EOUKE: ••••••••••••••••••••
20
20
<a
.9
100
101
102
103
21
22
CUR PRUC£;OIJReIlOZJ
lE (KOUHT .. EQ.1)
l INC:&/ilOOCl-l ,U;NuTH-ll +l
tWIll
l-l+lIf04C
KOUNTsl<.OUNT + 1
fWl f.IIJlUQU&f
STRUCTURING
ENGINE
FORTRAN
UNSTRUCTURED ' - - - -....
ONE TI ME TRANSLATION
I
I
I
I
I
I
OBJECT
MODULES
STRUCTURED
$-FORTRAN
COMPILER
MAl NTENANCE AND/OR DEVELOPMENT OF
RESTRUCTURED PROGRAMS
"".
Figure 4-The restructuring chain
or their core size. In the present case, we have chosen to
accept a limited increase in memory size. The creation of
internal procedures is our method for preventing a
program from growing beyond an acceptable point.
Figure 5 shows a typical distribution of core size expansion ratios (1 would mean no increase) as a function of the
size of the object module for the unstructured program
when compiled with IBM's FORTRAN G compiler. The
circled data point corresponds to a program that the
"structuring engine" could not structure without producing three times as many S-FORTRAN cards as there were
FORTRAN cards. This "abnormal" expansion factor was
caused by a deeply nested section of code that could not
be turned into procedure because it would then have
contained an UNDO outside its scope. Such an UNDO
outside the scope of a procedure is not permitted in SFORTRAN. Consequently, the same section of code was
duplicated 18 times throughout the program.
Data on the execution speed of the restructured programs has been harder to get because most of the programs we have restructured so far were components of
much larger systems which we could not run ourselves.
Preliminary results show that we should expect slight
variations in the running time with a trend toward a re-
. . . . . . . . . . . . . . . . . . . . . . . . fORHAT STATEMENTS ••••••••••••••••••••••••
105
106
90U10 fORMAT ,.
1:::' ,Oll)
NIV',IJ,': UROti LH:MP=',15,' CUkNfW .. ',15,
I
CREFI',IIt,'j
Object size ratil) (G)
o
90Q20 FORHAT llX,lOIlH."2tUi CkOSS REFERENCE TA6L~ fULL ,9QIlH*JJ
•••••••••••••••••••••••• END PROGRAM UN! T ••••••••••••••••••••••••
PRu~t;DiJRE
lOC.ATlON
AFR PROCEDlIREOOl
AFR PROCEDUREOOl
CROSS_REFERENce TAblE
.
RfFERI:NCeS
88
4b
97
29
59
10
"....,
FORHAT CkOSS_REFERENC.1: TAbU
FOflMAT STATEMENT
NUMBER
9COIO
90020
90030
REFERENCE~
1.,5
107
108
OJ
41
k bytes
a4
Figure 3-Continued
Figure 5-Core size expansion ratios
From the collection of the Computer History Museum (www.computerhistory.org)
326
National Computer Conference, 1975
duction rather than an increase. This may' seem paradoxical at first but can be explained as follows. There are
two major factors that influence the running time in opposite ways:
(i) the size of the basic block: the restructuring process
cannot decrease the average size of the basic block
and in general will increase it. Thus, an optimizing
compiler should generate better code within each
basic block of the restructured programs.
(ii) the control flow statements produced by the transla- .
tor to support branching, looping and procedure
referencing: These require, in general, more
instructions than needed to implement the original
control logic.
The first factor tends to make restructured programs
run faster whereas the latter tends to slow them down.
This means that with a translator generating very good
code we should be able to have programs run faster
restructured than unstructured. In fact, we have now built
more sophistication into the translator than had been
originally planned in order to make full use of the capabilities of optimizing compilers. For instance, with IBM's
FORTRAN H (OPT=2) compiler, changes in the translation of IF statements have reduced in one instance the
core size by 12 percent and the running time by 8 percent
when compared with earlier versions of the translator.
CONCLUSIONS
Automatic restructuring as implemented by the "structuring engine" is proposed as a method to modernize existing
programs. It should prove much more practical than
manual reprogramming, particularly with regards to manpower requirements, conversion time and the reliability of
the conversion process itself.
Manpower requirements are reduced since no major
human effort is invested redoing what already exists. On
the contrary, programmer time is devoted to perusing
restructured programs, implementing improvements
wherever deficiencies show up, and correcting errors. In
particular, any program which still appears to be overly
complex after restructuring compared to what it is supposed to accomplish, becomes a good candidate for an indepth investigation of the reasons underlying its apparent
complexity. Poor algorithms may be pinned down fast and
replaced accordingly. The overall result is that the
programmer understands the structured code more
rapidly and can, therefore, allocate more time to difficult
areas. Consequently, his error detection rate increases,
thus justifying our claim to improved software reliability.
Conversion time is negligible compared to that required
for manual reprogramming. In particular, the project's
clock is not set back since the restructuring process does
not introduce any new errors.
Of course, there may still be cases where complete
redesign and reprogramming appear to be absolutely
necessary. Under those circumstances, the "structuring
engine" can still play an important role. Indeed, no matter
how unstructured and clumsy the original software may
be, it represents an approximate solution to the problem,
correct in most if not all of the cases. As such, it acts as a
repository for a wealth of details that were added
throughout the life cycle of the software to handle unusual
and certainly unforeseen cases. Starting from this rich
data, the "structuring engine" becomes a very valuable
tool since it produces an up-to-date structured picture of
the solution currently implemented. This picture may
then be used to base a thorough evaluation of the status of
the project, including any needs for manual redesign and
reprogramming.
APPENDIX
The main characteristics of S-FORTRAN are:
(a) S-FORTRAN is a superset of FORTRAN (including
the FORTRAN language extensions provided by
various manufacturers).
(b) Any construct with a scope has both an opening and a
closing delimiter. If the opening statement is XXX,
the ending statement is of the form END XXX. (e.g.,
IF ... END IF, DO WHILE ... END DO WHILE).
(c) The IF includes any number of ELSEIF clauses and
an optional ELSE clause. ELSEIF's are often convenient to prevent very deep indentation levels (and
the so-called "wall to wall" ENDIF's).
(d) Repetitive DO groups include a DO FOR analogous to
the FORTRAN DO loop, a DO WHILE, a DO
UNTIL (which is in fact a DO AT LEAST ONCE
UNTIL), and a DO FOREVER (an infinite loop).
(e) Non repetitive DO groups include a DO for bracketing
statements, a powerful DO CASE, a DO CASE SIGN
OF which is the equivalent of a three way arithmetic
IF, and a DO LABEL to handle abnormal returns
from subroutines and functions and end and error
exits from 110 statements.
(f) UNDO is a mechanism to exit from a DO group prematurely. We have found this multilevel exit
mechanism to be superior to introducing switch
variables which tend to clutter the program and make
its logic harder to follow. UNDO is applicable to any
DO group, repetitive or not. It can be followed by a
label if another DO group besides the innermost one is
to be exited from.
(g) CYCLE is similar to UNDO but implies skipping any
statement until the closing delimiter of a DO group is
found. The test controlling the repeated execution of
the DO group is then performed to determine whether
to exit or repeat. CYCLE is only applicable to repetitive~DO groups.
(h) Internal parameterless procedures can be defined using PROCEDURE ... END PROCEDURE. Their
execution can only be triggered by an EXECUTE
From the collection of the Computer History Museum (www.computerhistory.org)
Better Manpower Utilization Using Automatic Restructuring
(proc-name) statement. Premature termination of a
procedure can be accomplished by an EXIT statement. Procedures share the same data space as the
program in which they are contained.
REFERENCES
1. Ashcroft, E. A., Z. Manna, "The Translation of 'GOTO' Programs to
'WHILE' programs," Proc. IFIP Congress 71, Ljubljana, Aug. 1971.
2. Bohm, C., G. Jacopini, "Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules," Comm. ACM, May 1966,
pp. 366-371.
3. Caine, Stephen H., Reference Guide to the XXX Language, CFG 708-001, Feb. 1971.
327
4. Dijkstra, E., "GO TO Statements Considered Harmful," Comm.
ACM, March 1968, pp. 147-148.
5. Donaldson, James R., "Structured Programming," Datamation, Dec.
1973, pp. 52-54.
6. Holmes, Charles E. and Leslie W. Miller, "Chief Programmer
Experience," GUIDE 37, Nov. 1973.
7. Miller, E. F., Extensions to FORTRAN and Structured Programming-An Experiment General Research Corp., RM-1608, Feb. 1972.
8. Mills, Harlan D., "On the Development of Large Reliable Programs," IEEE Symp. Computer Software Reliability, 1973, pp. 155159.
9. Peterson, W. W., T. Kasami and N. Tokura, "On the Capabilities of
WHILE, REPEAT and EXIT Statements," Comm. ACM, Aug.
1973, pp. 503-512.
10. Wulf, William A., "A case against the GO TO," SIGPLAN Notice,
Nov. 1972, pp. 63-69.
From the collection of the Computer History Museum (www.computerhistory.org)
From the collection of the Computer History Museum (www.computerhistory.org)