Software Engineering For Students: A Programming Approach Part 13 pot

Although a program that uses the three structures may have abstraction of control, it may well have global data.. Thus control abstraction is only one side of the coin; the other side is

98 Chapter 7■ Structured programming

Notice, though, that throughout our discussion we have concentrated almost

exclu-sively on control structures and have neglected references to data Although a program

that uses the three structures may have abstraction of control, it may well have global data This seriously weakens the abstraction, since at any level of detail all of the data has to be considered Thus control abstraction is only one side of the coin; the other side is data abstraction – an important theme that is developed in the chapters on mod-ularity, object-oriented design and object-oriented programming later in this book The idea of abstraction is a powerful tool in constructing software that is under-standable, but, by itself, it is inadequate In order to create programs that are well

struc-tured, we need a systematic method that takes us from the statement of the problem to

the structure of the program There are a variety of methods, discussed in later chapters

while do

if then

else

endif

endWhile

if then

endif

goto label

label:

Figure 7.4 An unstructured program

Summary

The arguments against the gotoare:

1. it is unnecessary

2. the experimental evidence

3. the lack of expressive power of gotos

Exercises 99

7.1 Review the arguments for and against goto statements and criticize their validity.

7.2 State in your own words what structured programming is Imagine that you meet a

friend who is used to programming using gotos Explain in simple clear language what

structured programming is

7.3 A while statement can be used instead of an if statement, because the statement:

if bool then s endif

can be rewritten as:

while bool do s bool = false endwhile

Show how an if-then-else statement can similarly be rewritten using while state-ments If the if statement is superfluous, why have it?

4. the difficulty of finding out where you came from in a program constructed using gotos

5. the need to read backwards in a program with gotos in it

6. the difficulty of proving the correctness of programs that use gotos

The arguments for gotos are:

1. to ban them is to deskill programming

2. they have a use in exceptional circumstances

3 gotos are sometimes necessary in order to make programs perform well

4. it is sometimes “natural” to use gotos

Much of the debate about structured programming has been conducted in this way

Throughout the arguments, the need for clarity in programs is the dominant idea

The avoidance of gotos does not necessarily lead to a structured program The central idea of structured programming is abstraction Indeed, we can define struc-tured programming as:

“the systematic use of (control) abstraction in programming”

(Abstraction can be applied not just to control, but to data as well This is the sub-ject of other chapters.)

Abstraction requires not only the use of suitable control structures but also a sys-tematic design method

Exercises

•

100 Chapter 7■ Structured programming

7.4 Convert the following into a structured program

i = start loop:

if x = a[i] then goto found endif

if i = end then goto notFound endif

i = i + 1 goto loop

notFound:

display 'not found' action1

goto end

found:

display 'found' action2

end:

Compare and contrast the two programs

7.5 Recursion can be used to accomplish repetition, as in the following example of a method to skip spaces in a stream of input information:

method skipSpaces read(char)

if char = space then skipSpaces endif endmethod

Convert this example to a method that uses a while statement for repetition Compare

and contrast the two solutions What is the role of recursion in the programmer’s toolkit?

7.6 Argue for and against providing the following constructs in a programming lan-guage:

■ case

■ repeat-until

■ until-do

Answer to self-test question 7.1 count = 0

while count < 10 do count = count + 1 endwhile

Further reading 101

The famous article that launched the debate about structured programming is: E.W

Dijkstra, Go To statement considered harmful, Communications of the ACM, 11(3)

(March 1968), pp 147–48

It is widely agreed that structured programming is a vital ingredient of software devel-opment For a review of the (inconclusive) experimental evidence about the effec-tiveness of structured programming, see: I Vessey and R Weber, Research on

structured programming: an empiricist’s evaluation, IEEE Trans on Software

Engineering, 10 (4) (1984), pp 397–407.

A vigorous exposition of the argument that structured programming is de-skilling is

given in: P Kraft, Programmers and Managers, Springer-Verlag, 1977

count = 0 loop:

count = count + 1

if count < 10 goto loop

Further reading

•

Functional decomposition is a technique for designing either the detailed structure or the large-scale structure of a program or module As its name suggests, functional decompo-sition is a method that focuses on the functions, or actions, that the software has to carry out To use the method we first write down, in English, a single-line statement of what the software has to do If the software performs several functions (as most GUI-driven software does) write down a single line for each function For example, suppose we want to write a program to direct a robot to make a cup of instant coffee We could begin by writing:

make a cup of coffee

Then we express the problem solution in terms of a sequence of simpler actions:

boil water get a cup put coffee in cup add water

add milk add sugar to taste

Next we take each of these statements and write down what it does in greater detail This process of decomposition or refinement is continued until the solution is expressed

in sufficient detail Usually this is when the solution corresponds to the statements provided by the programming language to be used

This chapter explains:

■ how to use functional decomposition

■ the principles behind the method

CHAPTER

8 Functional

decomposition

8.2 Case study 103

A statement that is to be broken down may be regarded as a method call The set of more elementary steps into which it is decomposed can be viewed as the implementation

of the method

