Software Engineering For Students: A Programming Approach Part 12 pps

One view of structured programming is that it holds that programs should only be built from three components: sequences normally written in the order in which the statements are to be ex

One view of structured programming is that it holds that programs should only be built from three components: sequences (normally written in the order in which the statements are to be executed), selections (normally written as if-then-else), and repetitions (written as while-do) The gotostatement is, by implication, banned In this chapter we begin by examining the controversy about the goto statement The outcome of the argument is that gotos are an irrelevancy; the argument is about some-thing else, good program structure We go on to explore the significant principles of structured programming

There are some other principles We will explore these using flowcharts, which describe flow of control A flowchart is read from the top downwards or in the direc-tion of the arrows Flowchart decisions (corresponding to ifor whilestatements in code) are drawn as diamonds Flowchart activities are shown as rectangular boxes A flowchart is very similar to a UML activity diagram and conveys the same information

If the three structures of structured programming are diagrammed as flowcharts (Figure 7.1), the following characteristics become clear:

1. they have only one entry and exit

2. none of the constructs consists of more than three boxes

Figure 7.1 The three structures of structured programming

Figure 7.2 A control structure that is not structured

If we visualize any one of the three constructs as they are used, then a third character-istic is evident:

3. the entry is at the start and the exit is at the end

Why is it that these characteristics are important? Why are other constructs that have the same characteristics (Figure 7.2) ruled out? We now go on to look at these questions

SELF-TEST QUESTION

7.1 Write a loop that repeats ten times, first using a whilestatement, then using goto

Fortunately there is a mathematical theorem (thanks to Bohm and Jacopini) guaran-teeing that any program written using goto statements can be transformed into an equivalent program that uses only the structured constructs (sequence, selection and iteration) The converted program will, in general, need additional data items that are used as flags to control the actions of the program Indeed the new program may look rather contrived; nonetheless, it can be done On the face of it, therefore, there is no need for programs with gotos in them

Note, as an interesting side issue, that the theorem does not tell us how to transform the unstructured program; only that it can be done

Experimental evidence

Structured programming is well established and widely regarded as the best approach

to programming You might think, therefore, that there would be clear evidence from real software projects that it is beneficial, but this is not so; there are no convincing results from real projects, largely because a carefully controlled experiment would be difficult and expensive to mount It would be necessary to develop a particular piece of software in two ways: once using structured programming and again using “unstruc-tured” programming All other variables, like the expertise of the programmers, would have to be held constant The two versions of the software could be compared accord-ing to criteria like development time and number of errors Regrettably, there are no results of this type

However, experimenters have carried out small-scale studies comparing how easily people can understand and debug small structured programs compared with unstruc-tured ones In a typical experiment, each of a group of subjects is presented with the

listing of a program that is written in a structured way and asked a series of questions that are designed to assess their comprehension of it The accuracy of the replies and the time taken to reply are both measured These are measures of the ease with which the program could be debugged or changed A second group of subjects are given copies of the same program rewritten in an unstructured way The accuracy and response times of the two groups are compared The results of these experiments gen-erally indicate that structured programs are superior to unstructured ones

The results of empirical studies are reviewed in the literature given at the end of the chapter In a review published in 1984, long after the dust had settled on the structured programming debate, Vessey and Weber concluded that “the evidence supporting [structured programming] is weak” This conclusion largely stems from the difficulty of carrying out experiments that give trustworthy results

Clarity and expressive power

Compare the following two equivalent program fragments:

-if a > 0 goto label endwhile

-As we read down the first program fragment, we are not immediately sure what the roles of the label and gotoare It would take us some time to read and study the pro-gram in order to discover that they are being used to create the repetition of a piece of code This is made immediately obvious by the while statement in the second pro-gram Worse, there is a remaining doubt in the first program that there may be another

gotoaimed at this same label from some other point in the program

The facilities of a programming language should allow people to describe what they want to do in a meaningful way If we examine a typical program written using gotos

we see that the gotos are used for a variety of purposes, for example:

■ to avoid a piece of code (which is to be executed in different circumstances)

■ to perform repetition

■ to exit from the middle of a loop

■ to invoke a shared piece of code

When we see a goto, there are few clues that allow us to decide the purpose for which the goto is being used The alternative is, of course, a unique language con-struct for use in each of these different circumstances These are, respectively:

■ if-then-else

■ while-door repeat-until

■ exit

■ method call

It is as if the gotois too primitive an instruction – like a machine instruction to load

a register – that can be used in a whole variety of circumstances, but does not clearly convey its meaning in any of them

In summary, the gotolacks expressive power and it is therefore difficult to under-stand the logic of a program that is written using a lot of gotos When we look at a piece of coding, words like whileand ifgive us a strong clue as to what is intended;

gotos do not

How many pencils?

Suppose we want to read a program in order to understand it by tracing through it as

if we were a computer executing it Suppose we have available a supply of pencils (or fingers) to help us The pencils will be used as markers, and are to be placed on the pro-gram listing to point to places of interest

If we are following a simple sequence, then we will only need one pencil to keep track of our position If we encounter a method call, we need two pencils, one to leave

