Software Engineering For Students: A Programming Approach Part 15 ppsx

118 Chapter 9 ■ Data flow design
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 transforma-
tions 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 fer-
mentation. 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 with-
in 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.
Process
Input Output
Input
raw
data
Convert
Figure 9.9 Converting raw data for input
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 dia-
gram 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.
BELL_C09.QXD 1/30/05 4:21 PM Page 118
Exercises 119
9.1 Complete the development of the patient monitoring system described in this chapter.
9.2 Apply data flow design to devising an architectural structure for each of the systems
described in Appendix A.
9.3 What characteristics should a good software design method possess? Does data flow
design exhibit them?
9.4 Suggest the facilities of a software tool that could assist in using data flow design.
9.5 Compare and contrast the principles behind the following design methods:
■ functional decomposition
■ data structure design
■ data flow design
■ object-oriented design.
9.6 Evaluate data flow design 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?
During the second stage of data flow design, the data flow diagram is transformed
into a structure chart, showing the constituent components of the software and
their interrelationships, by:
1. identifying the most important or central transformation in the data flow dia-
gram
2. lifting this transformation into the air, leaving the others dangling beneath it.
This creates a hierarchical or tree-shaped structure for the software.
Arguably data flow design leads to the most modular structure for the software, since

the design is based on “data coupling” (the best type) between the components.
Exercises
•
BELL_C09.QXD 1/30/05 4:21 PM Page 119
120 Chapter 9 ■ Data flow design
■ good for large-scale design?
■ good for small-scale design?
9.7 Suggest features for a software toolkit to assist in using data flow design.
Answers to self-test questions
9.1 Arrow from the convert bubble to a log bubble. Then arrow from this
bubble to a log file data store.
9.2 Line downwards from the check component to a component labeled
log.
Data flow design is described in: E. Yourdon and Larry L. Constantine, Structured
Design, Prentice Hall, 1979.
Further reading
•
BELL_C09.QXD 1/30/05 4:21 PM Page 120
Starting with the specification of a program, this method, via a series of steps, leads to
a detailed design, expressed in pseudo-code. The method is variously called the Michael
Jackson program design method (after the name of its inventor), or Jackson Structured
Programming (JSP), and data structure design.
The basic idea behind the data structure design method is that the structure of a pro-
gram should match the structure of the information that the program is going to act
on. To get a feel for how this can be done, let us look at a few simple examples.
First, suppose we want a program to add a set of numbers held in an array, and ter-
minated by a negative number. Here’s some sample data:
29 67 93 55 –10
With experience of programming, we can, of course, immediately visualize the struc-
ture of this program. Its main feature is a

while loop. But a more rigorous way of look-
ing at the design is to realize that because there is a repetition in the data, there must
be a corresponding repetition in the program. Thus we have gone from the data struc-
ture to the program structure.
Consider a program that is to print a bank statement. The bank statement will be
printed on a number of pages. Each page has a heading, a series of ordinary lines (rep-
resenting transactions) and a summary line. Ignore, for the time being, the structure of
any input data. Again, with some experience of programming, we can visualize that we
10.1
●
Introduction
CHAPTER
10
Data structure
design
This chapter explains:
■ how to use data structure design
■ the principles behind the method.
BELL_C10.QXD 1/30/05 4:22 PM Page 121
122 Chapter 10 ■ Data structure design
will need statements to print a heading, print a transaction line and so on. But we can
also see that we will need:
■ a loop to print a number of pages
■ a loop to print the set of transaction lines on each page.
You can see that this description of the program structure matches the structure of
the report. What we have done is to derive the structure of the program from what we
know about the structure of the report.
These small examples show how it is possible to approach program design using the
structure of data. We will return to these examples later, showing exactly how the
method treats them.

Let us consider the design of a program to display the following pattern on a com-
puter screen. We will assume that, in drawing this pattern, the only possible cursor
movements are across the screen from left to right, and down to the beginning of a
new line.
*
***
*****
*****
***
*
The first step in the method is to analyze and describe the structure of the informa-
tion that the program is to create. The product of this step is called a data structure
diagram. The diagram for the pattern is given in Figure 10.1.
10.2
●
A simple example
Top half
Line Line
Bottom
half
Middle
**
Picture
Figure 10.1 Data structure diagram for the asterisks pattern
BELL_C10.QXD 1/30/05 4:22 PM Page 122
10.2 A simple example 123
In English, this reads:
■ the pattern consists of the top half followed by the middle, followed by the bot-
tom half
■ the top half consists of a line of asterisks, which is repeated. The bottom half also

