Structured programming: a tutorial guide

Structured programming. A tutorial guideR.W. Whitty, N.E. Fenton and A.A. Kaposi

Indexing terms: Structured programming, Flowcharts, Program testing, Top-down design

Abstract: Structured programming is presented as a specific discipline of software engineering. The historyof this discipline up to the mid-1970s is summarised and three subsequent approaches to its theory andpractice are described. The emphasis is on providing a working familiarity with the underlying concepts andhow they are formalised.

1 Introduction

7.7 Background

Structured programming is now almost 20 years old. Whenit was first emerging Basic was brand new; the cheapestever IBM computer, offering 8K 16-bit words of core storage,cost over £12 000; R.K. Richards [83] wrote 'the fourthgeneration, whatever that will be, is not yet in sight'.Despite this relative venerability and the fact that hundredsof articles have been published on its theory and practice,there is still little agreement in the profession as to whatstructured programming actually means [56]. Practisingprogrammers or systems analysts who claim familiarity withit may in fact be using one of a variety of methodologiessuch as structured analysis [85], structured design [94] ortop-down functional design; or they may regard all suchapproaches as expensive and pedantic common sense,adhering to none of them [110].

In this tutorial paper we will present structured pro-gramming as a quite specific discipline and as a basis fordeveloping a versatile engineering theory. By summarisingthe history of the subject and some modern approaches toit, we hope to provide readers with the means and motiva-tion to adopt such a theory as one of the tools of theirtrade.

In the remainder of this Introduction we describe thefundamental engineering principles underlying structuredprogramming, explain how they are reflected in the studyof program control structures and discuss their importancein modern software production and computer science.

7.2 What is structured programming?

A fundamental approach to engineering system develop-ment is top-down design (or stepwise refinement in pro-gramming terms [105]). A system is first viewed as ablack box which performs some function linking a single-input stream with a single-output stream. To design the

Paper SM85, received 3rd May 1984Mr R.W. Whitty and Dr. A.A. Kaposi arc with the Department ofElectrical & Electronic Engineering, Polytechnic of the SouthBank, Borough Road, London SE1 0AA, England, and Dr. N.E.Fenton is with the Mathematical Institute, 24-29 St. Giles, Oxford,England

54

system, we specify a decomposition of the box into avariety of simpler functions combining to produce theoriginal function. Each of these simpler functions is itself aone-input, one-output black box to be designed in thesame way. The design process is thus recursive or hier-archical in nature and may be represented as a tree (seeFig. 1). Every node in the tree is a black box, and everynode has a group of adjacent 'successors' below it in thetree, unless it is on the bottom level. The tree is completewhen all the nodes on the bottom level represent 'func-tional primitives' in that they are available off-the-shelf or,in our case, in-the-compiler. These are functions that do notneed to be designed.

Fig. 1 Top-down functional design hierarchy

The functional hierarchy tree just described is not acomplete design of the system — there is as yet no informa-tion about how the successors of any node (i.e. thefunctions within any black box) are to be combined inorder that they collectively perform the function of thatnode. How this combination is made depends on the typeof engineering involved. In sequential programming it isgenerally accomplished by specifying a conditional flow ofexecution of the functions. We refer to this as a 'controlstructure'.

Furthermore, any control structure on one level of thehierarchy has to replace some node in a control structureon the next level up (because, in the final implementation,only primitive functions and the control structures corn-

Software & Microsystems, Voi. 3, No. 3, June 1984

bining them may appear). Thus control structures must becapable not only of combining functions but also othercontrol structures. In sequential programming this may bedone by making the node a procedure or subroutine call(for example if a function node has been duplicated) or by'nesting' control structures (for example to get nested loops,nested IF statements etc.).

Structured programming is a programming discipline. Itstipulates that program design and analysis should beexclusively concerned with programs which use only a fixedlimited class of 'primitive' control structures to combinethe successor nodes in their functional hierarchies.

A program which satisfies this requirement has an overallcontrol structure which mirrors its functional designhierarchy. It is a hierarchy built of the primitive controlstructures and can be referred to as being 'structured' interms of these control structures.

A few remarks are appropriate at this point to illustrateour discussion and place it in a more familiar programmingcontext.

Interpretations of the concept of control structures varyaccording to which aspect of structured programming isconsidered to be most important. Originally, structuredprogramming concerned the primitive control structuresSequence, Selection (IF-THEN-ELSE) and Iteration(WHILE-DO) represented by ordinary flowcharts as shownin Fig. 2. Because of this we shall use the term 'flowchart'for control structure in this paper except when a moregeneral or abstract interpretation is under consideration.

The role of the GOTO statement in this design process isvery ambivalent. It is a means by which a programmer,frustrated by a limited choice of system-defined controlstructures, may create his own. The choice of primitivecontrol structures then becomes potentially infinite. Inthe absence of a detailed functional design this can lead toundisciplined logical tangles with dire effects on later stagesof the program life-cycle. On the other hand, Knuth [64]has shown that using the GOTO is sometimes the morenatural and efficient programming option. In some languages(for example Basic, Fortran and APL) the programmer isforced to build his own IF-THEN-ELSE constructs andWHILE loops in this way.

7.3 Why do we need structured programming?

Attempts to establish the cost-effectiveness of structuredprogramming in the software life-cycle meet two obstacles:

(i) First, the difference of opinion as to the meaningof structured programming, as described in Section 1.1.This means that aggregating the experience of several pro-gramming teams, each claiming to use structured program-ming, would probably be meaningless.

(ii) Secondly, the lack of any widely accepted measuresof software quality. Without such measures, no evaluationcan be made of evidence that structured programming leadsto 'better programs'.

However, there is wide acceptance on intellectual andintuitive grounds that the use of some structured method-ology in design and analysis is important. Such as it is, theevidence supports this [5, 7, 8, 45, 52, 73]. In any eventwe can make certain well defined claims:

(i) Structured programs are easier to test and debug(see Reference 111, for example). In the traditional engin-eering disciplines it is generally possible to derive conditionsunder which the correctness of all functions in a black boximplies the correctness of the black box itself. In sequentialprogramming no such conditions are yet available becauseof the complex way the functions are combined. The bestchance lies in keeping this combining structure as simple aspossible. If a program is structured using a small number ofwell understood primitive control structures, one is thusbetter able to design an intelligent testing strategy for it,to quantify the success of the testing and to analyse thebugs that are identified.

Fig. 2 Primitive control structures

SequenceSelectionIteration

(ii) Structured programs are easier to understand andtherefore easier to modify (see Reference 40, for example).This is accepted by no less a commercial authority thanPeat Marwick Mitchell [87].

(iii) A theory of structured programs that is sufficientlyrigorous and general provides a conceptually simple approachto some other problems connected with program analysis,for example design of software metrics, loop optimisationetc. (see Reference 55 in connection with this).

1.4 How is structured programming made scientific andeffective?

