Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
■ if-then-else ■ while-do or repeat-until ■ exit ■ method call 7.2 Arguments against goto 91 It is as if the goto is 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 goto lacks expressive power and it is therefore difficult to understand the logic of a program that is written using a lot of gotos. When we look at a piece of coding, words like while and if give 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 program 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 while statement or a for loop, 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 goto that 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 if statement, we can never dispense with pencils; instead we need ever more. The increased number of pencils reflects the increased complexity of the goto program. 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 without 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.
92 Chapter 7 ■ Structured programming 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 program that it can always be read from top to bottom – provided it has no methods. The exception to this rule arises in comprehending a while loop, 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 program 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 corresponds 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 program. 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 structures 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. 7.3 ● Arguments in favor of goto Deskilling The goto statement 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
- 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 112 and 113: 7.2 Arguments against goto 89 If we
- 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
- Page 162 and 163: CHAPTER 11 Object-oriented design T
■ if-then-else<br />
■ while-do or repeat-until<br />
■ exit<br />
■ method call<br />
7.2 Arguments against goto 91<br />
It is as if the goto is too primitive an instruction – like a machine instruction to load<br />
a register – that can be used in a whole variety of circumstances, but does not clearly<br />
convey its meaning in any of them.<br />
In summary, the goto lacks expressive power and it is there<strong>for</strong>e difficult to understand<br />
the logic of a program that is written using a lot of gotos. When we look at a<br />
piece of coding, words like while and if give us a strong clue as to what is intended;<br />
gotos do not.<br />
How many pencils?<br />
Suppose we want to read a program in order to understand it by tracing through it as<br />
if we were a computer executing it. Suppose we have available a supply of pencils (or<br />
fingers) to help us. The pencils will be used as markers, and are to be placed on the program<br />
listing to point to places of interest.<br />
If we are following a simple sequence, then we will only need one pencil to keep<br />
track of our position. If we encounter a method call, we need two pencils, one to leave<br />
at the point of the call (in order to know where to return) and another to proceed into<br />
the method.<br />
If we encounter a while statement or a <strong>for</strong> loop, then we need an integer, a counter,<br />
to keep count of the number of times we have repeated the loop.<br />
To summarize, if the program has been written in a structured way, we need:<br />
■ one pencil to point to the current position<br />
■ one pencil to point to each method call that has been executed but not returned from<br />
■ a counter <strong>for</strong> every uncompleted loop.<br />
This may seem like a lot of equipment, but consider the alternative of a program that<br />
contains a lot of gotos. As be<strong>for</strong>e, we will need to indicate the position of the current<br />
statement. Next, we need a pencil to point at every goto that has been executed. But<br />
now, whereas in the structured program we can remove a pencil whenever we return<br />
from a method, finish a loop or complete an if statement, we can never dispense with<br />
pencils; instead we need ever more. The increased number of pencils reflects the<br />
increased complexity of the goto program.<br />
The real problem becomes evident when we want to refresh our memory about what<br />
happened be<strong>for</strong>e we arrived at the current point in the program. In the program without<br />
gotos we simply look back up the program text. In the unstructured program,<br />
when we look backwards we are defeated as soon as we reach a label, because we have<br />
no way of knowing how we reached it.