at the point of the call (in order to know where to return) and another to proceed into the method

If we encounter a whilestatement or a forloop, then we need an integer, a counter,

to keep count of the number of times we have repeated the loop

To summarize, if the program has been written in a structured way, we need:

■ one pencil to point to the current position

■ one pencil to point to each method call that has been executed but not returned from

■ a counter for every uncompleted loop

This may seem like a lot of equipment, but consider the alternative of a program that contains a lot of gotos As before, we will need to indicate the position of the current statement Next, we need a pencil to point at every gotothat has been executed But now, whereas in the structured program we can remove a pencil whenever we return from a method, finish a loop or complete an ifstatement, we can never dispense with pencils; instead we need ever more The increased number of pencils reflects the increased complexity of the gotoprogram

The real problem becomes evident when we want to refresh our memory about what

happened before we arrived at the current point in the program In the program

with-out gotos we simply look back up the program text In the unstructured program, when we look backwards we are defeated as soon as we reach a label, because we have

no way of knowing how we reached it

Ease of reading (static and dynamic structures)

In the Western world we are used to reading left to right and top to bottom To have to begin by reading forwards and then to have to go backwards in the text is rather unnatural;

it is simpler if we can always continue onwards It is an important feature of a structured pro-gram that it can always be read from top to bottom – provided it has no methods The excep-tion to this rule arises in comprehending a whileloop, during which repeated references back to the terminating condition at the start of the loop are necessary

Programs are essentially dynamic beings that exhibit a flow of control, while the pro-gram listing is a static piece of text To ease understanding, the problem is to bring the two into harmony – to have the static text closely reflect the dynamic execution In a structured program, the flow of control is always down the page, which exactly corre-sponds to the way that text is normally read

Proving programs correct

Formally to prove all programs correct is not a practical proposition with present-day techniques Nonetheless there are some lessons that can be learned from proving

In one technique of program proving, assertions are made at strategic points in the program An assertion is a statement of what things are true at that point in the pro-gram More exactly, an assertion describes the relationships that hold between data items that the program acts upon Assertions at the start and end of a piece of program are called the input and output assertions respectively Proving consists of rigorously demonstrating that if the input assertion is true, then the action of the program will lead to the output assertion being true

A structured program consists solely of components that have a single entry and a single exit point This considerably aids the process of reasoning about the effect of the program In contrast, it is usually impossible to isolate single-entry, single-exit struc-tures within a program with gotos in it

Even when formal proof techniques are not being used, but where an informal study

of the program is being made, the single-entry and single-exit character of programs aids checking and understanding

Deskilling

The gotostatement is one tool among many provided by the programming language To take it away from the programmer is to deprive him or her of a tool that can be validly used in certain circumstances

Consider a craftsperson who is an expert at making delicate objects from wood Suppose that we remove from that person a tool that we consider to be inappropriate, say an ax The skill of making a discriminating selection among the available tools is reduced, because the choice is narrower Furthermore, the skill in using the tool is no

longer required (Remember, however, that there may occasionally be circumstances in which an ax is the most suitable tool.)

Exceptions

Often a program is required to detect an error and to take some special action to deal with it Suppose that such an error is detected many levels down in a chain of method calls One way of handling the error is to create an additional parameter associated with each method call This approach can become very unwieldy as methods receive and merely pass on parameters that they do not need to act on

An alternative is for the method detecting the error to simply gotoa suitable place

in the program where the error can be dealt with This can result in a significant sim-plification to the program The essence of the argument is that an exceptional situation

in the program demands an exceptional solution – a goto

Some programming languages, such as Java, have solved this problem using a special mechanism for handling exceptional situations

Program performance

On occasions it is possible to write a program that will run more quickly using goto

statements An example is a program to search an array afor an item x:

for i = 1 to tableSize

if a[i] = x then goto found endif endfor

notfound:

found:

The nearest we can get to writing this as a structured program is to write:

i = 1 while i <= tableSize and a[i] not = x

i = i+1 endwhile

if i > m then

-endif

which requires an additional test Although both programs achieve the same end – finding (or not finding) the desired item – the steps taken by the two programs differ The first (unstructured) program takes fewer steps, and there is no way of writing a structured pro-gram that works in the same way Thus it is possible to write gotoprograms that run more quickly than structured ones

Naturalness

Consider the table searching program above Arguably the unstructured solution is the best in the sense that it is the solution that solves the problem most naturally Any trans-formation of this program, or any other solution, is a distortion of the natural solution

In other words, getting rid of gotos in existing programs (as can always be done), will sometimes needlessly destroy a good program

The trouble is deciding what is natural It surely differs from person to person, depending on individual psychology and cultural experiences So it is a rather subjec-tive judgment

Rather than take part in a parochial debate about the merits of a particular control structure, let us take a constructive approach If we had a free choice and a blank piece

of paper, what control structures would we choose to use in programming? Perhaps our first consideration should be to establish the principles that govern the selection Let us examine the following criteria:

■ standardization

■ abstraction

■ expressive power

■ orthogonality

■ minimality

