<ch23 toc ch25>

24 Data flow diagrams

24.1 Purpose
24.2 Strengths, weaknesses, and limitations
24.3 Inputs and related ideas
24.4 Concepts
24.4.1 Data flow diagram symbols
24.4.2 Conventions
24.4.3 Underlying principles
24.4.4 The context (level 0) diagram
24.4.5 The level 1 data flow diagram
24.4.6 Documenting the model
24.4.7 Verifying the model
24.4.8 Exploding the processes
24.4.9 Functional primatives
24.4.10 The configuration item level
24.4.11 The complete logical model
24.4.12 Logical and physical data flow diagrams
24.5 Key terms
24.6 Software
24.7 References
24.1 Purpose
A data flow diagram is a logical model of the flow of data through a system that
shows how the system s boundaries, processes, and data entities are logically rel
ated.
24.2 Strengths, weaknesses, and limitations
A data flow diagram is an excellent tool for summarizing and organizing detailed
information about a system s boundaries, processes, and data entities, providing
the analyst with a logical map of the system. Documenting the system s boundaries
by drawing a context diagram helps the analyst, the user, and the responsible ma
nagers visualize alternative high-level logical system designs. The elements of
a data flow diagram lead directly into physical design, with processes suggestin
g programs and procedures, data flows suggesting composites, and data stores sug
gesting data entities, files, and databases.
Creating a data flow diagram is a process driven task. Consequently, it is relat
ively easy to overlook key data elements and composites. Balancing a data flow d
iagram verifies the model s internal consistency, but does not necessarily reveal
missing elements. Attempting to balance a significant logical model without appr
opriate software (such as CASE software) is at best difficult and can be mislead
ing. Beginners and users often confuse data flow diagrams with process flowchart
s.
24.3 Inputs and related ideas
The first step in creating a data flow diagram is to prepare a list of the syste
m s boundaries, data, and processes using the tools covered in Part II. Data flow
diagrams are a significant part of the structured analysis and design methodolog
y (# 3). A data flow diagram is sometimes created in conjunction with an entity-
relationship diagram (# 26) or data normalization (# 28). Processes are document
ed using one or more of the process description tools in Part VI (#s 55 through
60). The data elements and data composites are documented in the data dictionary
(# 25). The data flow diagram is sometimes included in the requirements specifi
cation (# 35). A completed data flow is required by the automation boundaries te
chnique described in # 36.
24.4 Concepts
A data flow diagram is a logical model that shows the flow of data through a sys
tem.
24.4.1 Data flow diagram symbols

Figure 24.1 Using Gane and Sarson s notation,4 four primary symbols are used t
o create a data flow diagram (Figure 24.1). A source or destination (sink) is re
presented by a (shaded) square. Sources and destinations define the system s bound
aries; each one represents a person, organization, or other system that supplies
data to the system, gets data from the system, or both. A process, or transform
, (a round-cornered rectangle) identifies an activity that changes, moves, or ot
herwise transforms data. A data store (an open-ended, horizontal rectangle) repr
esents data at rest and implies that the data are held (for some logical reason)
between processes. A data flow (an arrow) represents data in motion. Additional
ly, Gane and Sarson use thick arrows to show physical or material flows.
Using Yourdon7 and DeMarco s2 notation, sources and sinks are represented as recta
ngles, processes as circles, and data stores as horizontal rectangles open at bo
th ends (two parallel horizontal lines). Data flows are shown as arrows. There i
s no symbol for a material flow.
24.4.2 Conventions
The following conventions are used.
24.4.2.1 Legal and illegal data flows
All data flows must begin and/or end with a process (Figure 24.2). Data cannot l
egally flow directly from a source to a destination or between a source/destinat
ion and a data store unless they pass through an intermediate process.
Figure 24.2 All data flows must begin and/or end with a process.
24.4.2.2 Data flow lines
Multiple data flows between two components can be shown by two data flow lines o
r by a two-headed arrow. Some analysts use two flow lines when the input and out
put data flows are different and a single two-headed arrow when they are the sam
e. For example, a process that gets data from a store, updates the data, and the
n sends the same data elements back to the store calls for a two-headed arrow.
24.4.2.3 Naming
A process name consists of a verb followed by a noun. By convention, the names o
f the sources, destinations, and data stores are capitalized, while process name
s and data flows are shown mixed case.
24.4.2.4 Numbering
By convention, the processes in a level 1 data flow diagram are numbered 1, 2, 3
, and so on. The numbers do not imply sequence; they are for reference only.
The sub-processes in an exploded data flow diagram are assigned numbers starting
with the parent process s number. For example, level 1 process 4 might be explode
d into level 2 processes 4.1, 4.2, 4.3, and so on, while level 2 process 4.3 mig
ht be decomposed into level 3 processes 4.3.1, 4.3.2, 4.3.3, and so on.
Many analysts use the letter D followed by a number to identify the data stores.
For example, in an inventory system, INVENTORY might be D1, SALES might be D2,
and so on. Some analysts identify the sources and destinations as well.
24.4.2.5 Duplicate symbols
Symbols can be repeated if doing so makes the diagram easier to read. For exampl
e, duplicating a symbol might be clearer than drawing lengthy or crossing data f
lows. Duplicate symbols are usually marked in some way; for example, source/dest
inations might be marked with a slash in the lower-left corner and data stores m
ight be marked with an extra vertical line.
24.4.3 Underlying principles
Two general principles guide the creation of a data flow diagram: the principle
of data conservation and the principle of iteration.
24.4.3.1 The principle of data conservation
There are no miracles, and there are no black holes. A given process can neither
lose nor create data. Any data that flow into a process must be used by or outp
ut by that process. Any data output by a process must be input to or created by
an algorithm within that process. Except for constants, any data used by an algo
rithm within a process must first flow into the process. Finally, any data creat
ed by an algorithm must either be used by another algorithm within the same proc
ess or output by the process.
24.4.3.2 The principle of iteration
High-level processes are decomposed into lower-level processes. At the lowest le
vel are primitive processes that perform a single function (or algorithm). Note
that a lower-level process gets its data from its higher-level parent.
24.4.4 The context (level 0) diagram
A context (level 0) diagram documents the system s boundaries by highlighting its
sources and destinations. Documenting the system s boundaries by drawing a context
diagram helps the analyst, the user, and the responsible managers visualize alt
ernative high-level logical system designs.
For example, Figure 24.3 shows a context diagram for a typical inventory system.
The system itself is shown as a single process. It provides data to the FINANCI
AL SYSTEM. It both provides data to and gets data from MANAGER, SUPPLIER, and CU
STOMER. Note that the data flows are labeled with (at this level) composite name
s.
Moving the boundaries significantly changes the system, and the ability to visua
lize the implications of different boundary assumptions is a powerful reason for
creating a context diagram. For example, in Figure 24.3 the financial system an
d the inventory system are independent. An alternative logical design might move
the financial system inside the inventory system (or vice versa), effectively i
ntegrating them. The result would be a somewhat more complex (but perhaps more e
fficient) system.
Figure 24.3 A context diagram.
24.4.5 The level 1 data flow diagram
A level 1 data flow diagram shows the system s primary processes, data stores, sou
rces, and destinations linked by data flows. Generally, a system s primary process
es are independent, and thus, separated from each other by intermediate data sto
res that suggest the data are held in some way between processes.
For example, Figure 24.4 shows a level 1 data flow diagram for an inventory syst
em. Start at the upper left with source/destination FINANCIAL SYSTEM. Data flow
to FINANCIAL SYSTEM from process 9, Report cash flow. Data enter process 9 from
data store D1, SALES. Data enter D1 from process 2, Sell appliance. Process 2 ge
ts its data from CUSTOMER and from data stores D1, D3, D5, and D6, and so on. No
te how intermediate data stores serve to insulate the primary processes from eac
h other and thus promote process independence.
A level 1 process is a composite item that might incorporate related programs, r
outines, manual procedures, hardware-based procedures, and other activities. For
example, process 2, Sell appliance might imply (in one alternative) a set of sa
les associate s guidelines, while another alternative might include a point-of-sal
e terminal equipped with a bar code scanner and necessary support software. In e
ffect, the level 1 process Sell appliance represents all the hardware, software,
and procedures associated with selling an appliance. As the data flow diagram i
s decomposed, the various sub-processes are eventually isolated and defined.
24.4.6 Documenting the model
The data flow diagram shows the data flows between the system s sources, destinati
ons, processes, and data stores.
24.4.6.1 The data dictionary
The data elements are recorded in the data dictionary (# 25). As work progresses
, the data elements that occupy the same data store or share a data flow form co
mposite items or data structures that are also documented in the data dictionary
. For example, Supplier name, Supplier address, Description, Reorder quantity an
d other data elements flow to SUPPLIER from process 4 and form a data structure
that might be called Reorder.
Figure 24.4 A level 1 data flow diagram.
24.4.6.2 Process descriptions
Each process is defined in a process description that notes its input and output
data elements and composites and briefly describes the tasks or activities it p
erforms. (Process description tools are described in Part VI.) Process (or data
transform) descriptions are sometimes recorded in the data dictionary.
24.4.6.3 The CASE repository
In most CASE products (# 5), the data descriptions and process descriptions are
stored in the CASE repository.
24.4.7 Verifying the model
The point of verification is to ensure that the model is complete and internally
consistent.
24.4.7.1 Syntax checking
Every data flow must begin and/or end with a process and have at least one arrow
head to define the direction of data movement. Every process and every data stor
e must have at least one input data flow and at least one output data flow. If t
he inflow is missing, the source of the data is unknown. If the outflow is missi
ng, that process or store acts like a black hole. In either case, something is w
rong.
Other syntax checks involve judgement. Process names should imply their function
. Component names should be unique because redundant names are confusing.
24.4.7.2 Tracing data elements
Following the principle of data conservation, each data element in a level 1 dat
a flow diagram must be rigorously traced from its destination, through the model
, back to its source. If the source of every data element is accounted for, the
data flow diagram is internally consistent.
24.4.7.3 Cross referencing
On the data flow diagram, each data element, data store, and data flow must appe
ar in the data dictionary, and each process must have a matching process descrip
tion.
In the data dictionary, each logical data structure must match a data flow or a
data store, and each data element must appear at least once on the data flow dia
gram. Additionally, each data element and each logical data structure must appea
r in the input or output list of at least one process description. There are two
possible explanations for unused data elements: Either they are not needed by t
he system, or the analyst overlooked them.
Each process description must match a process on the data flow diagram, and the
input and output lists must match the data flows. Every data element entering or
leaving a process must appear in the data dictionary. Unused processes may have
been overlooked when the data flow diagram was created. If not, they are unnece
ssary.
24.4.7.4 Tracing objectives
Note that if a significant feature of the system was overlooked, verification wi
ll not necessarily find the error. Consequently, the logical model should always
be checked against the system objectives and the process or processes that cont
ribute to meeting each one identified. If an objective cannot be matched with at
least one process, that objective may have been overlooked. If a process cannot
be matched with at least one objective, that process might be unnecessary.
24.4.8 Exploding the processes
A level 1 data flow diagram is a high-level logical map of the system. It shows
the key relationships but hides most of the details. Consequently, the next step
is to explode the processes by taking advantage of the principle of iteration.
The act of exploding a data flow diagram is sometimes called functional decompos
ition.
24.4.8.1 Level 2
Each level 1 process consists of several sub-processes that are listed on the pr
ocess description. To explode the data flow diagram, the analyst creates an inde
pendent level 2 data flow diagram for each level 1 process.
For example, Figure 24.5 shows a level 2 data flow diagram for process 4, Reorde
r stock (Figure 24.4). Note the numbering scheme. Processes 4.1, 4.2, 4.3, 4.4,
and 4.5 are sub-processes of level 1 process 4.
Figure 24.5 A level 2 data flow diagram for process 4.
24.4.8.2 Local and global data
Global data are shared by two or more higher level processes. Local data are kno
wn only within one part of the system; intermediate computations are a good exam
ple. For example, in Figure 24.5, the data elements in data store D7, REORDER DA
TA are known only within the level 2 explosion of process 4 (and its sub-process
es).
Mistakes made while working with local data tend to be limited in scope, but glo
bal data errors can ripple throughout the system. Local data elements should be
recorded in the data dictionary and identified as local. If they already exist,
they might not be local; perhaps a global data element was overlooked.
24.4.8.3 Balancing the level 2 explosion
An exploded data flow diagram must be balanced by accounting for each input from
the parent level and each output to the parent level. Checking to ensure that a
n explosion is balanced is similar to tracing data elements from their destinati
on (output) back to their source (input). The only difference is that the higher
-level process s outputs are traced back to the higher-level process s inputs throug
h the exploded data flow diagram.
Every global data element (or composite) input to the lower level must be used b
y at least one lower-level sub-process. Every global data element (or composite)
output to the higher level must either be input to the lower level or generated
by an algorithm within a lower-level sub-process. Each data element or composit
e input to or used by an exploded process must be defined in the higher-level pr
ocess.
Note that a higher-level composite might be decomposed into data elements or sub
-composites at the lower level. Local data (by definition) are neither input to
nor output from the explosion.
24.4.9 Functional primatives
A functional primitive is a process (or transform) that requires no further deco
mposition. The process description for a functional primitive is sometimes calle
d a mini-spec. The system s discrete physical components lie one step below a func
tional primitive.
24.4.10 The configuration item level
The functional primitives and the data stores that appear at the lowest level of
decomposition are called configuration items. A configuration item is a composi
te rather than a specific physical component; for example, a composite item migh
t represent a program and the computer on which it runs, or a database and the d
evice on which it resides. In a complete logical model, all the processes are de
composed down to the configuration item level, an imaginary line that links the
system s configuration items.
24.4.11 The complete logical model
A logical model consists of a complete set of balanced data flow diagrams, a dat
a dictionary, and one process description for each process at each level down to
the configuration item level. Note that some processes will be exploded only to
level 2, others to level 3, and so on, so the configuration item level does not
necessarily correspond to a single, consistent data flow diagram level.
The documentation package for a large system can be quite lengthy. Processes abo
ve the configuration item level are purely logical; their process descriptions c
onsist of little more than lists of sub-processes. Those sub-processes can be ob
tained from the exploded data flow diagram, so some organizations exclude them f
rom the finished model process descriptions above the configuration item level.
The configuration item level processes will decompose into the system s programs a
nd procedures. The data stores will map into files and databases. The data flows
will become reports, screens, forms, and dialogues. Above the configuration ite
m level, the logical relationships between the components support planning, coor
dination, and control.
24.4.12 Logical and physical data flow diagrams
A logical data flow diagram s symbols are used to describe logical not physical en
tities. A process might eventually be implemented as a computer program, a subro
utine, or a manual procedure. A data store might represent a database, a file, a
book, a folder in a filing cabinet, or even notes on a sheet of paper. Data flo
ws show how the data move between the system s components, but they do not show th
e flow of control. The idea is to create a logical model that focuses on what th
e system does while disregarding the physical details of how it works.
A physical data flow diagram uses data flow diagram symbols to represent the sys
tem s physical processes (programs, manual procedures) and physical data stores (f
iles, databases, reports, screens, etc.) and shows how the system works. Some an
alysts like to start the analysis process by preparing a physical data flow diag
ram of the present system. Following the analysis stage, physical data flow diag
rams can be used to document alternative solutions.
24.5 Key terms
Balance
A characteristic of an exploded data flow diagram in which each input from a
nd output to the parent level is accounted for.
Composite
A set of related data elements; a data structure.
Configuration item
A functional primitive that appears at the lowest level of decomposition.
Configuration item level
An imaginary line that links the system s configuration items.
Context diagram (level 0 data flow diagram)
A data flow diagram that documents the system s boundaries by highlighting its
sources and destinations.
Data flow
Data in motion.
Data flow diagram
A logical model of the flow of data through a system.
Data store
Data at rest; implies that the data are held between processes.
Data structure
A set of related data elements; a composite.
Destination (sink)
A person, organization, or other system that gets data from the target syste
m; a destination defines a system boundary.
Explode
To decompose a process in a data flow diagram to a lower level.
Functional decomposition
The act of exploding a data flow diagram.
Functional primitive
A process (or transform) that requires no further decomposition.
Global data
Data elements or composites that are shared by two or more processes.
Level 1 data flow diagram
A data flow diagram that shows the system s primary processes, data stores, so
urces, and destinations linked by data flows.
Level 2 data flow diagram
An explosion of a level 1 process.
Local data
Data elements or composites that are known only within one part of the syste
m.
Logical data flow diagram
A data flow diagram that does not suggest physical references but shows the
system s components as logical entities.
Mini-spec
The process description for a functional primitive.
Physical data flow diagram
A data flow diagram that identifies the system s physical processes and physic
al data stores.
Process (transform)
An activity that changes, moves, or otherwise transforms data.
Source
A person, organization, or other system that supplies data to the target sys
tem; a source defines a system boundary.
24.6 Software
Many CASE products support creating, modifying, maintaining, and balancing data
flow diagrams. Charting programs, such as Visio and Micrografx s Flowcharter can b
e used to create data flow diagrams. The data flow diagrams in this # were creat
ed using Visio.
24.7 References
1. Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont,
CA, 1994.
2. DeMarco, T., Structured Analysis and System Specification, Yourdon, New
York, 1978.
3. Gane, C., Rapid System Development, Rapid System Development, New York,
1987.
4. Gane, C. and Sarson, T., Structured Systems Analysis: Tools and Techniqu
es, Prentice-Hall, Englewood Cliffs, NJ, 1979.
5. Martin, J. and McClure, C., Diagramming Techniques for Analysts and Prog
rammers, Prentice-Hall, Englewood Cliffs, NJ, 1985.
6. Thayer, R. H. and Dorfman, M., System and Software Requirements Engineer
ing, IEEE Computer Society Press, Los Alamitos, CA, 1990.
7. Yourdon, E. and Constantine, L. L., Structured Design, Prentice-Hall, En
glewood Cliffs, NJ, 1979.
<ch23 toc ch25>