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 . 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),. 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. 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