Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
SELF-TEST QUESTION 9.4 Discussion 117 9.2 Enhance the structure chart for the patient monitoring software so as to show the logging. 9.4 ● Discussion Why does the data flow method prescribe these steps? There are two main ideas behind the method: 1. the connection between data flows and modularity 2. the idea of an idealized software structure. The first concerns the data flow diagram. Why exactly do we draw a data flow diagram and what is its significance? The answer is that the central aim of this technique is to create a design with the best possible modularity. As described in Chapter 6, the different types of modularity have been analyzed and classified in an attempt to identify which is the best sort of modularity. Perfect modularity would mean that an individual component could be designed, tested, understood and changed when necessary without having to understand anything at all about any other component. The result of the analysis is that out of all the types of relationships, the most independent components are those that communicate with each other only by inputting and outputting serial streams of data – just like the bubbles in a data flow diagram. This type of interaction is termed data coupling. The second idea behind the data flow design method is the observation that many software systems have a similar overall structure. Most software carries out some input, performs some action on the input data and then outputs some information. The most important of these three is the action or transformation on the data. Therefore, in general, the ideal structure for any software is as shown in Figure 9.8. We have seen that the component that does the main processing should be at the top. If we now look at what the input component does, it is likely that it can be broken down into two components, one that inputs some raw data and another that converts it into a more convenient form. The corresponding structure diagram is shown in Figure 9.9. Figure 9.8 Idealized structure for software Process Input Output
118 Chapter 9 ■ Data flow design Input raw data Figure 9.9 Converting raw data for input Process Input Output Convert In general, a piece of software will require that several transformations are carried out on its input data streams and that, after the main processing, several transformations are carried out on its output data streams. We can use an analogy from outside computing. To make wine, we have first to grow vines, pick the grapes, transport them to the farm, and then press them. Only then can we carry out the central task of fermentation. After this we have to pour the wine into bottles, store the bottles for some time, and finally transport them to the shop. Data flow design recognizes this as the archetypal structure for software systems. As we have seen, data flow design concentrates on modeling the flows of data within software. The essential ingredient is any application in which the flows of data are important and can be identified easily. Data flows are significant because nearly every software system involves data flows. In all computer systems information enters the computer as a serial stream of data, simply because time flows serially. Similarly any component within a software system is only capable of carrying out one task at any time. Thus the demands placed on any component are a serial data stream. Therefore data flows constitute a fundamental concept within software. Summary Data flow design proceeds by initially analyzing the data flows and transformations within a software system. The first task is to draw the data flow diagram (bubble diagram), consisting of arcs (data flows) and bubbles (transformations). This diagram can be arrived at by using any one of the following three methods: 1. starting with a single, large bubble, break it up into smaller bubbles 2. start with the output data stream from the software and trace it backwards 3. start with the input data stream to the system and trace it forwards.
- 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 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 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
- Page 182 and 183: Figure 12.4 Pipe and Filter pattern
- Page 184 and 185: Figure 12.6 Layers in a distributed
- Page 186 and 187: Answers to self-test questions 163
- Page 188 and 189: CHAPTER 13 Refactoring This chapter
SELF-TEST QUESTION<br />
9.4 Discussion 117<br />
9.2 Enhance the structure chart <strong>for</strong> the patient monitoring software so as to<br />
show the logging.<br />
9.4 ● Discussion<br />
Why does the data flow method prescribe these steps? There are two main ideas behind<br />
the method:<br />
1. the connection between data flows and modularity<br />
2. the idea of an idealized software structure.<br />
The first concerns the data flow diagram. Why exactly do we draw a data flow diagram<br />
and what is its significance? The answer is that the central aim of this technique is to create<br />
a design with the best possible modularity. As described in Chapter 6, the different<br />
types of modularity have been analyzed and classified in an attempt to identify which is<br />
the best sort of modularity. Perfect modularity would mean that an individual component<br />
could be designed, tested, understood and changed when necessary without having to<br />
understand anything at all about any other component. The result of the analysis is that<br />
out of all the types of relationships, the most independent components are those that<br />
communicate with each other only by inputting and outputting serial streams of data – just<br />
like the bubbles in a data flow diagram. This type of interaction is termed data coupling.<br />
The second idea behind the data flow design method is the observation that many<br />
software systems have a similar overall structure. Most software carries out some<br />
input, per<strong>for</strong>ms some action on the input data and then outputs some in<strong>for</strong>mation.<br />
The most important of these three is the action or trans<strong>for</strong>mation on the data.<br />
There<strong>for</strong>e, in general, the ideal structure <strong>for</strong> any software is as shown in Figure 9.8.<br />
We have seen that the component that does the main processing should be at the top.<br />
If we now look at what the input component does, it is likely that it can be broken down<br />
into two components, one that inputs some raw data and another that converts it into a<br />
more convenient <strong>for</strong>m. The corresponding structure diagram is shown in Figure 9.9.<br />
Figure 9.8 Idealized structure <strong>for</strong> software<br />
Process<br />
Input Output
Change language