Data Flow Diagrams

A structured analysis technique that employs

a set of visual representations of the data that
moves through the organization, the paths
through which the data moves, and the
processes that produce, use, and transform
data.
 Why Data Flow Diagrams?

• Can diagram the organization or the system

• Can diagram the current or proposed situation
• Can facilitate analysis or design
• Provides a good bridge from analysis to design
• Facilitates communication with the user at all
stages

2
 Types of DFDs
• Current - how data flows now
• Proposed - how we’d like it to flow
• Logical - the “essence” of a process
• Physical - the implementation of a process
• Partitioned physical - system architecture
or high-level design
 Levels of Detail
• Context level diagram - shows just the inputs
and outputs of the system
• Level 0 diagram - decomposes the process
into the major subprocesses and identifies
what data flows between them
• Child diagrams - increasing levels of detail
• Primitive diagrams - lowest level of
decomposition
Recommended Progression
• Current logical diagrams
– start with context level
– decompose as needed for understanding
• Proposed logical diagrams
– start at level where change takes place
– decompose as far as possible
• Current physical diagrams
– at level of change
• Proposed physical diagrams
– same levels as proposed logical
– lower levels become design
Four Basic Symbols

Source/ Data Flow

Sink

#
# Data Store
Process
 Context Level Diagram
• Just one process
• All sources and sinks that provide data to or
receive data from the process
• Major data flows between the process and
all sources/sinks
• No data stores
 Running Example
Course Registration: Context level Diagram

Class roster
Professor
Class Request
0
Student Payment Course
Receipt Registration
System
Student Schedule
Enrollment Registrar
statistics
 Level 0 Diagram
• Process is “exploded”
• Sources, sinks, and data flows repeated
from context diagram
• Process broken down into subprocesses,
numbered sequentially
• Lower-level data flows and data stores
added
 Running Example
Course Registration: Current Logical Level 0 Diagram
Payment
Class Request Student
Receipt

1.0 2.0
D1 Student Class Records Payment
Register Collect Information
Student for Student Fee
Course Student and Student D2 Student Payments
Course Data Class Record Payment
Student
Class
Student Class Record Student Class Record
Record
3.0 4.0 5.0
Produce Produce Produce
Student Class Enrollment
Schedule Roster Report
Student Schedule Enrollment
Class Roster Report

Student Professor Registrar

 Child Diagrams
• “Explode” one process in level 0 diagram
• Break down into lower-level processes, using
numbering scheme
• Must include all data flow into and out of
“parent” process in level 0 diagram
• Don’t include sources and sinks
• May add lower-level data flows and data stores
 Running Example
Course Registration: Current Logical Child Diagram

Available Seats
D3 Semester Schedule

Available Seats

1.1 1.2 1.3

Class Request Check Valid Class Check Feasible Class Enroll
Prerequisites Request for Request Student
Met Availability in Class
Error

Error Student
Student Course Record and Course
Record Data

D4 Student Transcripts D5 Course Catalogue D1 Student Class Records

 Physical DFDs
• Model the implementation of the system
• Start with a set of child diagrams or with
level 0 diagram
• Add implementation details
– indicate manual vs. automated processes
– describe form of data stores and data flows
– extra processes for maintaining data
 Running Example
Course Registration: Current Physical Child Diagram

Available Seats
D3 Semester Schedule DB

Available Seats

1.1 1.2 1.3

Class Request Check Advisement Check Feasible Class Enroll
Prerequisites Authorization for Request Student
Met Availability in Class
Student Notified (manual) (myUMBC) (STARS)
(verbally)
Unavailability
Message Student
Student Course Description and Course
File Data

D4 Department Student File D5 Course Catalogue (text) D1 Semester Enrollment DB

 Running Example
Course Registration: Proposed Physical Child Diagram

Available Seats
D3 Semester Schedule DB

Available Seats

1.1 1.2 1.3

