Data Flow Diagrams (DFD)

Key Definitions
• A process model is a formal way of
representing how a business operates
• Data flow diagramming shows business
processes and the data that flows between
them
 Key Definitions
• Logical process models describe
processes without suggesting how they
are conducted
• Physical models include information about
how the processes are implemented
 Key Definition
• Decomposition is the process of modeling
the system and its components in
increasing levels of detail.
• Balancing involves insuring that
information presented at one level of a
DFD is accurately represented in the next
level DFD.
 What are data-flow diagrams?
• Data-flow diagrams (DFDs) model a perspective of the system that is
most readily understood by users – the flow of information through the
system and the activities that process this information.
• Data-flow diagrams provide a graphical representation of the system that
aims to be accessible to computer specialist and non-specialist users
alike.
• The models enable software engineers, customers and users to work
together effectively during the analysis and specification of requirements.
• Although this means that our customers are required to understand the
modeling techniques and constructs, in data-flow modeling only a limited
set of constructs are used, and the rules applied are designed to be
simple and easy to follow. These same rules and constructs apply to all
data-flow diagrams (i.e., for each of the different software process
activities in which DFDs can be used).
 DFD notations
• External entities — the sources from which information flows into the
system and the recipients of information leaving the system. External
entities are notated as ovals.
• Data-flows — the data inputs to and outputs from to these activities.
Data-flows are notated as named arrows.
• Processes — the activities carried out by the system which use and
transform information. Processes are notated as rectangles.
• Data stores — where information is stored within the system. Data
stores are notated as rectangles.

• The diagrams are supplemented by supporting documentation including

a data dictionary, describing the contents of data-flows and data stores;
and process definitions, which provide detailed descriptions of the
processes identified in the data-flow diagram
 External Entities
– They could be a person, another software or a
hardware which provide to or consume
information from the intended software.
– Represented by rectangle:
• Must be named
• No direct data flow between two entities ever.

User
 External Entities
• External entities are entities outside of the system boundary
which interact with the system, in that they send information
into the system or receive information from it.
• External entities may be external to the whole organization; or
just external to the application area where users' activities are
not directly supported by the system under investigation.
• External entities are often referred to as sources and sinks.
• All information represented within the system is sourced
initially from an external entity. Data can leave the system
only via an external entity
 Rules for external entities
• Each external entity must communicate with the system in
some way, thus there is always a dataflow between an
external entity and a process within the system.
• External entities may provide and receive data from a
number of processes. It may be appropriate, for the sake of
clarity and to avoid crisscrossing of data flows, to depict the
same external entity at a number of points on the diagram.
 Data-flows
• A data-flow represents a package of information flowing
between two objects in the data-flow diagram.
• Data-flows are used to model the flow of information into the
system, out of the system, and between elements within the
system.
• Occasionally, a data-flow is used to illustrate information
flows between two external entities, which is, strictly
speaking, outside of the system boundaries. However,
knowledge of the transfer of information between external
entities can sometimes aid understanding of the system
under investigation, in which case it should be depicted on
the diagram.

A data-flow is depicted on the diagram as a directed line drawn between the source
and recipient of the data-flow, with the arrow depicting the direction of flow.
 Rules for data-flows
– The data flows should always be labeled
– The labels should be precise and informative
– You can join two similar input data flows(join)
or two similar output data flows (fork)
 Rules for data-flows
• Information always flows to or from a process; the other end
of the flow may be an external entity, a data store or another
process. An occasional exception to this rule is a data-flow
between two external entities.
• Data stores may not be directly linked by data-flows;
information is transformed from one stored state to another
via a process.
• Information may not flow directly from a data store to an
external entity, nor may it flow from an external entity directly
to a data store. This communication and receipt of information
stored in the system always takes place via a process.
 Rules for data-flows
• The sources (where data of interest to the system is
generated without any corresponding input) and sinks (where
data is swallowed up without any corresponding output) of
data-flows are always represented by external entities.
• When something significant happens to a data-flow, as a
result of a process acting on it, the label of the resulting data-
flow should reflect its transformed status. For example,
“Telephoned Service Call” becomes “Service Call Form” once
it has been logged.
 Processes
• Processes are the essential activities, carried out within the
system boundary, that use information.
• A process is represented in the model only where the
information which provides the input into the activity is
manipulated or transformed in some way, so that the data-
flowing out of the process is changed compared to that which
flowed in.
• The activity may involve capturing information about
something that the organisation is interested in.