The language that is used to express the solution is called pseudo-code (because it is similar in some ways to programming language code), or program design language (PDL) It consists of sequences of (natural language) sentences, each beginning with a verb It also involves the usual control structures – if-then-elsefor selection and while

for repetition For example, the statement boil waterabove can be refined to:

boil water

switch on kettle while water not boiling do watch tv

endwhile switch off kettle

Again we can refine add sugar to tasteas:

add sugar to taste

if sugar required then

put sugar in cup stir

endif

We can restrict ourselves just to whileand ifor we can make use of the repeat,

forand caseconstructs

In order to illustrate the use of functional decomposition, we will design the software for a simple game called cyberspace invaders The screen is shown in Figure 8.1 The specification of the program (also given in Appendix A) is as follows:

A window displays a defender and an alien (Figure 8.1) The alien moves sideways When it hits a wall, it reverses its direction The alien randomly launches a bomb that moves vertically downwards If a bomb hits the defender, the user loses and the game is over The defender moves left or right according to mouse movements When the mouse

is clicked, the defender launches a laser that moves upwards If a laser hits the alien, the user wins and the game is over.

A button is provided to start a new game.

The program responds to events from the play button, a timer, mouse clicks and mouse move events To create animation, we move all the objects and redisplay them whenever the timer produces an event So the overall logic is:

timer event

move all the objects display all the objects check hits

mouse clicked event

create laser

mouse moved event

move defender

104 Chapter 8■ Functional decomposition

Figure 8.1 Cyberspace invaders

8.2 Case study 105

start button event

create defender create alien start timer

We have hidden the detail in such statements as:

move all the objects

and we can study and check the high-level design without worrying about detail

When we are satisfied with the high-level design, we choose one of the statements and write down what it does in more detail An obvious first candidate is:

move all the objects

move alien move bomb move laser check boundaries

and then:

display all the objects

display background display defender display alien display laser display bomb

At this stage we have expressed the design in terms of a number of methods The most complex of these are check hits and check boundaries So we now design their detail:

check hits

if collides(laser, alien) then

endOfGame(userWins) else

if collides(bomb, defender) then

endOfGame(alienWins) endif

check boundaries

if bomb is outside window then

destroy bomb endif

if laser is outside window then

destroy laser endif

This completes some of the detail The next item that has some complexity is the method collides It has two parameters, the objects to be tested for impact It returns either true or false It uses the x and y coordinates of the objects,

together with their heights and widths We use the notation a.x to mean the x

coordinate of object a (The joy of pseudo-code is that you can use any notation that is convenient.)

collides(a, b)

if a.x > b.x and a.y < b.y + b.height and a.x + a.width < b.x + b.width and a.y + a.width > b.y

then return true else

return false endif

This illustrates how we have used the tool of abstraction to hide this complexity within a method

There is still some way to go with this particular design, but this much gives the flavor

of the design and of the method Notice how the design is refined again and again Notice how, throughout, we can check the design without having to take account of a lot of unnecessary detail Notice the informality of the statements used; we can simply make up new actions as necessary, but still within the discipline of the control structures – sequence,

ifand while, supplemented with methods

106 Chapter 8■ Functional decomposition

SELF-TEST QUESTION

8.1 Write method move alienassuming it is at window coordinates x

and y

One way of visualizing functional decomposition is to see that at any stage of decompo-sition the solution is expressed in terms of operations that are assumed to be available and provided by an abstract (or virtual) machine, like a very high-level programming lan-guage This is the idea of “levels of abstraction” In order to design and understand a solution at any one level of detail, it is not necessary to understand anything about how

the levels beneath work We know what they do, but not how they do it Thus the human

mind has a much better chance of understanding the solution and therefore of getting

it right

One approach to using functional decomposition is to refine the software design level by level The software structure can be visualized as an upside-down tree – always

with a very flat top that grows downwards uniformly This is the breadth-first approach

to design; it matches the strict, abstract machine view of software design described above

An alternative approach is to pursue one of the branches of the tree, leaving the others

stunted until later (This is called depth first.) Our motive for doing this might be to explore

what seems to be a difficult part of the software We might thereby hope to gain insights that guide us in refining the rest of the structure

This idea of trying to ignore the detail of lower levels of the design is easier said than done and takes some nerve It is a real test of whether we believe software design

is worthwhile and whether we can resist the temptation to rush on to coding pieces of the software

What about data?

What is the role of data in the method? It does rather play second fiddle to the actions that have to be taken The making of the cup of coffee illustrates that, by concentrating

on what the software should do, considerations of data are ignored, or rather postponed The idea is that the data emerges during the decomposition as it becomes evident what

is necessary and what needs to be done with it We defer decisions about pieces of data and the structure of information until we have a very clear knowledge of what operations have to be performed on them When that stage is reached we can design data which is tailored precisely to the operations

There is a possible problem here Suppose a program is written in this way and later needs modifying What happens if some new operation on the data is required? Remember that the data was designed with the old operations in mind, so it may not be in a con-venient form for the new

Another question about functional decomposition is whether it is actually possible

to delay thinking about data in this way

8.3 Discussion 107