Class Request Check Authorized Check Valid Class Enroll
Prerequisites Class Request for Request Student
Met Availability in Class
Student Notified (automated) (automated) (automated)
(email)
Student
Emailed Student
Student Course Record and Course
Record Data

D4 Registrar’s Student DB D5 Course Catalogue DB D1 Semester Enrollment DB

 Partitioning a physical DFD
• Part of system design
• System architecture
– high-level design
– overall shape of system
– some standard architectures
• Decide what processes should be grouped
together in the system components
 Running Example
Course Registration: Physical diagram (partitioned)

Available Seats
D3 Semester Schedule DB

Available Seats

1.1 1.2 1.3

Class Request Check Authorized Check Valid Class Enroll
Prerequisites Class Request for Request Student
Met Availability in Class
Student Notified (automated) (automated) (automated)
(email)
Student
Emailed Student
Student Course Record and Course
Record Data

D4 Registrar’s Student DB D5 Course Catalogue DB D1 Semester Enrollment DB

 Another Example
Perfect Pizza: Context Level Diagram

Weekly
Report Management
Phone Number
0
Customer Order Customer
Customer
Customer Info Order
System

Cook Order Cook

Delivery Delivery
Person Information
 Another Example
Perfect Pizza: Current Logical Level 0 Diagram
Customer Order
Customer

Phone
Number
1.0 2.0 3.0
Find Customer Take Order Print Delivery Delivery
Customer Information Customer Information Delivery Information Person
Record Order Order

Customer Customer Discount

Customer Record Order History
Info Information Info

D2 Customer History 6.0

D1 Customer Master Send Customer Customer
Order Order
Customer D3 Sales Records to Cook
Record
Sales Info Cook
Order
5.0 7.0
Add Print
Weekly Report
Customer Weekly
Record Totals Cook
Management
 Another Example
Perfect Pizza: Current Logical Child Diagram

Customer
D2 Customer History
History
3.1 Customer
Determine Information
Customer
3.2
Discount Discount
Order Record
Information Amount Discount
3.3
Print
Discount
Delivery
Information
Instructions

Delivery D3 Sales Records

Information
 Another Example
Perfect Pizza: Current Logical Child Diagram

5.1 5.2
Customer Information Record Raw Store
Customer Customer Customer
Information
Information Record

Customer
Record

D1 Customer Master
 Another Example
Perfect Pizza: Physical Child Diagram

Syntax Cancelled
Errors Transaction
Phoned
Customer 5.1 Recorded 5.2 Valid Customer 5.3
Information Clerk Types Customer System Information Clerk
Phone Customer Information Validates Visually
Number Information Customer Confirms
Information Cust. Info.

Customer 5.4
Format New Customer
D1 Customer DB Record Information
Customer
Record
 Another Example
Perfect Pizza: Current Physical Level 0 Diagram
Phoned
Customer Customer Order
Phone
Number
1.0 2.0 3.0
Delivery
Clerk Finds Customer Clerk Takes Customer System Prints Delivery
Customer Information Customer Delivery Person
Order & Order Printout
Row (by phone) Info Order

Customer Copy of Customer

Phoned Record Cust. Order Slip History
Customer Record Customer
Info. History
Info
D2 Customer History DB Record
D1Customer Spreadsheet 8.0
Mgr Updates
Customer Customer
Copies of History
Customer D3 Sales Records File Order Slips (nightly)
Record & Del. Printouts
Copies of Phoned
5.0 Order Slips Customer
Clerk Adds 7.0 Order
Customer Mgr Prints 6.0
Phone # Weekly Report Weekly
Row Totals Clerk Sends
Copy of Order
Management (batch) Cook order slip to Cook
(paper)
 Another Example
Perfect Pizza: Proposed Physical Level 0 Diagram
Phoned
Customer Customer Order Order
Info D3 Sales DB
Phone
Number Discount
Info
1.0 2.0 3.0
Delivery
System Finds Customer Clerk Enters Order System Prints Delivery
Customer Information Customer Delivery Person
Order Info Printout
Record (by phone) Order

