Reference Document 1
Process Modeling (Data Flow Diagrams)
The Data Flow Diagram (DFD) is one of the most commonly used techniques available
for process modeling. By emphasizing the logic underlying the system, the use of DFDs
allows a system analyst to create a graphical representation that capture, manipulate,
store and distribute data between a system and its environment and among system
components.
Data flow diagrams graphically illustrate movement of data between external entities
and the processes and data stores within a system.
Advantages of the Data Flow Approach
The data flow approach has four main advantages over the narrative explanation of data
movement in the system.
Freedom from committing the technical implementation of the system too early.
Further understanding of the interrelatedness of systems and subsystems.
Communicating current system knowledge efficiently to users through data flow
diagrams.
Detail analysis of a proposed system to determine if the necessary data and
processes have been defined.
Syntaxes used in Data Flow Diagram
There are two commonly used styles of symbols, one set developed by Chris Gane and
Trish Sarson and the other by Tom DeMarco and Ed Yourdan. Neither is better than the
other.
Gane and
Meaning
Examples
Sarson
Symbol
Process:
3.1
A process means that some action or group of actions takes
place.
Create
Student
Record
Entity:
An entity is a person, a group, a department, or any system
that either receives of originates information or data.
Data Flow:
A data flow which shows that information is being passed
from or to a process.
Student
New Student
Information
Data Store:
A data store is a collection of data that is stored in some
way.
D5
Student
Master
Figure 7.1 The four basic symbols used in data flow diagrams, their meanings, and examples
CSA505 Computer Project
Reference 1
Page 1
Entity/Source/Sink:
-
-
A square is used for representing an external entity  people who use the
information from the system to perform other processes or people who decide what
information should go into the system or people who receive any information from
the system.
An external entity is external to the system but may or may not be part of the
organization.
Entities should be named with a noun.
The same entity may be used more than once on a given data flow diagram to avoid
crossing data flow lines.
Do not represent people who are part of the system as external entities as people
who execute a process are part of the process itself and are not external to the
system (e.g. data-entry clerks, order takers).
Data flow:
-
An arrow is used for indicating data movement from one place to another in the
system.
An arrow should be described with a noun with a meaningful name to represent the
data.
It could be a data element (e.g. patient name), or a logical collection of several
pieces of information (e.g. patient information).
A data flow to a data store means update, delete or change.
A data flow from a data store means get or use.
Process:
-
A rectangle with rounded corners for the occurrence of transforming process.
It is a work or a action or an activity or a function that performed on data so that
they are transformed, stored or distributed.
Processes can be manual or computerized.
A unique identifying number should be given to the process, which indicates its level
within the diagram.
Data flow leaving a process is always labeled differently from the one entering it.
Each process has a name that starts with a verb and ends with a noun (e.g. “Find
Patient”, “Update Patient”).
Names should be short and contain enough information so that reader can easily
understand exactly what they do.
Each process performs only one activity. Therefore, avoid using the word “and” in
process names.
Each process must create at least one output data flow because if there is no output,
the process does not do anything.
Data store:
-
An open-ended rectangle for a data store.
It shows a depository for data that allows addition and retrieval of data.
Every data store has a descriptive name (i.e. a noun).
A unique reference number (e.g. D1, D2…).
Temporary data store, (e.g. scratch paper / a temporary computer file) are not
included on the DFD.
All data stores must have at least one input data flow and one output data flow.
CSA505 Computer Project
Reference 1
Page 2
Relationships among Different Levels of Data Flow Diagrams (DFDs)
Context Level Diagram
0
X
Entity
A
Entity
B
Z
Information
System
Y
Diagram 0 DFD
1
X
Entity
A
Entity
B
Process T
B
Z
Y
2
D1
N
Data Store N
3
Process U
A
Process V
N
Child Diagram DFD
for Process 2
2.1
B
J
Process D
H
2.2
N
D1
Data Store N
Child Diagram DFD
For Process 2.2
H
N
A
2.3
G
Process E
Process F
Y
2.2.1
Process K
Q
2.2.3
R
H
2.2.2
S
Process M
N
Process L
G
D1
N
Data Store N
Figure 7.2 Relationships among levels of data flow diagrams
CSA505 Computer Project
Reference 1
Page 3
Creating the Context diagram
-
-
This DFD of the scope of an organizational system that shows the system
boundaries, external entities that interact with the system and the major
information flows between the entities and the system.
It is the highest level in a data flow diagram and contains only one process
representing the whole system.
The process is given the number zero.
It does not contain any data stores.
Drawing Diagram 0/ Level 0 (The Next Level)
-
More detail than the context diagram
Inputs and outputs specified in the first diagram remain constant in all subsequent
diagrams.
The rest of the original diagram is exploded into three to nine processes showing
data stores and new lower-level data flows.
Each exploded diagram should use only a single sheet of paper.
It starts from the upper left-hand corner of the diagram and extends to the lower
right-hand corner.
The major data stores of the system (representing master files) and all external
entities are included on Diagram 0.
These are some suggestions you could follow when you draw a DFD:
• Start with the data flow from an entity on the input side.
• Work backwards from an output data flow.
• Examine the data flow to or from a data store.
• Analyze a well-define process.
• Take note of any confuse areas where you are unsure of what should be included
or of what input or output is required.
Figure 7.3 Context diagrams (above) can be “exploded” into Diagram 0 (below).
greater detail in Diagram 0.
CSA505 Computer Project
Reference 1
Note the
Page 4
Creating Child Diagrams (More Detailed Levels)
-
-
The process on Diagram 0 that is exploded is called the parent process, and the
diagram resulting from this process is called the child diagram.
The primary rule for creating child diagrams (vertical balancing) is that a child
diagram cannot produce output or receive input that the parent process does not
also produce or receive.
All data flow into or out of the parent process must be shown flowing into or out of
the child diagram.
The child diagram is given the same number as its parent process in Diagram 0.
Entities are usually not shown on the child diagrams below Diagram 0.
Processes may or may not be exploded, depending on their level of complexity.
Figure 7.4 Differences between the parent diagram (above) and the child diagram (below).
Rules for Drawing the Data Flow Diagrams
The conditions are errors that occur when drawing a data flow diagram:
-
-
Forgetting to include a data flow or pointing an arrowhead in the wrong direction.
Incorrectly labeling data flow or objects. Examples are:
• Labels omitted from data flow or objects.
• Data flow labeled with a verb.
• Processes labeled with a noun.
Including more than nine processes on a data flow diagram.
Omitting data flow from the diagram. (i.e. A process has only one input data flow
and only one output data flow.)
Creating unbalanced decomposition in child diagrams. The data flow in and out of a
parent process must be present on the child diagram.
CSA505 Computer Project
Reference 1
Page 5
Analysts should follow the following rules when drawing data flow diagrams:
Rules
Incorrect
Entity:
Data cannot connect directly from an
entity to another one. All data flows
must EITHER originate OR terminate at
a process. Otherwise, the data flow is
not shown on the DFD.
Data Store:
Data store cannot connect directly from
one data store to another one. Data
must be moved by a process.
Data store cannot connect directly from
one entity to a data store and vise
versa.
Data must be received/
processed by a process and stored it
into the data store.
Process:
No process can have only inputs. If an
object has only inputs, then it must be
an entity.
No process can have only outputs. If an
object has only outputs, then it must be
an entity.
Data Flow:
Each data flow should have only one
direction of flow between symbols.
If there is a data flow showing read and
update data between a process and a
data store, two data flows should be
used in this case.
If there is a data flow spiting into two,
there should be exactly the same data
goes to two or more entities, data
stores or processes.
-
A
B
If there are two or more data flows
joining into one, there should be exactly
the same data produced from two or
more entities, data stores or processes
to the same destination.
C
D
Figure 7.5 Incorrect ways to draw data flow diagrams
Here is a payroll example data flow diagram with typical errors:
CSA505 Computer Project
Reference 1
Page 6
Figure 7.6 Typical errors that can occur in a data flow diagram (payroll example).
This is the correct payroll example data flow diagram:
Figure 7.7 The correct data flow diagram for the payroll example.
CSA505 Computer Project
Reference 1
Page 7
Different Types of Data Flow Diagrams
Data Flow diagrams can be categorized to either logical or physical types.
A logical data flow diagram focuses on the business and how the business operates.
A physical data flow diagram shows how the system will be implemented, including
the hardware, software, files, and people involved in the system.
Figure 7.10 The physical data flow diagram (below) shows certain details not found on the
logical data flow diagram (above).
CSA505 Computer Project
Reference 1
Page 8