Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
7.2 Arguments against goto 89 If we visualize any one of the three constructs as they are used, then a third characteristic 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 while statement, then using goto. 7.2 ● Arguments against goto gotos are unnecessary Fortunately there is a mathematical theorem (thanks to Bohm and Jacopini) guaranteeing 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 “unstructured” 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 according 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 unstructured ones. In a typical experiment, each of a group of subjects is presented with the
90 Chapter 7 ■ Structured programming > 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 generally 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: ------ ------- ------ ------label: while a > 0 ------ ------- ------ ------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 goto are. It would take us some time to read and study the program 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 program. Worse, there is a remaining doubt in the first program that there may be another goto aimed 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 construct for use in each of these different circumstances. These are, respectively: >
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 114 and 115: ■ if-then-else ■ while-do or re
- Page 116 and 117: 7.3 Arguments in favor of goto 93 l
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
- Page 132 and 133: Exercises 109 skill. On the other h
- Page 134 and 135: CHAPTER 9 This chapter explains: 9.
- Page 136 and 137: 9.2 Identifying data flows 113 Noti
- Page 138 and 139: 9.3 Creation of a structure chart 1
- Page 140 and 141: SELF-TEST QUESTION 9.4 Discussion 1
- Page 142 and 143: Exercises 119 During the second sta
- Page 144 and 145: CHAPTER 10 This chapter explains:
- Page 146 and 147: In English, this reads: 10.2 A simp
- Page 148 and 149: 10.2 A simple example 125 Now comes
- Page 150 and 151: 10.4 Multiple input and output stre
- Page 152 and 153: Process header Process issue 10.4 M
- Page 154 and 155: 10.5 Structure clashes 131 As seen
- Page 156 and 157: 10.5 Structure clashes 133 Let us r
- Page 158 and 159: 10.6 Discussion 135 ■ teachable -
- Page 160 and 161: Exercises 137 2. a control block, s
7.2 Arguments against goto 89<br />
If we visualize any one of the three constructs as they are used, then a third characteristic<br />
is evident:<br />
3. the entry is at the start and the exit is at the end.<br />
Why is it that these characteristics are important? Why are other constructs that<br />
have the same characteristics (Figure 7.2) ruled out? We now go on to look at these<br />
questions.<br />
SELF-TEST QUESTION<br />
7.1 Write a loop that repeats ten times, first using a while statement, then<br />
using goto.<br />
7.2 ● Arguments against goto<br />
gotos are unnecessary<br />
Fortunately there is a mathematical theorem (thanks to Bohm and Jacopini) guaranteeing<br />
that any program written using goto statements can be trans<strong>for</strong>med into an<br />
equivalent program that uses only the structured constructs (sequence, selection and<br />
iteration). The converted program will, in general, need additional data items that are<br />
used as flags to control the actions of the program. Indeed the new program may look<br />
rather contrived; nonetheless, it can be done. On the face of it, there<strong>for</strong>e, there is no<br />
need <strong>for</strong> programs with gotos in them.<br />
Note, as an interesting side issue, that the theorem does not tell us how to trans<strong>for</strong>m<br />
the unstructured program; only that it can be done.<br />
Experimental evidence<br />
Structured programming is well established and widely regarded as the best approach<br />
to programming. You might think, there<strong>for</strong>e, that there would be clear evidence from<br />
real software projects that it is beneficial, but this is not so; there are no convincing<br />
results from real projects, largely because a carefully controlled experiment would be<br />
difficult and expensive to mount. It would be necessary to develop a particular piece of<br />
software in two ways: once using structured programming and again using “unstructured”<br />
programming. All other variables, like the expertise of the programmers, would<br />
have to be held constant. The two versions of the software could be compared according<br />
to criteria like development time and number of errors. Regrettably, there are no<br />
results of this type.<br />
However, experimenters have carried out small-scale studies comparing how easily<br />
people can understand and debug small structured programs compared with unstructured<br />
ones. In a typical experiment, each of a group of subjects is presented with the
Change language