Customer Order Customer

Phoned Record Cust. Info History
Customer Info. Record
Info
D2 Customer History DB
D1 Customer DB

Customer D3 Sales DB
Record
Sales
5.0 Records
Clerk Adds 7.0
Customer System Prints
Phone # Weekly Report Weekly
Record Totals
Cook Management (batch)
 Another Example
Perfect Pizza: Partitioned Physical Level 0 Diagram
Phoned
Customer Customer Order Order
Info D3 Sales DB
Phone
Number Discount
Info
1.0 2.0 3.0
Delivery
System Finds Customer Clerk Enters Order System Prints Delivery
Customer Information Customer Delivery Person
Order Info Printout
Record (by phone) Order

Customer Order Customer

Phoned Record Cust. Info History
Customer Info. Record
Info
D2 Customer History DB
D1 Customer DB

Customer D3 Sales DB
Record
Sales
5.0 Records
Clerk Adds 7.0
Customer System Prints
Phone # Weekly Report Weekly
Record Totals
Cook Management (batch)
 Data Flow Diagramming Rules
• Processes
– a process must have at least one input
– a process must have at least one output
– a process name (except for the context level
process) should be a verb phrase
• usually three words: verb, modifier, noun
• on a physical DFD, could be a complete sentence
 1.0 2.0
Demographic
Gather Compile
Data
Data Statistics

Survey
Responses 3.0
Final
Analyze
Report
Responses
 2.0 2.0
Visa BETTER Check
Authorization Customer
Credit

2.0 2.0
Total Total
BETTER
Records Sales
Records

2.0 2.0
QA BETTER Inspect
Process Finished
Products
 Data Flow Diagramming Rules
• Data stores and sources/sinks
– no data flows between two data stores; must be
a process in between
– no data flows between a data store and a source
or sink; must be a process in between
– no data flows between two sources/sinks
• such a data flow is not of interest, or
• there is a process that moves that data
 2.1 2.1
Customer Customer Store
Store
Information Information Customer
Customer
Data Data

Customer Customer
Data Data Customer
Preferences

D1 Customer Data D1 Customer Data

Customer
Preferences
D2 Customer Preferences

D2 Customer Preferences
 2.1 2.1
Customer Customer Store
Store
Information Information Customer
Customer
Data Data
Customer
Customer Data
Data
D1 Customer Data

D1 Customer Data Customer

2.2
Data
Extract
Customer
Customer
Preferences
Preferences Customer
Preferences

D2 Customer Preferences
D2 Customer Preferences
 Customer

Customer
Information
Customer
2.0

Customer Store
Data Customer
Data

D1 Customer Data Customer

Data

D1 Customer Data
 Service
Doctor
Information

Diagnosis Medical
Billing
System

Patient Bill
 Data Flow Diagramming Rules
• Data flows
– data flows are unidirectional
– a data flow may fork, delivering exactly the same data to
two different destinations
– two data flows may join to form one only if the original
two are exactly the same
– no recursive data flows
– data flows (and data stores and sources/sinks) are
labelled with noun phrases
 1.0 1.0
Take Take
Customer Customer
Order Order
Customer
Order

Order Order Order Order

Total Information Total Information

2.0 3.0 2.0 3.0

Total Print Total Print
Daily Delivery Daily Delivery
Sales Instructions Sales Instructions
 1.0 2.0 1.0 2.0
Take Lookup Take Lookup
Customer Customer Customer Customer
Order Record Order Record
Customer Customer Customer Customer
Order Address Order Address

Customer
Information
3.0 3.0
Print Print
Delivery Delivery
Instructions Instructions
 1.0
Daily Cumulative
Calculate
Sales To-Date
Weekly
Sales Sales
 Data Flow Diagramming
Guidelines

• The inputs to a process are different

from the outputs

• Every object in a DFD has a unique

name
 1.0
Customer Customer
Validate
Data Data
Customer
Data

