Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
9.3 Creation of a structure chart 115 Method 3 is the same as method 2, except that we start from the input flow to the system and work out the sequence of transformations that should be applied to it. There is no definite, systematic way of drawing these diagrams. Lots of paper, pencil and erasers (or a software tool) are needed – together with a lot of creativity. Now that we have obtained the data flow diagram using one of these methods, what do we do with it? One option is to regard each bubble as a component that inputs a serial stream of data from one component and outputs a serial stream to another. Some operating systems (such as Unix) and some languages (such as the piped input and output streams facility in Java) support this “filter and pipe” software architecture. This means that we can directly implement a data flow diagram as a series of filters and pipes. However, if pipes are not available, a data flow diagram must be transformed into a structure in which components make method calls on each other. SELF-TEST QUESTION 9.1 The data flow for the log file is omitted from the above data flow diagram. Add this data flow. 9.3 ● Creation of a structure chart The first and most crucial step of data flow design is drawing the data flow diagram. Such a diagram shows the transformations and the flows of data between them. The next step is to convert the data flow diagram into a structure chart or structure diagram. A structure chart shows the components that comprise the software and how they call each other. Suppose, for example, that some software consists of three components named A, B and C. Suppose that component A calls component B and also component C. The structure chart for these components is shown in Figure 9.6. A structure chart is thus a hierarchical diagram that shows components at the higher levels calling components at lower levels. A structure chart is a tree, with one single root at the top of the chart. Notice by contrast that a data flow diagram is not hierarchical. Let us now consider the patient monitoring system and see how to convert the data flow diagram into its equivalent structure chart. In this data flow diagram, arguably the A B C Figure 9.6 Structure chart in which component A calls B and C
116 Chapter 9 ■ Data flow design central and most important bubble is the check bubble. We take this to be the main, most important component. Imagine that we can touch and move the objects within the diagram. Suppose that the bubbles are joined by pieces of string. Grasp the central component and lift it into the air. Let the other bubbles dangle beneath. Next change the bubbles into rectangles. We now have a structure chart that looks like Figure 9.7. Each box is a software component. The components communicate by calls from higher components to lower components. The data that flowed along lines in the data flow diagram is now passed as parameters to and from the various components. The check component calls the convert component which in turn calls the read data component to obtain data. Then it calls the display message component to display the output on the screen. As we have illustrated, the steps for converting a data flow diagram into a structure chart are: 1. identify the most important bubble (transformation) 2. convert this into the top-level component in the structure chart 3. allow the other components to dangle beneath the top-level component, creating a hierarchical tree 4. convert the bubbles into rectangles and the data flows into lines representing method calls. The patient monitoring example illustrates how to use the data flow design method. But the example chosen is simple and we have deliberately avoided drawing attention to complications. Data flow diagrams typically have tens of bubbles and can be quite complex. Often there are several input and output data flows. In more complex diagrams, it can be difficult to identify a single center of the diagram. Notice that although the method leads us to a structure for a piece of software that is expressed in terms of well-defined, independent components, we still have to design the detail of each and every component; we have to carry out the low-level or detailed design. This emphasizes that data flow design is a method for high-level or architectural design. convert read data check Figure 9.7 Structure chart for patient monitoring software display message
- 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 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 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
- 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
9.3 Creation of a structure chart 115<br />
Method 3 is the same as method 2, except that we start from the input flow to the<br />
system and work out the sequence of trans<strong>for</strong>mations that should be applied to it.<br />
There is no definite, systematic way of drawing these diagrams. Lots of paper, pencil<br />
and erasers (or a software tool) are needed – together with a lot of creativity.<br />
Now that we have obtained the data flow diagram using one of these methods, what<br />
do we do with it? One option is to regard each bubble as a component that inputs a<br />
serial stream of data from one component and outputs a serial stream to another. Some<br />
operating systems (such as Unix) and some languages (such as the piped input and output<br />
streams facility in Java) support this “filter and pipe” software architecture. This<br />
means that we can directly implement a data flow diagram as a series of filters and pipes.<br />
However, if pipes are not available, a data flow diagram must be trans<strong>for</strong>med into a<br />
structure in which components make method calls on each other.<br />
SELF-TEST QUESTION<br />
9.1 The data flow <strong>for</strong> the log file is omitted from the above data flow diagram.<br />
Add this data flow.<br />
9.3 ● Creation of a structure chart<br />
The first and most crucial step of data flow design is drawing the data flow diagram. Such<br />
a diagram shows the trans<strong>for</strong>mations and the flows of data between them. The next step<br />
is to convert the data flow diagram into a structure chart or structure diagram. A structure<br />
chart shows the components that comprise the software and how they call each<br />
other. Suppose, <strong>for</strong> example, that some software consists of three components named A,<br />
B and C. Suppose that component A calls component B and also component C. The<br />
structure chart <strong>for</strong> these components is shown in Figure 9.6.<br />
A structure chart is thus a hierarchical diagram that shows components at the higher<br />
levels calling components at lower levels. A structure chart is a tree, with one single root<br />
at the top of the chart. Notice by contrast that a data flow diagram is not hierarchical.<br />
Let us now consider the patient monitoring system and see how to convert the data<br />
flow diagram into its equivalent structure chart. In this data flow diagram, arguably the<br />
A<br />
B C<br />
Figure 9.6 Structure chart in which component A calls B and C
Change language