Ticket
Booking

A circle (sometimes called a bubble) represents a process or transform that is

applied to data and changes it in some way.
 Rules for Processes
– It must not be repeated in a diagram
– Process names should be an imperative verb
specific to the activity in question, followed by a
pithy and meaningful description of the object of
the activity
– Processes may not act as data sources or sinks.
Data flowing into a process must have some
corresponding output, which is directly related to
it. Similarly, data-flowing out of a process must
have some corresponding input to which it is
directly related.
 Rules for Processes
– Normally only processes that transform system
data are shown on data-flow diagrams. Only
where an enquiry is central to the system is it
included.
– Where a process is changing data from a data
store, only the changed information flow to the
data store (and not the initial retrieval from the
data store) is shown on the diagram.
– Where a process is passing information from a
data store to an external entity or another process,
only the flow from the data store to the process is
shown on the diagram.
 Data stores
• A data store is a place where data is stored and retrieved
within the system
• This information may be stored either temporarily or
permanently by the user.
• They are internal to the system.

User info Order info

 Rules for Data stores
– Never shown in context level diagram
– No direct data flows between two data sources
– Data stores may not act as data sources or sinks.
Data flowing into a data store must have some
corresponding output, and vice versa.
– Because of their function in the storage and
retrieval of data, data stores often provide input
dataflows to receive output flows from a number of
processes.
 General rules for DFD
–No internal logic should be shown like loops, if-else, this is
not a flow chart
– In order to keep the diagram uncluttered, you can repeat
data stores and external entities
–No process can have only output data flows.
–No process can have only input data flows.
–Data cannot be moved directly from one store to another
without a process.
–Data cannot move directly from an external entity to a data
store without a process.
–Data stores can’t be sink ( only input data flows) or source
( only output data flows) in level 1 DFD
 Types of DFDs
• Context Diagram
– Main External Environment
• Level 0 Diagram
– Main focus is top-level internals
– Might be the same as the context diagram for small
projects
– Sources and Sinks need not be shown, but represent the
flow
• Level i Diagram
– Provides a higher level of detail for nodes in level i-1
– Use “Dewey decimal” notation to clarify relationships
• Node 2.3 expands to 2.3.1, 2.3.2 and so on
 Context Level Diagram
• A level 0 DFD, also called a fundamental
system model or a context model.
• It represents the entire software element as a
single process with input and output data.
• All the external entities should be identified
and shown.
• Rule:
– Only one process
– Data flows should be labeled.
– No data store can be shown in context diagram
 Course Registration System
Context Diagram for Course Registration System

Courses & other info.

Faculty Students

Registration
Process
Class schedule
Class list

Registrar
 Level 1 DFD
• The level 1 DFD we construct is a more refined
version of the context diagram.
• It covers the entire system, all the main processes
are shown
• The DFD should be balanced with respect to
context diagram
– No new external entities should be there
– The data flows from context diagrams should be
visible
• Rules:
– It should consists of 5-9 processes(bubbles).
– Repetition of data sources is allowed.
– Process can not be repeated.
 DFD: Course Registration System
Level 1 DFD
Students

Courses & Individual Course

Other info. Registration
Information

1. Enroll 2. Compile &

Students Distribute
Information

Schedules Registrar
Class Lists

Students Faculty

Note: External entity Students is replicated to avoid crossing lines

 Level 2 DFD
• Only those processes that merit being
expanded need to have level 2 DFDs .
• Level 2 DFD completely describes any one
process from the level 1 DFD.
• Rules:
– All the data flows into and out of selected
process on the level 1 DFD also appear on the
level 2 DFD
– Repetition of data sources is allowed.
– A Data store can appear as a sink or source
within level 2 DFD
DFD: Course Registration System
Level 2 DFD
Courses &
Other info. Student Records Course Prereqs

1.1 Obtain
List of 1.2 Check
Student
Preferences Eligibility
Preferences

Eligible Students

1.3 Enroll Students

in Classes

Individual course registration

information
 Data Flow Splits and Joins
• A data flow split shows where a flow is broken into its
component parts for use in separate processes
• Data flow splits need not be mutually exclusive nor use
all the data from the parent flow
• As we move to lower levels we become more precise
about the data flows
• A data flow join shows where components are merged to
describe a more comprehensive flow
 Alternative Data Flows