So far we have merely described what is effectively engin-eering common sense. To tackle the type of problems out-lined in the preceding Section we need to establish a hardscientific theory. This paper describes how and to whatextent this has been achieved since the conception ofstructured programming. In Section 2 we describe its originsin the notorious GOTO-controversy and its theoreticalfoundation in the work of Boehm and Jacopini and others.Subsequent developments are treated in Section 3, and inSection 4 we give details of three quite dissimilar modernapproaches. We end in Section 5 with our view of thefuture of structured programming in the light of the de-velopment of concurrent, functional and logic-based pro-gramming languages.

Software & Microsystems, Vol. 3, No. 3, June 1984 55

2 The origins of structured programming

2.1 Elimination of GOTOs

In Section 1.2 we described structured programming in aquite general form as a design methodology. However,like most powerful theories it began with experimenta-tion and the investigation of a particular problem.Schorre [86] is quoted by Knuth [64] as the earliestpioneer:

'Since the summer of 1960 I have been writing programsin outline form, using conventions of indentation to indicateflow of control. I have never found it necessary to takeexception to these conventions by using GO statements.'

Schorre was tackling the problem of designing GOTO-lessprograms. As Algol 60, with built-in FOR-WHILE-DO andIF-THEN-ELSE constructs, became widely available,forward looking programmers began to actually encodetheir designs without GOTOs and to ask whether thisshould not be standard practice as a means of reducingprogram complexity. At first this was academic speculation;Landin [66] referred to the 'game sometimes played withAlgol 60 programs - rewriting them so as to avoid usingGOTO statements'. Two things seem to have establishedGOTO elimination as a serious issue:

(i) At the 1965 IFIP Conference [31], and again inthe Communications of the ACM in 1968 [32], E.W.Dijkstra, now regarded as the originator of structured pro-gramming, forcibly argued his famous assertion that thequality of a programmer was inversely proportional to thenumber of GOTO statements in his programs.

(ii) Boehm and Jacopini [14] proved that the controlflow of any program could be replaced by one using onlythe Sequence, IF-THEN-ELSE and WHILE-DO controlstructures. These became known as the D-structures, the'D' standing for Dijkstra.

2.2 Theore tical founda tions

Boehm and Jacopini's proof was inductive, normalisingthree types of 'flow diagrams' which were general enoughto include all possible flow diagrams. These are shown inFig. 3, where the broken circles represent incomplete flowdiagrams. Thus the diagram of Fig. 3a was replaced by aWHILE loop containing a smaller general flow diagram;Fig. 3b was replaced by a WHILE loop containing anIF-THEN-ELSE with two smaller general flow diagrams;and Fig. 3c was first replaced by a diagram of the type in

Fig. 3b and then normalised accordingly. The normalisa-tion procedure involved introducing new Boolean flagvariables together with assignments and tests of thesevariables.

Following Boehm and Jacopini other procedures wereinvented for converting arbitrary flowcharts to 'D-structured'form (i.e. structured in terms of the D-structures). ThusCooper [21] observed that if the labels of an arbitraryAlgol-like program were Lo, Lx , . . . ,Ln and Pif- was thecondition for control to pass directly from Lj to L.- via theoperation sequence Stj; then the program had the followingD-structured equivalent:

BEGINBo :=True; B, :=B2 := :=Bn :=FalseWHILE not Bn DO

BEGINIF Bo and POo THEN

BEGINBo :=False;S00;B0 :=TrueEND

ELSE

IF Bj and Py THENBEGINBj :=False;Sjj ; BEND

ELSE

:=True

Fig. 3 Boehm and Jacopini's 'general flow diagrams'

56

IFB n _! andP n _ l n THENBEGINBn_! :=False;Sn_l n;Bn:=TrueEND

ENDEND.

Cooper also pointed out that, for the purpose of analysis,the resulting program was useless; it preserved the logicalcomplexities of the original flow of control while destroyingits relation to the function of the program. Clearly the D-structured replacement is also much longer and lessefficient in general. Since then, various methods have beendeveloped (see References 26-29, 79, 81, 87, 97, 102 andnotably Reference 4) which claim to preserve more of theoriginal program 'topology' or efficiency, but no signifi-cant improvements have been made and in fact there laterproved to be fundamental limitations to such attempts [30,70].

Another very important theoretical result was that therewere programs whose flowcharts could only be replaced byD-structured flowcharts if some equivalent to Boehm andJacopini's Boolean flags was introduced. Proofs of this,first given independently by Bruno and Steiglitz [18] andAshcroft and Mann [4], essentially concern the normalisa-tion of the two-exit-loop flowchart (see Fig. 4). LikeBoehm and Jacopini's theorem this result may be seen asinitiating the study of the power of various primitivecontrol structures. This has proved to be a central theme ofmathematical structured programming and will be de-scribed in Section 3.1.

2.3 The GO TO con troversy

Dijkstra's arguments and the theoretical considerations out-

Software & Microsystems, Vol. 3, No. 3, June 1984

lined in the preceding Section split the computing com-munity in half. Those who supported the new D-structuredor 'GOTO-less' programming, proclaiming uncritically thetheoretical elegance of Boehm and Jacopini's theorem, wereopposed by those who had always relied on the GOTO towrite compact, efficient 'clever' programs. Disallowing theprogrammer the use of the GOTO meant forbidding himthe creation of new primitive control structures; and it wasas an attack on creativity that half the programming pro-fession viewed structured programming.

Fig. 4 Two-ex it-loop flowchart

In the early 1970s structured programming became abuzz-word, and controversy over the GOTO approached itsheight. The 25th ACM National Conference included asession on the subject where 'those who came . . . in favourof the GOTO statement left in favour of it, andthose who came opposing it left opposing it' [109] (forexample, compare References 54 and 107). Datamationdevoted almost a whole issue to this 'programming revo-lution' [8, 20, 33, 72, 76] as did Computer [10, 17, 28, 45,52, 73, 75, 84] and a number of books were written [74,98, 109]. Knuth [64], in one of the most readable andobjective papers of the period, acted as arbitrator in thedispute.

The GOTO controversy has never been resolved, but,after the mid-1970s, its impetus slackened. This was partlydue to the emergence of the other methodologies men-tioned in Section 1.1. Besides, with the advent of fourth-generation computers, the enormous increase in pro-gramming power and storage made the complicated tricksof writing fast, compact code obsolete. D-structured pro-gramming was, to a large extent, forgotten in commercialsoftware production while remaining a subject of academicresearch.


3 The evolution of structured programming

3.1 Beyond D-structu redness

Even the protaganists of D-structured programming wereconvinced by the GOTO controversy that there was justifi-cation for examining the power of more general controlstructures. The D-structures were known to be theoreticallysufficient but acknowledged to be inadequate from apractical viewpoint. This recognition was a step towards amore general theory of structured programming. A concreteexample was provided by Wulf [107, 108], who reportedon the development of the language Bliss at Carnegie-MellonUniversity. Wulf suggested that there were a few cases inwhich the GOTO was needed for practical reasons, but thatthese could be identified and accommodated by supple-menting the D-structures with a few new control structures.Specifically, Bliss has no GOTO. Instead an 'escape'command is available which allows conditional exit fromany (nested) control structure in which it is placed. Thereserved 'escape types' are self-explanatory:

Exit, Exitblock, Exitcase, Exitcompound, Exit condi-tional, Exitloop, Exitselect and Return

