Data Flow Diagrams

12.4.1 Data Flow Diagrams

As information moves through software, it is modified by a series of transformations.

A data flow diagram is a graphical representation that depicts information flow and The DFD provides a

the transforms that are applied as data move from input to output. The basic form mechanism for

of a data flow diagram, also known as a data flow graph or a bubble chart, is illus- information flow

trated in Figure 12.10. modeling and

The data flow diagram may be used to represent a system or software at any level functional modeling.

of abstraction. In fact, DFDs may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. In so doing, it satisfies the second operational analysis principle (i.e., creating a functional model) discussed in Chapter 11.

A level 0 DFD, also called a fundamental system model or a context model, repre- sents the entire software element as a single bubble with input and output data indi- cated by incoming and outgoing arrows, respectively. Additional processes (bubbles)

Refinement from one and information flow paths are represented as the level 0 DFD is partitioned to reveal DFD level to the next

more detail. For example, a level 1 DFD might contain five or six bubbles with inter- should follow an

connecting arrows. Each of the processes represented at level 1 is a subfunction of approximate 1:5 ratio,

reducing as the the overall system depicted in the context model. refinement proceeds.

As we noted earlier, each of the bubbles may be refined or layered to depict more detail. Figure 12.11 illustrates this concept. A fundamental model for system F indi- cates the primary input is A and ultimate output is B. We refine the F model into trans-

forms f 1 to f 7 . Note that information flow continuity must be maintained; that is, input

F I G U R E 12.11

Information flow

refinement

PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

and output to each refinement must remain the same. This concept, sometimes called balancing, is essential for the development of consistent models. Further refinement of f depicts detail in the form of transforms f to f . Again, the input (X, Y) and out-

Although information

flow continuity must put (Z) remain unchanged.

be maintained, The basic notation used to develop a DFD is not in itself sufficient to describe recognize that a data

requirements for software. For example, an arrow shown in a DFD represents a data item represented at

object that is input to or output from a process. A data store represents some orga- one level may be

refined into its nized collection of data. But what is the content of the data implied by the arrow or constituent parts at the depicted by the store? If the arrow (or the store) represents a collection of objects,

next level. what are they? These questions are answered by applying another component of the basic notation for structured analysis—the data dictionary. The use of the data dic- tionary is discussed later in this chapter.

DFD graphical notation must be augmented with descriptive text. A process spec- ification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD. The process specification describes the input to a function, the algo- rithm that is applied to transform the input, and the output that is produced. In addi- tion, the PSPEC indicates restrictions and limitations imposed on the process (function), performance characteristics that are relevant to the process, and design constraints that may influence the way in which the process will be implemented.