consists of a line of asterisks which is repeated.
In general, the diagrammatic notation has the following meaning:
■ consists of – a line drawn downwards below a box means “consists of”. Thus
Figure 10.2 shows that A consists of B.
■ sequence – boxes at the same level denote a sequence. Figure 10.3 shows that A
consists of B followed by C.
■ repetition – an “*” in a box signifies zero or more occurrences of the component.
Figure 10.4 shows that A consists of B repeated zero or more times.
Having now described the data structure, the next step is to convert it into a program
structure. This is easy because, remember, the program structure must correspond to the
A
B
Figure 10.2 A consists of B
A
CB
Figure 10.3 A consists of B followed by C
A
B
*
Figure 10.4 A consists of B repeated
BELL_C10.QXD 1/30/05 4:22 PM Page 123
124 Chapter 10 ■ Data structure design
data structure, so all we have to do is to write “process” in every box of the data struc-
ture diagram. We thereby obtain a program structure diagram. For our program this is
shown in Figure 10.5.
A program structure diagram like this is interpreted as follows:
■ the program as a whole (represented by the box at the top) consists of (lines lead-
ing downwards) a sequence of operations (boxes alongside one another)
■ sometimes a program component is to be repeatedly executed (an “*” in the box).
The next step is to write down (in any order) a list of all the elementary operations

that the program will have to carry out. This is probably the least well-defined part of
the method – it does not tell us how to determine what these actions should be. For
the program we are working on they are:
1 display n asterisks
2 display blank line
3 display s spaces
4 increment s
5 decrement s
6 increment n
7 decrement n
8 initialize n and s
9 new line
For later reference, we number the operations, but the ordering is not significant.
Next each of these operations is placed in its appropriate position in the program
structure diagram. For example, operation 2 needs to be done once, for the middle
of the pattern. It is therefore associated with the box containing
process middle.
Similarly, operation 1 is associated with the component
process line (Figure 10.6).
This act of associating operations with positions is not automatic; instead, as indicated,
judgment has to be employed.
Process
line
Process
line
Process
bottom
half
Process
middle

Process
top half
**
Process
picture
Figure 10.5 Program structure diagram for the pattern program
BELL_C10.QXD 1/30/05 4:22 PM Page 124
10.2 A simple example 125
Now comes the final step of transforming the program structure diagram into pseudo-
code. Expressed in pseudo-code, the structure of our example program is:
initialize n and s
while more lines do
display s spaces
display n asterisks
new line
decrement s
increment n
endwhile
display blank line
initialize n and s
while more lines do
display s spaces
display n asterisks
new line
decrement n
increment s
endwhile
To derive this pseudo-code from the diagram, start with the box at the top of the
diagram and write down its elementary operations. Then indent the code across the
page and go down a level on the diagram. Now write down the operations and struc-

tures present at this level. Repeatedly go down a level, indenting the code for each new
level. This transformation is straightforward and mechanical.
We have now arrived at a program design capable of being readily translated into
most conventional programming languages.
8
Process
picture
Process
line
Process
line
Process
bottom
half
Process
middle
Process
top half
**
1 3 6 5 1
2
3 7 4
8
99
Figure 10.6 Annotated program structure diagram
>
>
BELL_C10.QXD 1/30/05 4:22 PM Page 125
To understand how to input and process information from a file, consider the follow-
ing problem:

A serial file consists of records. Each record describes a person. Design a program to
count the number of males and the number of females.
The data structure diagram is given in Figure 10.7.
The new notation here is the boxes with the letter “o” in them (meaning or) to
indicate alternatives. These boxes are drawn alongside each other. Depending on the
application, there are sometimes a number of alternatives.
10.3 ● Processing input files
126 Chapter 10 ■ Data structure design
To sum up, the steps we have taken are:
1. draw a diagram showing the structure of the file
2. derive the corresponding program structure diagram
3. write down the elementary operations that the program will have to carry out
4. place the operations on the program structure diagram
5. derive the pseudo-code of the program.
SELF-TEST QUESTION
10.1 Check that operation 9 (new line) has been placed in all the right
places on the program structure diagram.
Body
Record
eof
Male Female
*
File
Figure 10.7 Data structure diagram for counting males and females
BELL_C10.QXD 1/30/05 4:22 PM Page 126
10.4 Multiple input and output streams 127
We now derive the program structure diagram as before (not shown).
After writing down operations and assigning them to the program structure diagram
(not shown), we arrive at the following pseudo-code design:
open file

initialize counts
read record
while not end of file
do
if record = male
then increment male-count
else increment female-count
endif
read record
endwhile
display counts
close file
This recognizes that the boxes with alternatives in them become if-then-else
statements.
There is just one small point to note. Data structure design did not help us to real-
ize that we would need an initial
read record operation before the loop, followed by
another at the end of each loop. Data structure design gave us the structure or skeleton
in which we could place the elementary operations – it did not give us the fine detail.
We have now considered and used all the notations used by the data structure design
method. They are: sequence, selection, repetition and hierarchy.
>
>
SELF-TEST QUESTION
10.2 Suppose that instead of counting both males and females, the program
is only required to count males. How would the data structure diagram
be different?
So far we have just looked at programs that process a single input or a single output
stream. Now we turn to the more common situation of multiple streams. The method
is basically the same, except that we will have to describe all of the streams and make

the program structure reflect them all.
The basic principle, as always with the data structure design method, is that the pro-
gram structure should reflect the structures of all the input and output streams. So we
draw a data structure diagram for each input and output file and then devise a program
structure that incorporates all aspects of all of the data structure diagrams.
10.4 ● Multiple input and output streams
BELL_C10.QXD 1/30/05 4:22 PM Page 127