We shall see that some of these conflict with each other Note also that in our examin-ation we are confining ourselves to sequential, imperative programming, in contrast to concurrent or declarative programming (as in logic or functional programming)

Standardization

Domestic appliances exhibit enormous variety and yet all plug into a standard socket Similarly, it is desirable to build software from components that all exhibit the same external interface

The simplest interface comprises one entry point, at the start, and one exit point at the end This has the strength of being consistent with the essence of sequential pro-gramming It also conforms to the important idea of calling a method We are used to the idea of calling a method as a sequential step and returning from it to the next instruction in sequence (We do not, for example, expect to supply a label as a param-eter to which control is returned.)

Abstraction

This is probably the most important idea in structured programming The human mind cannot devise or understand the whole of a complex system Instead we can only under-stand one part of the system at a time Nonetheless it is vital to underunder-stand the whole system The only way to resolve these contradictory statements is to be able to perceive

the overall structure in a digestible way The solution is to use abstraction, that is, the

system must be described in a notation that allows subsystems to be seen as black boxes whose task is readily understood but whose detail is invisible In programming, the method has long been a mechanism that fulfills this role

Other constructs that possess the same single-entry at the start, single-exit at the end property, are if-then-elseand while-do.

Expressive power

In discussing the arguments against the gotostatement, we saw that the gotois too primitive It has more to do with describing what a machine will do than what a pro-grammer intends Instead we look at the range of structures on offer, tempted on the one hand to seize every mechanism available, while at the same time conscious of the need for minimality

Certainly we need some mechanism for repetition, and either a whilestatement or recursion is sufficient to provide this facility Many languages provide both a while

statement and a repeat-untilstatement Most languages also support recursion

Arguably we also require a statement to carry out a choice of actions following a test The if-then-elsefulfills this requirement, but others are equally valid, including the

casestatement Again, we are torn between expressive power and minimality

Orthogonality

When designing a set of facilities, a good design principle is to create features that are each as different from each other as possible If this is so, we can more easily satisfy the goal of a minimum number of functions, while at the same time ensuring that the facil-ities are sufficiently powerful for all our needs

Minimality

The principle of minimality curbs our tendency to include too many facilities A conse-quence of Bohm and Jacopini’s theorem is that we know that the three control structures

(sequence, selection and iteration) are sufficient (Strictly, a construct for iteration, such

as a while, is also unnecessary, because any loop that can be written iteratively can also,

in theory, be achieved using only recursion.) Consider the flowcharts of various control structures Sequence has one box, whilehas two, and ifhas three boxes There are other control structures that involve only three or less boxes; but from amongst them all, these are the minimal feasible set

It is easy to become engrossed in the arguments about the gotostatement, but is this the central issue of structured programming?

Can a program that is written using only the three structures claim to be well struc-tured? The answer is no; it is possible to create a bad program structure using the three structures, just as it is possible (with greater difficulty) to create a good structure that uses gotostatements To illustrate why this is so, consider a badly structured program that has been written using many gotos If we now transform this into a program that uses the three structures, we still have a badly structured program, since we have done nothing significant to improve it

As a second example, consider a program to search a table for a required item Two alternative solutions, one structured, the other not, were compared earlier However, arguably, neither of these is the best solution Here is another, in which the item being sought is first placed at the end of the table:

a[tableSize + 1] = x

i = 1 while a[i] not = x

i = i + 1 endwhile

if i = tableSize + 1 then

else endif

This is arguably the best of the solutions because it is less complex (the condition in the while statement is simpler) and would execute more quickly on a conventional computer (for the same reason that there is only one condition to test) This example illustrates that the use of the approved structures does not necessarily guarantee the best design

A structured program is essentially one that can be understood easily, and the most useful tool in understanding is abstraction Abstraction is concerned with identifying the major elements of what is being studied, and ignoring detail Such is the complex-ity of software that we have to do this in order to stand a chance of understanding it

Abstraction can only be achieved if the control flow constructs are used in a disci-plined way, so that part of structured programming is the avoidance of gotos For example, consider the program in Figure 7.3

We can draw boxes around components as shown Because it is built from limited control structures, we can view the program at all levels of detail as consisting of abstract components that have only one entry and one exit If we examine any subsys-tem of the program, it is totally contained – the boxes do not overlap If we look in detail at its contents, it does not suddenly sprout connections with other subsystems When we uncover the nested contents of a traditional Russian wooden doll, we do not expect suddenly to encounter a doll that affects any of those we have already seen (Structured programs are, of course, more complex than these dolls; it is as if, when we open a doll, not just one, but several more are revealed.)

Suppose that in the above program we inserted a gotoas shown in Figure 7.4 We have now ruined the structure, since we can no longer view the program at different levels of abstraction

As an analogy compare the problems of understanding a plate of spaghetti as com-pared with a plate of lasagna In order to understand the spaghetti, we have to under-stand it all; we cannot employ abstraction With the lasagna, we can peel off layers, one

by one, uncovering the interesting detail of successive layers and understanding each separately from the others

while do

if then

else

endif

endWhile

if then

endif

Figure 7.3 A structured program, showing self-contained components