It is not easy to think of an interpretation of our restric-tion to a 'fixed limited class of control structures' which isnot violated by the ability to exit from nested controlstructures. Nevertheless, Bliss was a significant workingstructured programming experiment from which Wulfdrew two important conclusions: that programming withoutthe GOTO actually led to increased programming product-ivity, and that code optimisation could be done moreefficiently in a GOTO-less language. Another languagewhich experimented with exit statements in this way wasBCPL[41].

In Reference 80, Peterson, Kasami and Tokura treatedthe power of multilevel loop exits more formally, showingthat they were actually not as powerful as the GOTOstatement. Their work, and that of Knuth and Floyd [62],Cooper [22] and others, examined ways in which programscould be altered, for example by duplicating some of theprimitive functions or some parts of the flowchart or bycombining tests or replacing them by their negation.Instances were found of programs which could not bechanged into D-structured or 'well formed' or 'multi-levelexit' programs using only these alterations.

These results are of limited importance: they reflect thearbitrariness of the permitted alterations, which maythemselves depend on a particular interpretation of controlstructures. An exception, mentioned in Section 2.2, wasBruno and Steiglitz's demonstration that to achieve D-structuredness it was sometimes necessary to alter aprogram even to the extent of adding new tests and primitivefunctions, namely those connected with new flag variables.This is a fundamental alteration because it cannot be inter-preted as being purely structural. It signals the point atwhich we have to step beyond the limits of our structuralconsiderations.