• Where a process can produce different data
given different conditions
• We show both data flows and use the process
description to explain why they are alternatives
• Tip -- alternative data flows often accompany
processes with IF statements
 Creating Data Flow Diagrams
Steps:

1. Create a list of activities

2. Construct Context Level DFD
(identifies external entities and processes)
3. Construct Level 0 DFD
(identifies manageable sub process )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
5. Check against rules of DFD
 DFD Naming Guidelines

• External Entity  Noun

• Data Flow  Names of data
• Process  verb phrase
– a system name
– a subsystem name
• Data Store  Noun
Creating Data Flow Diagrams
Lemonade Stand Example
 Creating Data Flow Diagrams
Example
The operations of a simple
lemonade stand will be used
to demonstrate the creation
of dataflow diagrams.
Steps:
1. Create a list of activities
• Old way: no Use-Case Diagram
• New way: use Use-Case Diagram
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 0 DFD
(identifies manageable sub processes )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Think through the activities

that take place at a
lemonade stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Also think of the additional

activities needed to support
the basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Group these activities in

some logical fashion,
possibly functional areas.
Customer Order
Serve Product
Collect Payment

Produce Product
Store Product

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 2. Construct Context Level DFD
(identifies sources and sink)
Create a context level
diagram identifying the Context Level DFD
sources and sinks (users).
Sales Forecast
Order 0.0
CUSTOMER Lemonade Production Schedule EMPLOYEE
Customer Order Product Served System Pay
Serve Product Payment
Time Worked
Collect Payment Received Goods
Payment
Purchase Order

Produce Product
Store Product VENDOR

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 3. Construct Level 0 DFD
Create a level 0 diagram (identifies manageable sub processes )
identifying the logical Level 0 DFD
subsystems that may exist.
1.0
Sale
Customer Order Sales Forecast
Customer Order
Product Ordered
Serve Product
Payment
Collect Payment 2.0
CUSTOMER Production
EMPLOYEE
Production
Schedule

Product Served
Produce Product
Inventory
Store Product Received Goods
3.0
VENDOR Procure- Order
Purchase Order
Order Raw Materials ment
Decisions

Pay for Raw Materials Payment

Pay
Time Worked

Pay for Labor 4.0

Payroll
 Creating Data Flow Diagrams
Example 4. Construct Level 1- n DFD
Create a level 1 (identifies actual data flows and data stores )
decomposing the processes Level 1 DFD
in level 0 and identifying
CUSTOMER
data stores. Customer Order
Request for Forecast
Customer Order ORDER
1.1
Serve Product Record
Collect Payment Order
1.3
Produce Sales
Severed Order Forecast
Produce Product Payment Sales Forecast
Store Product 1.2
Receive PAYMENT
Payment
Order Raw Materials
Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying
Product Order
data stores.
ORDER
Customer Order 2.1
Serve
Serve Product Product
Quantity Severed

Collect Payment
Production RAW MATERIALS
Schedule

Produce Product 2.2

Store Product Produce
Product
Quantity Used

INVENTORTY
Order Raw Materials Production Data
Pay for Raw Materials
2.3
Quantity Produced & Location Stored
Store
Pay for Labor Product
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying Order Decision
PURCHASE
data stores. 3.1
ORDER
Produce
Purchase
Customer Order Order Quantity On-Hand

Serve Product RAW MATERIALS

Quantity

Collect Payment Received Goods

Received

3.2
Produce Product Receive
Items
Store Product RECEIVED ITEMS

Payment Approval
Order Raw Materials
VENDOR
Pay for Raw Materials 3.3
Pay
Vendor
Pay for Labor
Payment
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying Time Worked

data stores. TIME CARDS

4.1
Record Time

Customer Order Worked

Employee ID

Serve Product EMPLOYEE

Collect Payment Payroll Request

4.2 Unpaid time cards

Produce Product Calculate
Payroll
Store Product PAYROLL

Payment Approval
Order Raw Materials
Pay for Raw Materials 4.3
Pay
Employee
PAYMENTS
Pay for Labor
Payment
 Process Decomposition
1.1 1.2
1.0
Record Receive
Sale
Order Payment

2.1 2.2 2.3

2.0
Serve Produce Store
Production
Product Product Product

0.0
Lemonade
System
3.0 3.1 3.2 3.3
Produce
Procure- Purchase Receive Pay
ment Order Items Vendor

4.1 4.2 4.3

4.0
Record Time Calculate Pay
Payroll Worked Payroll Employee

Context Level Level 0 Level 1