1.0
Customer Validate Valid
Data Customer Customer
Data Data
 1.0 2.0 3.0
Order
Get Customer Take Process
Customer Data Customer Customer
Customer
Data Order Order
Data

1.0 2.0 3.0

Get Customer Take Order Process
Customer Data Customer Customer
Data Order Order
 2.0
Customer Take
Data Customer
Order
1.0
Get
Customer
3.0
Data
Customer Validate
Data Customer
Data

Only if these are

exactly the same
 Data Flow Diagramming
Guidelines
• A data flow at one level may be
decomposed at a lower level
• All data coming into and out of a
process must be accounted for
• On low-level DFDs, new data flows
can be added to represent
exceptional situations
 1.0
Customer Get Customer
Information Customer Address
Address

1.1 1.2
Customer Customer
Phone Get Phone Lookup
Customer Customer
Phone Address
Customer
Address
1.3
Customer Request
Address Customer
Address
 1.0
Customer Get Customer
Information Customer Address
Address

1.1 1.2
Customer Customer
Phone Get Phone Lookup
Customer Customer
Invalid Phone Phone Address
Customer
Number Message
Address
1.3
Customer Request
Address Customer
Address
 Data Elements
• Indivisible pieces of data
• Data flows and data stores are made up of
data elements
• Like attributes on an ER diagram
• The data elements of a data flow flowing in
or out of a data store must be a subset of the
data elements in that data store
 Employee D1 Employee Master
Employee
Hours Record
Worked
1.0 2.0
Employee Calculate Gross Calculate
D2 Employee Time File Time Gross Pay Withholding
Record Pay Amount

Withholding

Employee 4.0 3.0

D1 Employee Master Record Print Net Calculate
Employee Pay Net
Check Paycheck Pay
Reconciliation
Record Employee
Paycheck
D3 Check Reconciliation
Employee
 Employee D4Withholding Tables
Number of
D1 Employee Master Dependents Withholding
Hours
Worked Employee Rates
5.0 Record
Create 1.0 2.0
Time Gross
Record Calculate Calculate
Gross Pay Withholding
Employee Employee Pay Amount
Time Record Time
Record Withholding
D2 Employee Time File Gross
Amount
Pay
D1 Employee Master
Employee 4.0 3.0
6.0 Record Print Net Calculate
Reconcile Paycheck Employee Pay Net
Pay Paycheck Pay
Information
Check
Check Employee
Reconciliation Paycheck
Record
D3 Check Reconciliation Employee
 DFDs and ERDs
• DFDs and ERDs are both used to model
systems, but they show two very different
perspectives on the system
• A DFD shows what the system does as well
as the data that the system manipulates
• An ERD shows only the data that the
system manipulates.
 DFDs and ERDs (cont.)
• Entities on an ERD often (but not always) correspond to
data stores on a DFD
• Attributes on an ERD usually correspond to data elements
(listed in the data dictionary) that make up the data store
and data flows on a DFD
• Relationships on an ERD do not correspond to processes
on a DFD.
• Sources and sinks on a DFD usually do not show up as
entities on an ERD
 Example DFD and ERD
Customer

DFD Cook
Places
Order
Customer

1.0 Hours Name

Name
Address
Take
Order

Inventory

2.0 3.0
Processed
Convert Order Convert Order Item Quantity
Order
to Cooking to Ingredient
Instructions List

Cooking
Ingredients
Instructions

D1 Order Log

Cook
Inventory
Processing Incorrect ERD
 Example DFD and ERD
OrderId
Customer Order
Time

DFD Date

ItemQuantity
Contains
1.0

Take Includes Ingredient

Order

Ingredient
Quantity Description
Item
2.0 3.0
Processed
Convert Order Convert Order
Order Cooking
to Cooking to Ingredient Requires
Instructions
Instructions List ItemId ItemName

Cooking Index
Ingredients StepId Description
Instructions

D1 Order Log

Cook
Inventory
Processing Correct ERD