Kosaraju [65] (who, like Ashcroft and Manna, provedBruno and Steiglitz's result independently) defined twoprograms or their flowcharts to be 'strongly equivalent' or'strongly reducible to each other' if:

57

(i) they had the same tests and primitive functions

(ii) for every input the two programs performed thesame sequence of tests and operations in precisely the sameorder.

If instead of (ii) we have:

(ii)' for every input the two programs produce thesame output

then the programs are said to be 'weakly equivalent' or'weakly reducible to each other'. Weak reducibility is thus,in a fundamental sense, the weakest way in which two pro-grams can be structurally equivalent. Fig. 5 shows twoflowcharts which are weakly equivalent to each other butnot strongly equivalent.

Fig. 5 Two weakly equivalent flowcharts that are not stronglyequivalent

Kosaraju also gave a more precise meaning to thequestion of the 'power' of flowcharts: a class of flowchartswas weakly reducible to another class if every flowchart inthe first class was weakly reducible to one in the secondclass. If the converse was not true, then the second classcould be seen as the more powerful. Thus the flowchart ofFig. 2 is weakly reducible (in fact strongly reducible) tothat in Fig. 4, just by putting A =B = F31 and a = |3 = x inFig. 4. But, as we have seen, the converse is not true.Kosaraju proved a good many other results of a similarnature in his paper.

The notion of reducibility was extended by Ledgardand Marcotty [69]. They defined five different types ofreducibility and used them to give a unified survey of theresults we have described. They concluded that:

'from the programmer's viewpoint, theoretical resultsbased on the conversion of one program to another underrestrictive conditions may not be of practical significance'.

Indeed, what had failed to emerge from the work ofKosaraju and his predecessors was any set of primitiveflowcharts or control structures which could fulfill Wulf'shope of replacing the GOTO more effectively than theD-structures.

In any case there was an obstruction to further progressin this direction: the lack of clear and precise definitions of

58

flowcharts or control structures and formal methods forcombining them as described in Section 1.2. No twoauthors agreed; all made their own interpretation and fewdevoted more than a cursory paragraph to it. Bruno andSteiglitz, Ashcroft and Manna, Knuth and Floyd andKosaraju all proved their results by means of counter-examples, often resorting to actual algorithmic interpre-tations of flowcharts because their structural machinerywas not powerful enough to support general arguments.

3.2 Flo w graph reducibility

Apart from his formulation of the power of controlstructures in terms of weak reducibility, a significant contri-bution of Kosaraju's paper [65] was a necessary andsufficient structural condition for weak reducibility to D-structured flowcharts, or 'D-charts' as he called them. Thisgeneralised the counterexample of Fig. 4 by allowing theloop with two exits to be any cyclic path in a programflowchart (i.e. possibly containing many program tests andoperations — see Fig. 6). Thus the nonexistence of a cyclic

Fig. 6 Flowchart of the 'modified Burns algorithm' [82]

two-exit cyclic path

+ and - signs are omitted for clarity


path having two distinct paths to the stop node (or itsequivalent) was proved necessary and sufficient for aprogram's flowchart to be weakly reducible to a D-chart.

The importance of Kosaraju's theorem is twofold. In thefirst place it can actually be used in program design - aprogrammer knows that, even if he uses the GOTO, so longas he avoids two-exit cyclic paths his program may beconverted to a D-structured program merely by re-arrangingand duplicating his code. This idea was extended further byMcCabe [71] and others, as is described in Section 4.2.Secondly, the theorem, as Kosaraju himself pointed out,provided a point of contact with the theory of flow graphreducibility which was being developed in the field of codeoptimisation.

From the first, flow graphs were much more rigorouslytreated than the flowcharts used in structured programming.They are directed graphs (collections of 'nodes' joined bydirected lines or 'arcs' [chapter 16 of Reference 46])having a 'start node' from which any other node may bereached via a directed path. A node may have arbitraryoutdegree (i.e. the number of arcs leaving it). There areseveral definitions of flow graph reducibility,f for example,in terms of 'intervals', flow graph reductions, backward andforward branch partitions; however, by virtue of themathematical nature of flow graph theory these are all seento be equivalent to each other [49]. The definition which isof interest here was provided by Hecht and Ullman [48].They proved that a necessary and sufficient condition forreducibility was that no cyclic path had two paths to itfrom the start node. This is the dual of Kosaraju's theorem(illustrated in Fig. 6).

The connection between D-structuredness and flow graphreducibility is very important. The latter has never beenanything but a useful tool for loop optimisation (seeReference 2 for an excellent treatment of this). Nocontroversies cloud its past; there is no ambiguity as to itsmeaning. As a result, far better analytic techniques areavailable for flow graphs than for flowcharts. Some of thebiggest names in algorithmic computer science have contri-buted, among them Hopcroft, Tarjan and Shamir (of thefamous RSA codes). It is purely thanks to flow graph theorythat we know that we can test for D-structuredness innearly linear time [95]. Indeed, any results concerningflow graph analysis (for example References 6, 43, 51 and89) may have application in structured programming.

The match between the two disciplines is, of course, notexact. Empirical evidence [3, 63] suggests that almost allflow graphs are reducible, whereas the same is certainly nottrue of D-structuredness for flowcharts. There may be nonatural counterpart in flow graph analysis for generalisationsof structured programming, although rigorous techniquesare emerging to deal with these in any case, as we shall seein the following Section.

4 Modern structured programming

4.1 Background

We saw, in Section 3.1, that, by the mid-1970s, structuredprogramming was ready to enter a new phase of its develop-ment. The GOTO controversy had run out of steam; the

fit is unfortunate that 'reducibility' here has nothing whatever todo with the reducibility discussed by Kosaraju and Lcdgard andMarcotty. This multiple use of terms has rather plagued structuredprogramming. Williams [104] has tackled the problem.

power of various control structures had been studied asdeeply as inadequate models would permit. There wereseveral options open to researchers in the field. In thisSection we discuss three which have been followed sincethen, more or less continuously until the present day. Apartfrom flow graph analysis, these represent, to the best know-ledge of the authors, the only major research in structuredprogramming to have spanned this period. The threeapproaches differ widely enough to cover most of the issuesraised in preceding Sections.

4.2 /dentifying the causes of unstructuredness

The 1976 paper of McCabe [71] is famous chiefly for itspresentation of the well known 'cyclomatic number'complexity measure (which actually does no more thanequate the complexity of a program with the number ofprogram tests). However, the paper also discusses D-structuredness in terms of certain forbidden 'subgraphs' offlowcharts. Unfortunately, the discussion, although motiva-ted by elementary directed graph theory, is quite vague.One tangible conclusion is that D-structuredness dependsupon there being no branches into or out of Selection andIteration constructs. This was illustrated by McCabe asshown in Fig. 7 but was not proved. Indeed his results weretoo informally stated to admit any kind of proof.

Independently of McCabe, Williams [101] proposed aset of five 'basic unstructured forms' which are effectivelythe same as the constructs of Fig. 7. He goes a step furtherthan McCabe in asserting that any method for 'structuring'these would transform any unstructured program to a D-structured one. However, his statement and proof areunacceptably sketchy. Subsequently he presented, withOssher [102], a method for restructuring the unstructuredforms. Again the methods are informally presented andseem to pay scant attention to efficiency. In particular,automatic use of 'node-splitting' (i.e. replacing blocks ofcode with several entry points by several copies of theblock each with a single entry) can lean to excessive dupli-cation of code; the fact that it is 'necessary to identify theheads, ranges, exits and entries of each loop in the flowdiagram' suggests an insuperable obstacle since the numberof loops in a flowchart may be exponential in the numberof test nodes.

More recently, Oulsnam [79] has produced his own setof six unstructured forms, distinguishing between thebranches into and out of forward and backward loop paths.He concludes, however, that McCabe's set was sufficient forrestructuring. His method for doing this is described moreprecisely than Williams and Ossher's and takes moreaccount of efficiency. Thus branching into a Selection hastwo restructurings: one duplicating code, and one intro-ducing a new test and test variable (see Fig. 8). Neverthe-less, the method still relies on identifying loops (Oulsnamrecognises that this is a problem).

It remains to be seen in what circumstances the transfor-.mation of unstructured forms offers an effective approachto structured programming problems. Perhaps McCabe hitupon its crucial feature when he (rather presumptuously)compared the characterisation of D-structuredness byforbidden unstructured forms with Kuratowski's characteri-sation of planar graphs in terms of forbidden minors(p. 108 of Reference 46). This gives great insight into thenature of planarity but has no known efficient implement-ation. Similarly, the visualisation of D-structuredness as


Fig. 7 McCabe's four forbidden subgraphs

a Branch out of a loopb Branch into a loopc Branch out of a selectiond Branch into a selection

60

avoiding branches into and out of Selections and Iterationsmay be a helpful programming aid but does not yet amountto a useful analytic tool.

4.3 The algebraic theory

The search for sets of control structures that are morepowerful than the D-structures is a central issue in structuredprogramming. However, as we saw in Section 3, it was nevertreated with any real formality. In Reference 38 theeminent American mathematician Calvin C. Elgot (seeReference 90) provided both the necessary formality and a

Fig. 8 Oulsnam's two restructurings of the basic unstructuredform 'branch into a selection'

significantly greater degree of generality. Elgot's approach,further developed in References 12, 39, 91 and 96, was tofirst formalise and generalise the concept of flowcharts andto treat these as purely algebraic objects upon whichcertain well defined mathematical operations (correspond-ing to analogous programming constructs) might be per-formed. This represents a formalisation of the concept ofprimitive control structures as a collection of combiningoperations rather than as a collection of flowcharts.

Thus, rather than flowcharts we have 'flowchart schemes'which roughly speaking consist of an underlying directedgraph in which there are an arbitrary finite number ofindexed 'begin' nodes and 'exit' nodes (see Fig. 9). Allnodes of the graph are labelled according to their respectiveoutdegrees: nodes of outdegree zero are precisely the exitnodes; nodes of outdegree m (greater than zero) are labelledfrom some predefined set Tm (where F j , F2, F 3 , . . . aremutually disjoint sets whose elements are interpreted asoperations and multi-exit tests). The m arcs leaving a nodeof Tm in the scheme are indexed from {1, . . , m } . In thecase where the maximum outdegree is equal to 2, only thesets F! (the 'operation' nodes) and F2 '(the 'predicative'nodes) are relevant, and the indexing {1,2} of the two arcsout of each predicative node correspond to a true or falseoutcome of the predicate. 'Scalar' flowchart schemes arethose having just one begin node; 'biscalar' schemes arescalar schemes having just one exit node. 'Accessible'flowchart schemes are those schemes in which every nodelies on a path from some begin node. Thus the accessiblebiscalar schemes over Ft and F2 may be thought of as theusual interpretation of flowcharts.

It is the arbitrariness in numbers of begin and exit nodes(particularly the latter) which is crucial in formulating thealgebraic theory of these schemes. Indeed, the buildingblocks of the theory are families of very simple schemes,namely the 'atomic' and 'trivial' schemes: if yn is in FM,then the 'atomic scheme yn' (see Fig. 10a) is the scheme


consisting of «+l nodes and n arcs — one begin node labelledyn with n arcs to n exit nodes, where the /th arc goes toexit / (/=1 , . . . , n). The 'trivial scheme / ' where / and pare integers and p> /> 1 (see Fig. 10b), is the schemeconsisting of just p exit nodes, one of which (the /th) is theunique begin node. This means that not only functionalprimitives in Vi, but also tests and CASE statements are tobe combined by the operations.

Fig. 9 Example of a scheme: n • [ 1 , ® CJ]

Given schemes F^ and F2, precise algebraic operationsare defined in certain circumstances on these schemes; theeffect of these operations on the underlying digraphs maybe readily described informally. For example:

(i) 'Separated pairing' of Fx and F2 (written Fx © F2)is obtained by regarding the two schemes Fx and F2 asone and taking the sequence of begins of F, followed bythe sequence of begins of F2.

(ii) 'Composition' of Fx and F2 (written Fy • F2) isdefined when the number of exits of Fx is the same as thenumber of begins of F2. Then the /th exit of Fx is identifiedwith the /th begin of F2.

(iii) 'Scalar conditional iteration' of F (written F+) isdefined, when F is scalar and has p>\ exits, as the scalarscheme with p- 1 exits formed from F by deleting the pthexit and redirecting the arcs of F which go to the pth exitto the begin of F. Thus scalar conditional iteration of F is(as we shall see) a powerful generalisation of WHILE-DO.

The key theme in References 12, 38, 39, 91 and 96 is thatvarious (algebraically defined) 'classes' of flowchartschemes may be studied; specifically, the least class ofschemes containing certain 'generators' (which will be somesubset of the set of trivial schemes) and which is closedunder certain operations (such as those mentioned above).Restricting the discussion henceforth to scalar schemes, wehave, for instance:

(i) the 'CACI-schemes', whose set of generators is theset of all trivial and atomic schemes and whose operationsare composition and scalar conditional iteration

(ii) the ' Q -schemes', whose set of generators is thetrivial scheme 11 and the set Fx and whose operations arecomposition, scalar conditional iteration and two furtheroperations called 'separated atomic substitution' and'merging'

(iii) the ' $, -schemes', whose generators are 11 and allatomic schemes and whose operations are composition,scalar conditional iteration, merging and another operationcalled 'separated substitution'.

Theoretically, the combinations are unlimited, and we notealso that the D-structured flowcharts are, in our opinion,given their first acceptably rigorous characterisation here, asthe class of D-schemes whose generators are the set 1 j andthe set Vx and whose operations are composition, alterna-tion and the WHILE-DO.

In Reference 38, Elgot examined the relationshipbetween various classes. For example, he showed that everyflowchart scheme is strongly equivalent to a CACI-scheme(a result which, bearing in mind the 'inadequacy ' of the D-schemes, shows the power of the scalar conditional iterationoperation). The accessible CACI-schemes are precisely theQ -schemes s (this may be deduced from theorem 4.3 ofReference 38 and proposition 1.1 of Reference 12). The${. -schemes are studied in detail in Reference 39, themain result being that, if we restrict our attention to theunderlying digraphs, then the scalar ${. -schemes corres-pond exactly to the reducible flowgraphs described in thepreceding Section. The discussions in References 12 and91 concentrate on graph-theoretic characterisations ofvarious classes of schemes. Certain properties of paths inthe underlying digraph (for example the 'bipath exit'property and the 'bipath re-entry' property) appear to besufficient to characterise many of these classes. Thus, forexample, the Q -schemes are precisely those schemeshaving both 'bipath properties' (theorem 3.2.6 of Reference12) and the ' C -schemes' are precisely those schemes whichare acyclic and have the 'bipath exit property'.

In summary, the algebraic approach is highly commend-able in so far as it provides the first rigorous attempt toformalise the notion of program flowchart and structured-ness and leads to an unambiguous foundation for variousgeneralised notions of structured programming. From a

Fig. 10 Two of Elgot's generating schemesn

a The atomic scheme 1 -+ 21

b The trivial scheme 2,


purely mathematical viewpoint the theory is elegant,self-contained and raises many interesting questions whichare worthy of attention. Software practitioners will,however, be disappointed if they expect to find seriousapplications in this approach; a substantial and importantpart of the theory concerns a class of schemes which donot correspond at all to algorithmic programs, namely themulti-entry, multi-exit schemes, of which the atomic chartsare one example. Also, apart from the graph-theoreticconsiderations (of theoretical rather than practical interest),no attempt is made to provide systematic methods fordetermining whether an arbitrary flowchart is in any one ofthe particular classes, nor to transform flowcharts which arein one class to 'equivalent' flowcharts in a different class.Perhaps the main reason for this is that the generalisednotion of flowchart scheme does not allow for the identifi-cation of 'subcharts' which would correspond to substitut-able procedures.

4.4 The graph-theoretic approach

A theory of flowgraphs is developed in References 23, 24,42, 44 and 100 which is similar to the algebraic theorydescribed in the preceding Section in two important ways.The need is recognised first for a mathematical formalisa-tion of flowcharts as an unambiguous structural programmodel and secondly to define generalised notions ofstructuredness based on families of primitive controlstructures. This is where the similarities end: here,'flowgraphs' have a unique 'start' and 'stop' node and arealways bi-accessible (as defined in the preceding Section).An example is given in Fig. 11 with the start and stop node

encircled. This straightforward interpretation of controlstructures is representative of the theory itself, which isvery much geared to program analysis rather than toabstract questions of structured programming.

Fig. 11 Flowgraph version of Fig. 6

62

Fig. 12 Some small irreducibles

Generality in the concept of structuredness is achievednot by regarding control structures as operations actingarbitrarily to combine other control structures, but ratherby allowing any set of flowgraphs to be primitive controlstructures (called 'basic flowgraphs') and defining onesimple nesting operation called 'composition' to take careof combining them. Then \S-structuredness' is defined withrespect to an arbitrary family S of basic flowgraphs.

Suppose a flowgraph F contains a subgraph (a subset ofthe nodes and arcs of F) which is also a flowgraph. Supposealso that the only arcs going from the subgraph to the restof F come from its stop node. Then the subgraph is called a'subflowgraph'. If it has only one arc leading into it fromthe rest of F (going to its start node), then we can assumethat it was nested inside F by composition. The notion of'subflowgraph' is crucial to flowgraph theory. Theflowgraphs with no subflowgraphs are called the 'irredu-cibles'. In Fig. 12 we give examples of irreducibleflowgraphs for each number of tests up to four. The readermay like to try to think of algorithmic interpretations ofthese control structures.

The irreducibles cannot be produced by compositioneven if we allow identical nested subflowgraphs to bemerged as a single subflowgraph with several arcs leadinginto it. Because of this they are ideal candidates to be basicflowgraphs (i.e. the primitive control structures). They playa central role in the theory.

In particular, it is seen (in Reference 100; for example)that restricting our arbitrary sets of basic flowgraphs toconsist only of irreducibles causes no practical loss ofgenerality. Moreover, in this case it can be shown that theFinite Church Rosser property [50] applies to 'decomposi-tion' algorithms (performing the reverse of composition).This allows an arbitrary flowgraph to be representedefficiently and unambiguously as a hierarchy of irreducibles.In Fig. 13 we show how the flowgraph of Fig. 11 has a


Table 1: Numbers of CGK-irreducibles on up to six test nodes

Number of test nodes 0 1 2 3 4 5 6

Number ofCGK-irreducibles withstart node notdistinguished

Number ofCGK-irreducibles withstart nodedistinguished

16

54

152

735

2151

12690

subflowgraph (Fig. 13a) which is itself made up of aREPEAT-UNTIL (the 1 -test irreducible of Fig. 12b) and asingle primitive function node (the O-test irreducible ofFig. 13a). The removal of these (Fig. 13b) leaves the four-test irreducible of Fig. 12e (the reader may like to checkthis!); therefore this gives the complete hierarchy ofirreducibles for the flowgraph.

Since any flowgraph may be described in terms of acollection of irreducibles, structural analysis of flowgraphsmay in many instances be replaced by a study of irreducibles.For example, an algorithm for four-colouring irreducibleshas been shown to give a four-colouring of arbitraryflowgraphs [99]. If a flowgraph property is well under-stood for irreducibles up to a certain size or of a certaintype, then, in an area of application where this property isimportant, we may require programmers to restrict them-selves not to D-structuredness, but only to structuredness interms of these irreducibles. Thus all irreducibles up to sixtests have been catalogued so that analysis of a flowgraphstructured using irreducibles with no more than six testsis scarcely any more difficult than analysis of D-structuredflowgraphs.

Fig. 13 Decomposition of Fig. 11 into irreducibles

The hierarchy of irreducibles associated with a flowgraphalso suggests a number of easily evaluated software metricswhich are far more significant indicators of structuralcomplexity than McCabe's trivial measure. Specifically,depth of the irreducible hierarchy, the size of its largestirreducible and the variety of its irreducibles can all besystematically calculated and are invariant up to Kosaraju'sstrong equivalence.

This graph-theoretic approach to structured programminghas its origins in two papers presented to British Combina-torial Society Conferences [34, 35] by Dowker and Kaposi.These modelled programs as directed trivalent graphs (i.e.with all nodes having a total outdegree and indegree of

three) and concentrated on the generation of all trivalentgraphs on 2« nodes (the number of nodes has to be even)from those on 2(«-l) nodes. The idea was to see whatstructural properties were connected to certain types ofgeneration. In fact, the model proved to be too abstract tobe very revealing about program structure, although,interestingly enough, one class of trivalent graphs corres-ponded closely to McCabe's unstructured forms.

Flowgraphs, as presented in References 23, 24 and 44,were a modification of the trivalent graph model to repre-sent only program tests, so that every node now hadoutdegree two. This is now called the CGK-graph to distin-guish it from the more general flowgraphs illustrated inFig. 11. Owing to its conciseness, it is the most convenientfor analysis; in fact, remarkably, it is shown in Reference42 that the study of irreducible flowgraphs may largely bereplaced by the study of CGK-graphs. As an example, theflowgraphs of Fig. 12c and Fig. 13b become, respectively,the CGK-graphs of Fig. 14a and b. It is now easy to checkthat the two are in fact the same directed graph.

Fig. 14 CGK-irreducibles corresponding to Figs. 12e and 136

One conjecture that was made concerning CGK-graphshas proved to be of outstanding importance. In the spirit ofthe work of Dowker and Kaposi, it was asserted that allCGK-irreducibles with n tests could be generated by thosewith n-1 tests by adding a new test node with a new arcfrom it to an existing node (see Fig. 15). This may be seenas adding a new 'unstructured' GOTO. A proof of thisso-called 'generation theorem' has recently been given [99].Using it, all CGK-irreducibles on up to six tests have beengenerated; their numbers are given in Table 1. The theoremis a powerful tool for deriving results concerning the CGK-irreducibles and hence, as indicated above, of irreducibles ingeneral. Most significantly, a direct consequence of it is ageneralisation (discovered by Fenton [42]) of Kosaraju'stheorem (Section 3.2) from irreducibles with one test (theD-structures) to irreducibles with any finite number of tests.

Fig. 15 Generating the CGK-irreducibles corresponding to theirreducibles in Fig. 12

5 The future of structured programming

Throughout this paper we have never been far from thenotion of a program control structure. However these aredefined it is clear that they are rather closely linked to


traditional, Von-Neumann computer architectures and thesequential languages they support. This often prompts thequestion: 'is structured programming about to be madeobsolete by concurrent processing, dataflow architecturesand functional and logic-based languages?' The answer tothis is obviously 'yes' (and applies equally to manynonstructural computing techniques), but we would addcertain qualifications:

(i) So much existing software is written in languagessuch as Fortran, Cobol and Basic that the transition toconcurrent processing is bound to lag far behind actualadvances in concurrent hardware and programming tech-niques. The transition will probably involve a good deal ofadapting of sequential code to run concurrently, andstructural analysis is likely to be very necessary in thisprocess.

(ii) Although concurrent languages such as Occam andAda are highly structured, real-time applications may wellencourage the same tricks for speeding up concurrentprograms as are used for sequential programs. Structuralproperties of concurrent 'flowcharts' will still be important,and their analysis will certainly draw on re-interpretationsof existing techniques.

(iii) The obsession with developing ever smallermicrocomputers for an ever wider range of users seems setto perpetuate correspondingly 'small' languages which areeasy for unsophisticated users to learn. At the moment thismeans Basic as used by millions of self-taught whizz-kidswhose main preoccupation is writing clever, fast compactprograms. In this sense we are still in the mid-1960s.

6 Bibliography and References

1 AHO, A.V., and ULLMAN, J.D.: 'Node listings for reducibleflow graphs',/. Comput. & Syst. Sci., 1976, 13, pp. 286-299

2 AHO, A.V., and ULLMAN, J.D.: 'Principles of compilerdesign' (Addison-Wesley, 1977), chaps. 12, 13

3 ALLEN, F.E.: 'Control flow analysis', SIGPLANNot., 1970,5, (7), pp. 1-19

4 ASHCROFT, E., and MANNA, Z.: 'The translation of'GOTO' program to 'WHILE' programs', in FREIMAN, C.V.(Ed.): Information Processing 71. Vol. 1 (North Holland,1972), pp. 250-255

5 ARON, J.D.: 'The supcrprogrammer project'. SoftwareEngineering Techniques, NATO Scientific Affairs Division,Brussels 39, Belgium, pp. 50-52

6 BAKER, B.S.: 'An algorithm for structuring flowgraphs',/ . ACM, 1977, 24, pp. 98-120

7 BAKER, F.T.: 'Chief programmer team management ofproduction programming', IBM Syst. / . , 1979, 1, pp. 56-73

8 BAKER, F.T., and MILLS, H.D.: 'Chief programming teams',Datamation, 1973, 19, (12), pp. 58-61

9 BECERILL, J.L., BONDIA, J., CASAJUANA, R., andVALER, F.: 'Grammcr characterization of flowgraphs', IBMJ. Res. & Dev., 1980, 24, pp. 756-763

10 BIGELOW, R.: 'Structured code via a stack machine',Computer, 1975, 8, (6), p. 67

11 BLOOM, A.M.: 'The 'ELSE' must go, too', Datamation, 1975,21,(5), pp. 123-128

12 BLOOM, S.L., and TINDELL, R.: 'Algebraic and graphtheoretic characterisations of structured flowchart schemes',Theor. Comput. Sci., 1979, 9, pp. 265-286

13 BOEHM, C: 'On a family of Turing machines and the relatedprogramming language', ICC Bull., 1964, pp. 187-194

14 BOEHM, C, and JACOPINI, G.: 'Flow diagrams, Turingmachines and languages with only two formation rules',Commun. ACM, 1966, 9, pp. 366-371

15 BOCHMANN, G.V.: 'Multiple exits from a loop without theGOTO\ibid., 1973, 16, pp. 443-444

64

16 BRAMSON, B.D., and GOODENOUGH, S.J.: 'Graph theoryleads to program visibility'. Report 80004, Royal Signals &Radar Establishment, Malvern, England

17 BROWN, J.R.: 'Structured programming: agony and/orecstasy', Computer, 1975, 8, (6), pp. 56-57

18 BRUNO, J., and STEIGLITZ, K.: 'The expression of algor-ithms by charts',/. A CM, 1972, 19, pp. 517-525

19 CHENIAVSKY, J.C., HENDERSON, P.B., and KEOHANE,J.: 'On the equivalence of URE flow graphs and reducibleflow graphs'. Proceedings of CISS, John Hopkins University,Baltimore, MD, USA, 1976, pp. 423429

20 CLARKE, R.L.: 'A linguistic contribution to GOTO-lessprogramming', Datamation, 1973, 19, (12), pp. 62-68

21 COOPER, D.C.: 'Boehm and Jacopini's reduction of flowcharts', Commun. ACM, 1967, 10 pp. 463, 473

22 COOPER, D.C.: 'Some transformations and standard formsof graphs, with applications to computer programs', inMITCHIE, D. (Ed.): 'Machine intelligence 2' (Oliver andBoyd, Edinburgh, 1967)

23 COWELL, D.F., GILLIES, D.F., and KAPOSI, A.A.:'Introduction to flowgraph schemas', Proceedings of CISS,John Hopkins University, Baltimore, MD, USA, 1978,pp.437440

24 COWELL, D.F., GILLIES, D.F., and KAPOSI, A.A.: 'Synthe-sis and structural analysis of abstract programming', Comput./ . , 1980, 23, pp. 243-247

25 DAHL, O.J., DIJKSTRA, E.W., and HOARE, C.A.R.:'Structured programming' (Academic Press, 1972)

26 de BALBINE, G.: 'Better manpower utilisation using auto-matic restructuring'. AFIPS Conference Proceedings, Vol. 44,1975, pp. 319-327

27 de BALBINE, G.: 'Design criteria for the "structuring engine".Proceedings of Second USA-Japan Computing Conference,Tokyo, Japan, Aug. 1975 (AFIPS, 1975), pp. 422426

28 de BALBINE, G.: 'The structuring engine: a transitional tool',Computer, 1975, 8, (6), pp. 64-65

29 de BALBINE, G.: 'Procedure extraction for automatic re-structuring'. 12th IEEE Computer Society InternationalConference on Computers: The Next Five Years, SanFrancisco, CA, USA, Feb. 1976, pp. 225-228

30 DeMILLO, R.A., EISENSTAT, S.C., and LIPTON, R.J.:'Space-time tradeoffs in structured programming: an improvedcombinatorial embedding theorem', / . ACM, 1980, '27,pp. 123-127

31 DIJKSTRA, E.W.: 'Programming considered as a humanactivity'. Proceedings of IFIP Congress 65 (Spartan Books,Washington, 1965)

32 DIJKSTRA, E.W.: 'GOTO statements considered harmful',Commun. ACM, 1968, 11, pp. 147-148,538,541

33 DONALDSON, J.R.: 'Structured programming', Datamation,1973, 19, (12), pp. 52-54

34 DOWKER, C.J., and KAPOSI, A.A.: 'Flowcharts and graphs'.Paper presented at Seventh British Combinatorics Conference,Royal Holloway College, London University, London,England, 1977

35 DOWKER, C.J., and KAPOSI, A.A.: 'The geometry offlowcharts'. Paper presented at Seventh British CombinatoricsConference, Cambridge University, Cambridge, England, 1979

36 DOWSING, R.D.: 'An introduction to structured program-ming', Microprocessors, 1978, 2, pp. 88-89

37 DOWSING, R.D.: 'Example of design using structured pro-gramming', ibid., 1978, 2, pp. 155-159

38 ELGOT, C.C.: 'Structured programming with and withoutGOTO statements', IEEE Trans., 1976, SE-2, pp. 41-53(Erratum and Corrigendum SE-2, 1976, p. 232)

39 ELGOT, C.C., and SHEPHERDSON, J.C.: 'A semanticallymeaningful characterisation of reducible flowchart schemes',Theor. Comput. Sci., 1979, 8, pp. 325-357

40 ELSHOFF, J.L., and MARCOTTY, M.: 'Improving computerprogram readability to aid modification', Commun. ACM,1982, 25, pp. 512-521

41 EVANS, R.V.: 'Multiple exits from a loop using neitherGOTO nor labels', ibid., 1974, 17, p. 650

42 FENTON, N.E., WHITTY, R.W., and KAPOSI, A.A.: 'Ageneralised mathematical theory of structured programming',Theor. Comput. Sci., (under consideration)

43 FONG, A.C., and ULLMAN, J.D.: 'Finding the depth of aflow graph'. Eight Annual ACM Symposium on Theory ofComputation, New York, USA, 1976, pp. 121-125


44 GILLIES, D.F., COWELL, D.F., and KAPOSI, A.A.: 'Atheory for flowchart schemas'. Proceedings of CISS, JohnHopkins University, Baltimore, MD, USA, 1978, pp. 441446

45 GORDON, E.K.: 'Experience and accomplishments withstructured programming', Computer, 1975, 8, (6), pp. 50-53

46 HARARY, F.: 'Graph theory' (Addison Wesley, 1969)47 HENDERSON, P., and SNOWDON, R.: 'An experiment in

structured programming', BIT, 1972, 12 pp. 38-5348 HECHT, M.S., and ULLMAN, J.D.: 'Flow graph reducibility',

SIAMJ. Comput, 1972, 1, pp. 188-20249 HECHT, M.S., and ULLMAN, J.D.: 'Characterisations of

reducible flowgraphs',/. ACM, 1974, 21, pp. 367-37550 HECHT, M.S.: 'Flow analysis of computer programs'(North

Holland, 1977)51 HIRATA, T., MARUOKA, A., and KIMURA, M.: 'Depth

problems for flow graphs', Syst.-Comput.-Controls, 1979, 10,(6), pp. 78-85

52 HOLMES, C.E.: 'Structured programming at McAuto',Computer, 1975, 8, (6), pp. 41-43

53 HOLTON, J.B., and BRYAN, W.: 'Structured top-downflowcharting', Datamation, 1975, 21, (5), pp. 80-84

54 HOPKINS, M.E.: 'A case for the GOTO'. Proceedings of25th ACM National Conference, Vol. 2, 1972, pp. 787-790

55 HUNT, H.B., III: 'On the complexity of flowchart and loopprogram schemes and programming languages',/. ACM, 1982,29, pp. 228-249

56 JAMES, E.: Structured programming considered dangerous'.IEE Colloquium on Languages for Programming Micropro-cessors, Imperial College, London, England, 1982, pp. 4/1-4/4

57 JENSEN, R.W.: 'Structured programming', Computer,(Tutorial Series 6), 1981, Mar., pp. 31-48

58 KAPOSI, A.A.: 'An engineer's guide to algorithmic structures',CADJ., 1977, 9, pp.. 58-65

59 KAPOSI, A.A., GILLIES, D.F., and COWELL, D.F.: Letterto the Editor, Comput. J., 1979, 22, p. 190 (commenting onReference 102)

60 KASAI, R.: Translatability of flowcharts into WHILE pro-grams',/. Comput. & Syst. Sci., 1974, 9, pp. 177-195

61 KASYANOV, V.N.: 'Some properties of fully reducible flowgraphs',Inf. Process. Lett., 1973,2, pp. 113-117

62 KNUTH, D.E., and FLOYD, R.W.: 'Notes on avoiding GOTOstatements', ibid., 1971, 1, pp. 23-31

63 KNUTH, D.E.: 'An empirical study of FORTRAN programs',Software-Pract. & Exper., 1971, 1, pp. 105-133

64 KNUTH, D.E.: 'Structured programming with GOTO state-ments', ACM Comput. Surv., 1974,6, pp. 261-301

65 KOSARAJU, S.R.: 'Analysis of structured programs', /.Comput. & Sys. Sci, 1974, 9, pp. 232-255

66 LANDIN, P.J.: "The next 700 programming languages',Commun. ACM, 1966, 9, pp. 157-166

67 LEAVENWORTH, B.M.: 'Programming with(out) the GOTO'.Proceedings of 25th ACM National Conference, Vol. 2,1972, pp. 782-786

68 LEDGARD, H.F.: 'The case for structured programming',BIT, 1973, 13, pp. 45-57

69 LEDGARD, H.F., and MARCOTTY, M.: 'A genealogy ofcontrol structures', Commun. ACM, 1975, 18, pp. 629-639

70 LIPTON, R.J., EISENSTAT, S.C., and DeMILLO, R.A.:'Space and time hierarchies for classes of control structuresand data structures',/. ACM, 1976, 23, pp. 720-732

71 McCABE, T.J.: 'A complexity measure', IEEE Trans., 1976,SE-2, pp. 308-320

72 McCRACKEN, D.: 'Revolution in programming: an overview','Datamation, 1973, 19, (12), pp. 50-51

73 McHENRY, R.: 'Measuring programming improvement atIBM-FSD', Computer, 1975, 8, (6), p. 49

74 McGOWAN, C.L., and KELLY, J.R.: 'Top-down structuredprogramming' (Mason and Lipscomb, 1975)

75 McGOWAN, C.L.: 'Structured programming: a review ofsome practical concepts', Computer, 1975, 8, (6), pp. 25-30

76 MILLER, E.F., and LINDAMOOD, G.E.: 'Structured pro-gramming: top-down approach', Datamation, 1973, 19, (12),pp. 55-57

77 MILLS, H.D.: 'The new math of computer programming',Commun. ACM, 1975, 18, pp. 43-48

78 . NAUR, P.: 'GOTO statements and good ALGOL style', BIT,1963, 3, pp. 204-208

79 OULSNAM, G.: 'Unravelling unstructured programs',Computer J., 1982, 25, pp. 379-387

80 PETERSON, W.W., KASAMI, T., and TOKARA, N.: 'On thecapabilities of While, Repeat and Exit statements', Commun.ACM, 1973, 16, pp. 503-512

81 PRATHER, R.E., and SHIRLA, G.C.: 'Decomposition offlowchart schemata', Comput. / . , 1981, 24, pp. 258-262

82 RAMOS, J.M.: 'Some modifications to the Burns algorithm',IEEE Trans., 1983, SMC-U, pp. 108-110

83 RICHARDS, R.K.: 'Electronic digital systems' (John Wiley,1966), p. 40

84 ROMANOS, J.P.: 'An implementation of structured codetechnique on a real-time system', Computer, 1975, 8, (6)

85 ROSS, D.T. and SCHOMAN, K.E.: 'Structured analysis forrequirements definition', IEEE Trans., 1977, SE-3, pp. 6-15

86 SCHORRE, D.V.: 'Improved organisation for procedurallanguages'. Technical Memo TM 3086/002/00, SystemsDevelopment Corporation, Santa Monica, CA, USA, Sept.1966

87 SEGERDAL, A.: 'Restructuring the spaghetti at source',Computing, 1984, 19th Jan., pp. 24-25

88 SHIBEGLY, A., and WHITTY, R.W.: 'Comment on"Decomposition of flowchart schemata" ', Comput. /.,1982, 25, p. 494

89 SHAMIR, A.: 'A linear time algorithm for finding minimumcutsets in reducible graphs', SIAM J. Comput., 1979, 8,pp. 645-655

90 SHEPHERDSON, J.C.: 'In memoriam Calvin C. Elgot",Theor. Comput. Sci., 1981, 16, pp. 1-4

91 SHEPHERDSON, J.C.: 'Graph theoretic characterisation ofG-schemes and TL-schemes', ibid., 1982, 17, pp. 217-228

92 SKORDALAKIS, E., and PAPAKONSTANTINOU, G.: 'Acontrol structure for a variable number of nested loops',Comput. / . , 1982, 25, pp. 48-51

93 SMYTH, M.B.: 'Unique-entry graphs, flowcharts and statediagrams',//!/ & Control, 1974, 25, pp. 20-29

94 STEVENS, W.P., MYERS, G.J., and CONSTANTINE, L.k.:'Structured design', IBM Syst. / . , 1974, 2, pp. 115-139

95 TARJAN, R.E.: 'Testing flow graph reducibility',/. Comput.& Syst. Sci., 1974, 9, pp. 355-365

96 TINDELL, R.: 'Covering digraphs and structured programschemes', in HARARY, F. (Ed.): 'Topics in graph theory',Ann. NYAcad. Sci., 1979, 328, pp. 201-208

97 URSCHLER,G.: 'Automatic structuring of programs',IBMJ. Res. &Dev., 1975, 19, pp. 181-194

98 WEINBERG, G.: 'Structured programming in PL/C (JohnWiley, 1972)

99 WHITTY, R.W.: 'Generation of an important class ofprogram flowgraphs'. Paper presented at Ninth BritishCombinatorics Conference, Southampton University,Southampton, England, 1983

100 WHITTY, R.W., FENTON, N.E., and KAPOSI, A.A.: 'Arigorous approach to structured software design', Software &Microsyst. (under consideration)

101 WILLIAMS, M.H.: 'Generating structured flow diagrams: thenature of unstructuredness', Comput. / . , 1977, 20, pp. 45-50

102 WILLIAMS, M.H. and OSSHER, H.L.: 'Conversion of un-structured flow diagrams to structured form',/We?., 1978, 21,pp. 161-167

103 WILLIAMS, M.H.: 'A comment on the decomposition offlowchart schemata', ibid., 1982, 25, pp. 393-396

104 WILLIAMS, M.H.: 'Flowchart schemata and the problem ofnomenclature', ibid, 1983, 26, pp. 270-276

105 WIRTH, N.: 'Program development by stepwise refinement',Commun. ACM, 1971, 14, pp. 221-227

106 WIRTH, N.: 'On the composition of well-structured programs',ACM Comput. Surv., 1974, 6, pp. 247-260

107 WULF, W.A.: 'A case against the GOTO', Proceedings of25th ACM National Conference, Vol. 2, 1972, pp. 791-797

108 WULF, W.A.: 'Programming without the GOTO', inFREIMAN, C.V. (Ed.): 'Information Processing 71'(North Holland, 1972), pp. 408-413

109 YOURDON, E.: 'Techniques of program structure and design'(Prentice-Hall, 1975), p. 139

110 YOURDON, E.: 'The second structured revolution', SoftwareWorld, 1979, 12, (3), pp. 10-15

111 ZISLIS, P.M.: 'Semantic decomposition of computer pro-grams: an aid to program testing', Acta Inf., 1975, 4,pp. 245-269


Documents

Structured programming: a tutorial guide