Data flow design depends on identifying the flows of data through the intend-ed software, together with the transformations on the flows of data.. 112 Chapter 9■ Data flow designThe outp
Trang 1Alternative solutions
A major characteristic of functional decomposition is its flexibility, or (put another way) its lack of guidance When you use the method you do not necessarily arrive at a unique solution On the contrary, you can often see several solutions According to functional decomposition they are all reasonable The method gives us no guidance as to which design is best The only way to find out is to refine all the solutions to a level of detail
at which we can make a reasoned choice between them The choice might be made on the basis of clarity and simplicity, performance or some other criteria, but functional decomposition, by itself, gives no guidance for selecting the best solution
Because there is always more than one solution to a problem – more than one design that meets the specification – the user of functional decomposition is duty bound to find not just one solution, but to find the best solution The criteria for the “best” solution will differ from program to program – sometimes it will be maximum clarity, sometimes
it will be optimum performance If in pursuing one design it turns out to be unsatis-factory, we can retrace the design level by level, considering alternatives at each level It will often prove desirable to replace whole subtrees in this manner This process is
large-ly under control because we know which part of the structure we are looking at, and it has only one entry and exit point
Review
Arguably functional decomposition was the first truly systematic method for software design It is associated with the names Dijkstra and Wirth It evolved hand-in-hand with the ideas of structured programming in the 1960s Since then other methods that claim
to involve structured programming have been devised, so that nowadays functional decomposition is just one variety of structured programming
There is sometimes confusion about the terminology surrounding structured pro-gramming and top-down methods Let us try to clarify the situation Functional decom-position is a top-down method, since it starts with an overall task of the software, but
it is not unique in this respect Functional decomposition is also called stepwise refine-ment, though it is, of course, refinement of function.
Functional decomposition concentrates almost exclusively on defining the functions (the actions) that software must take The flexibility of functional decomposition means that it can be used in the design of software for any type of application; it is generally applicable But because it concentrates on the actions that the software has to take, it is perhaps most useful for problems in which the procedural steps are clearly evident One such area is numerical computation, like a program to calculate a square root Another
is the control of a sequential process, like a washing machine
Functional decomposition can be used either to design the detailed, low-level struc-ture of a program It can also be used to design the high-level or architectural strucstruc-ture
of software Thus it is applicable to both small- and large-scale software
Functional decomposition assumes that the structure of software must be a collection
of hierarchies (trees), one for each top-level function or use case This distinguishes it from other approaches
If we want a completely well-defined method that we can use almost without think-ing, then functional decomposition is inadequate, since its use requires considerable
108 Chapter 8■ Functional decomposition
Trang 2Exercises 109
Exercises
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 pro-grammer 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 ifstatements or with whilestatements 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
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
function-al decomposition exhibit them?
•
Trang 3110 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;
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.
Further reading
•
Trang 4Data flow design is a method for carrying out the architectural (large-scale) design of software Data flow design depends on identifying the flows of data through the
intend-ed software, together with the transformations on the flows of data The method leads from a specification of the software to a large-scale structure for the software expressed
in terms of:
■ the constituent components of the software
■ the interrelationships between the components
What is a component? A component is a collection of lines of code, usually involv-ing variables (descriptions of data) and actions A component is usually self-contained;
it is somewhat separate from any other component or components A component is called from some other component and, similarly, calls other components Programming languages (nearly) always provide facilities for modularity – such fea-tures as methods, classes and packages Ideally, a component is as independent as it can be One of the goals of software design is to create software structures in which all of the components are as independent as possible Chapter 6 discusses various gen-eral aspects of modularity
We begin exploring data flow design method using an analogy Suppose a chef works
in a kitchen all day preparing plates of spaghetti bolognese The principal inputs to the system are:
■ spaghetti
■ meat
9.1 ● Introduction
CHAPTER
design
This chapter explains:
■ how to use the data flow design method
■ the principles behind the method
Trang 5112 Chapter 9■ Data flow design
The output from the system is:
■ plates of spaghetti bolognese
We can draw a diagram (Figure 9.1) to describe what is to happen in the kitchen
In essence, data flows into the system, is transformed by actions (functions) and data then flows out of the system
The diagram is called a data flow diagram Each line with an arrow on it represents
a stream of data flowing through the system In this example there are three – spaghetti, meat and plates of spaghetti bolognese Each bubble represents a transformation, an activity or a process that converts an input flow into an output flow In this example there is only one transformation – prepare food Note that the diagram shows data flows (which are dynamic), and does not show files (which are static objects)
We can now explore the detail that lies within the single bubble We redraw it as Figure 9.2 so as to show more clearly the steps that are involved
prepare food spaghetti
meat
plates of spaghetti bolognese
Figure 9.1 Data flow diagram for making spaghetti bolognese
serve boil
fry
plates of spaghetti bolognese
meat
spaghetti
boiled spaghetti
fried meat
Figure 9.2 More detailed data flow diagram for making spaghetti bolognese
Trang 69.2 Identifying data flows 113
Notice again the essential components – data flows (lines) and functions (bubbles) Each line is labeled to describe exactly what data it is Each bubble is labeled with a verb
to describe what it does
We could go on redrawing our data flow diagram for the chef in the kitchen, adding more and more detail There are, for example, other ingredients, like tomatoes
to consider (data flows) and more detailed actions (bubbles), such as mixing in the various ingredients
We started with a single, high-level diagram in which all the detail was hidden We end with a richer, more detailed diagram in which the components of the system (and their interrelationships) are revealed In a computer system, the bubbles correspond to the software components We have created a design for the kitchen system expressed in terms of components and the flows of data between the components
We will use as a case study the design of software to monitor a patient in a hospital The specification (Appendix A) for the software is:
A computer system monitors the vital signs of a patient in a hospital Sensors attached
to a patient send information continually to the computer:
■ heart rate
■ temperature
■ blood pressure Some of the readings require conversion to useful units of measurement (e.g micro volts into degrees centigrade) The computer displays the information on a screen It also logs the information in a file that can be retrieved and displayed If any of the vital signs exceeds safe limits, the screen flashes a warning and an alarm sounds The limits have default values, but can also be changed by the operator If a sensor fails, the screen flashes
a warning and the alarm sounds.
The data flow diagram of the major data flow for this software is shown in Figure 9.3
It is straightforward to draw this diagram simply by reading the specification closely and picking out the functional steps that need to be carried out
This diagram also shows some data stores These are drawn as open boxes and rep-resent files or databases The difference between a data store and a data flow is that a data store is static (it does not move)
Drawing the data flow diagram for a proposed piece of software is a vital step in the method How do we do it? There are three alternative approaches
Method 1 is to start with a single bubble like Figure 9.4 that shows the overall func-tion of the software and its input and output data flows We then refine the bubble, or break it down, into a set of smaller bubbles like Figure 9.5 We continue redrawing bubbles as sets of smaller ones until we can’t do it any more
In method 2 we start with the output data flow from the system and try to identify the final transformation that has to be done to it Then we try to identify the transformation before that, and so on, until we have a complete diagram
9.2 ● Identifying data flows
Trang 7114 Chapter 9■ Data flow design
read data
convert
check
display message
message
data
safe limits
status information
converted data
raw data
conversion factors
Figure 9.3 Data flow diagram for patient monitoring software
overall function
output data flow
input data flow
Figure 9.4 Initial data flow diagram
function A
function B
output data flow
data flow input
data flow
Figure 9.5 Refined data flow diagram
Trang 89.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 out-put 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
A
Figure 9.6 Structure chart in which component A calls B and C
SELF-TEST QUESTION
9.1 The data flow for the log file is omitted from the above data flow diagram
Add this data flow
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 struc-ture 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
9.3 ● Creation of a structure chart
Trang 9116 Chapter 9■ Data flow design
central and most important bubble is the checkbubble 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 checkcomponent calls the convertcomponent which in turn calls the read datacomponent 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 dia-grams, 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 architec-tural design
check
display message convert
read data
Figure 9.7 Structure chart for patient monitoring software
Trang 109.4 Discussion 117
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 cre-ate 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
9.4 ● Discussion
SELF-TEST QUESTION
9.2 Enhance the structure chart for the patient monitoring software so as to show the logging
Process
Input Output
Figure 9.8 Idealized structure for software