Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
Exercises 109 skill. On the other hand, it is an excellent approach if we want a method that guides our thinking but allows us plenty of scope for creativity. In a sense, therefore, the method is not as advanced as some. For example, data structure design takes the programmer from a description of the structure of the data or files that the program is to act upon, via a number of fairly precise steps to the program design. By contrast, the use of functional decomposition encourages (some would say necessitates) the use of creativity and imagination in devising software structures. Its use also needs careful judgment in selecting the best structure from amongst any alternatives found. In summary, functional decomposition is a general-purpose method for software design, based around structured programming, but in allowing the development of alternative designs for the same problem it poses several unanswered questions: ■ where do we get the inspiration for alternative designs? ■ how do we choose between designs? ■ how do we know that we have arrived at the best possible design? We have to look to other sources of ideas to answer these questions. These issues have led some to say that functional decomposition is not really a serious method. Summary Functional decomposition proceeds by starting with a single statement of each function of the software. Next these are rewritten as a series of simpler steps using pseudo-code (program design language) as a notation. Pseudo-code consists of natural language imperative sentences written as sequences, with if statements or with while statements. The designs are refined (rewritten as more primitive steps) until the required level of detail is achieved. The method makes direct use of the power of abstraction provided by structured programming, while requiring significant creativity and judgment to be employed. It is applicable to the full range of computer application areas. • Exercises 8.1 Complete the design of the game program. 8.2 Write pseudo-code for the withdraw cash function in the ATM (Appendix A). 8.3 Use functional decomposition to design the software for each of the systems described in Appendix A. 8.4 What characteristics should a good software design method have? Does the functional decomposition exhibit them?
110 Chapter 8 ■ Functional decomposition 8.5 Evaluate functional decomposition under the following headings: ■ special features and strengths ■ weaknesses ■ philosophy/perspective? ■ systematic? ■ appropriate applications ■ inappropriate applications ■ is the method top-down, bottom-up or something else? ■ good for large-scale design? ■ good for small-scale design? 8.6 Compare and contrast the principles behind the following design methods: ■ functional decomposition ■ data structure design ■ data flow design ■ object-oriented design Answer to self-test question 8.1 move alien if x > window width or x < 0 then stepSize = -stepSize; endif x = x + stepSize; • Further reading Arguably the most important book about structured programming is: O.J. Dahl, E.W. Dijkstra and C.A.R. Hoare, Structured Programming, Academic Press, 1997.
- 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 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 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
- Page 164 and 165: Figure 11.1 The cyberspace invaders
- Page 166 and 167: SELF-TEST QUESTION 11.1 Derive info
- Page 168 and 169: 11.5 Class-responsibility-collabora
- Page 170 and 171: 11.7 ● Discussion Summary 147 OOD
- Page 172 and 173: 11.11 Compare and contrast the prin
- Page 174 and 175: CHAPTER 12 This chapter explains: 1
- Page 176 and 177: 12.3 Delegation 153 The concepts of
- Page 178 and 179: 12.5 Factory method 155 The followi
- Page 180 and 181: 12.8 Model, view controller (observ
Exercises 109<br />
skill. On the other hand, it is an excellent approach if we want a method that guides<br />
our thinking but allows us plenty of scope <strong>for</strong> creativity. In a sense, there<strong>for</strong>e, the<br />
method is not as advanced as some. For example, data structure design takes the programmer<br />
from a description of the structure of the data or files that the program is to<br />
act upon, via a number of fairly precise steps to the program design. By contrast, the<br />
use of functional decomposition encourages (some would say necessitates) the use of<br />
creativity and imagination in devising software structures. Its use also needs careful<br />
judgment in selecting the best structure from amongst any alternatives found.<br />
In summary, functional decomposition is a general-purpose method <strong>for</strong> software<br />
design, based around structured programming, but in allowing the development of<br />
alternative designs <strong>for</strong> the same problem it poses several unanswered questions:<br />
■ where do we get the inspiration <strong>for</strong> alternative designs?<br />
■ how do we choose between designs?<br />
■ how do we know that we have arrived at the best possible design?<br />
We have to look to other sources of ideas to answer these questions. These issues<br />
have led some to say that functional decomposition is not really a serious method.<br />
Summary<br />
Functional decomposition proceeds by starting with a single statement of each<br />
function of the software. Next these are rewritten as a series of simpler steps using<br />
pseudo-code (program design language) as a notation. Pseudo-code consists of<br />
natural language imperative sentences written as sequences, with if statements or<br />
with while statements. The designs are refined (rewritten as more primitive steps)<br />
until the required level of detail is achieved.<br />
The method makes direct use of the power of abstraction provided by structured<br />
programming, while requiring significant creativity and judgment to be<br />
employed. It is applicable to the full range of computer application areas.<br />
•<br />
Exercises<br />
8.1 Complete the design of the game program.<br />
8.2 Write pseudo-code <strong>for</strong> the withdraw cash function in the ATM (Appendix A).<br />
8.3 Use functional decomposition to design the software <strong>for</strong> each of the systems<br />
described in Appendix A.<br />
8.4 What characteristics should a good software design method have? Does the functional<br />
decomposition exhibit them?