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
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
 Modeling Dilemma: Scope
• Deciding whether an entity is an external
source/sink or an integral part of the system
• E.g. users of the system, managers who
oversee the process
• Does the entity simply provide or receive
information, or do they perform some part
of the process?
 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

 Balancing
• Most important rule in data flow diagramming
• Every child diagram must include the same
inputs and outputs as the process it represents
in its parent diagram
• Also applies to the level 0 diagram
• Checking for balancing is a good way to find
errors and omissions in your DFDs
 Customer 1.0
Information Get Customer
Directory Customer Address
Name Address

1.1 1.2
Customer Customer Customer
Lookup Record Extract
Information Customer Customer Zip Code
Entry Address

Customer 1.1 1.2

Information Customer Customer
Lookup Record Extract
Directory Customer Customer Address
Name Entry Address
 Balancing Exceptions

• A data flow at one level may be

decomposed at a lower level
• On low-level DFDs, new data flows
can be added to represent
exceptional situations
• All data coming into and out of a
process must be accounted for
 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
 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)