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 wed 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/ Sink

Data Flow

# 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 Class Request

Professor

Student

Payment Receipt

0 Course Registration System Enrollment statistics

Student Schedule

Registrar

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

Class Request

Student

Payment Receipt

1.0 Register Student for Course

D1 Student Class Records Student and Course Data

2.0 Collect Student Fee Student Class Record Payment

Payment Information D2 Student Payments Student Class Record

Student Class Record

Student Class Record

3.0 Produce Student Schedule

Student Schedule

4.0 Produce Class Roster

Class Roster

5.0 Produce Enrollment Report

Enrollment 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 Dont include sources and sinks May add lower-level data flows and data stores

Running Example

Course Registration: Current Logical Child Diagram

D3

Semester Schedule

Available Seats

Available Seats

1.1
Class Request

1.2
Valid Class Request Feasible Class Check Request for Availability Error

1.3
Enroll Student in Class
Student and Course Data

Error

Check Prerequisites Met

Student Record

Course Record

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 Class Request Check Prerequisites Met (manual) Student Notified

(verbally)

Advisement Authorization

1.2 Feasible Class Check for Request Availability (myUMBC)

1.3 Enroll Student in Class (STARS)

Student and Course Data

Unavailability Message

Student File

Course Description

D4 Department Student File

D5 Course Catalogue (text)

D1 Semester Enrollment DB

Running Example

Course Registration: Proposed Physical Child Diagram

D3 Semester Schedule DB

Available Seats

Available Seats

1.1 Class Request Check Prerequisites Met (automated) Student Notified

(email) Student Record

Authorized Class Request

1.2 Check for Availability (automated)

Valid Class Request

1.3 Enroll Student in Class (automated)

Student and Course Data

Student Emailed Course Record

D4 Registrars 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 Class Request Check Prerequisites Met (automated) Student Notified

(email)

Authorized Class Request

1.2 Check for Availability (automated)

Valid Class Request

1.3 Enroll Student in Class (automated)

Student and Course Data

Student Emailed

Student Record

Course Record

D4 Registrars Student DB

D5 Course Catalogue DB

D1 Semester Enrollment DB

Another Example

Perfect Pizza: Context Level Diagram

Weekly Report Phone Number Customer Order Customer Info

Management

Customer

0 Customer Order System Cook Order

Delivery Person

Delivery Information

Cook

Another Example

Perfect Pizza: Current Logical Level 0 Diagram

Customer Order

Customer
Phone Number 1.0 Find Customer Record Customer Information 2.0 Take Customer Order Order Information Customer History D2 Customer History 3.0 Print Delivery Order Discount Info 6.0 Send Order to Cook Cook Order Delivery Information

Delivery Person

Customer Info

Customer Record

Order Information

D1 Customer Master Customer Record 5.0 Add Customer Record

Customer Customer Order

D3

Sales Records

Sales Info 7.0 Print Weekly Totals

Weekly Report

Management

Cook

Another Example

Perfect Pizza: Current Logical Child Diagram

Customer History
3.1 Determine Customer Discount

D2 Customer History

Customer Information Discount Amount

Order Information

3.2 Record Discount

Discount Information
D3

3.3 Print Delivery Instructions Delivery Information

Sales Records

Another Example

Perfect Pizza: Current Logical Child Diagram

Customer Information

5.1 Record Customer Information

Raw Customer Information

5.2 Store Customer Record

Customer Record

D1 Customer Master

Another Example

Perfect Pizza: Physical Child Diagram

Syntax Errors Phoned Customer Information Phone Number 5.1 Clerk Types Customer Information Recorded Customer Information 5.2 System Validates Customer Information Valid Customer Information

Cancelled Transaction 5.3 Clerk Visually Confirms Cust. Info.

D1

Customer DB

Customer Record

5.4 Format Customer Record

New Customer Information

Another Example

Perfect Pizza: Current Physical Level 0 Diagram

Customer
Phone Number 2.0 1.0 Clerk Finds Customer Clerk Takes Customer Information Customer Order Row (by phone) Phoned Customer Info Customer Record Customer & Order Info 3.0 System Prints Delivery Order Delivery Printout Phoned Customer Order

Delivery Person

Cust. Info.

Copy of Order Slip

Customer History Record

D1 Customer Spreadsheet Customer Record 5.0 Clerk Adds Customer Row

D2 Customer History DB

Customer History Record

Phone #

Copies of D3 Sales Records File Order Slips & Del. Printouts Copies of Order Slips 7.0 Mgr Prints Weekly Report Weekly Totals (batch) Management Cook

8.0 Mgr Updates Customer History (nightly)

Customer
Phoned Customer Order

6.0 Clerk Sends Copy of Order order slip to Cook (paper)

Another Example

Perfect Pizza: Proposed Physical Level 0 Diagram

Customer
Phone Number 2.0 1.0 System Finds Customer Clerk Enters Customer Information Customer Order Record (by phone) Order Customer Info Phoned Cust. Record Customer Info. Info D1 Customer DB Order Info Phoned Customer Order Order Info D3 Sales DB Discount Info 3.0 System Prints Delivery Order Customer History Record D2 Customer History DB Delivery Printout

Delivery Person

Customer Record 5.0 Clerk Adds Customer Record

D3

Sales DB

Phone #

Cook

7.0 System Prints Weekly Report Weekly Totals (batch) Management

Sales Records

Another Example

Perfect Pizza: Partitioned Physical Level 0 Diagram

Customer
Phone Number 2.0 1.0 System Finds Customer Clerk Enters Customer Information Customer Order Record (by phone) Order Customer Info Phoned Cust. Record Customer Info. Info D1 Customer DB Order Info Phoned Customer Order Order Info D3 Sales DB Discount Info 3.0 System Prints Delivery Order Customer History Record D2 Customer History DB Delivery Printout

Delivery Person

Customer Record 5.0 Clerk Adds Customer Record

D3

Sales DB

Phone #

Cook

7.0 System Prints Weekly Report Weekly Totals (batch) Management

Sales Records

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

Gather Data

Demographic Data Survey Responses

Compile Statistics
3.0

Analyze Responses

Final Report

2.0 Visa Authorization

2.0

BETTER

Check Customer Credit

2.0

2.0

Total Records

BETTER

Total Sales Records

2.0

2.0

QA Process

BETTER

Inspect 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 Customer Information Store Customer Data Customer Data Customer Information

2.1 Store Customer Data

Customer Data

Customer Preferences

D1 Customer Data

D1 Customer Data

Customer Preferences

D2 Customer Preferences

D2 Customer Preferences

2.1 Customer Information Store Customer Data Customer Data Customer Information Customer Data D1 Customer Data D1 Customer Data Customer Data

2.1 Store Customer Data

2.2 Extract Customer Preferences

Customer Preferences

Customer Preferences

D2 Customer Preferences

D2 Customer Preferences

Customer

Customer

Customer Information
2.0

Customer Data

Store Customer Data

Customer Data D1 Customer Data

D1 Customer Data

Doctor

Service Information 0

Diagnosis

Medical Billing System Bill

Patient

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 Customer Order

Customer Order Order Total 2.0 Order Information 3.0 Print Delivery Instructions Order Total 2.0

Take Customer Order

Order Information 3.0 Print Delivery Instructions

Total Daily Sales

Total Daily Sales

1.0

2.0

1.0

2.0

Take Customer Order

Customer Order

Lookup Customer Record

Customer Address Customer Information 3.0

Take Customer Order

Customer Order

Lookup Customer Record

Customer Address

3.0

Print Delivery Instructions

Print Delivery Instructions

1.0 Daily Sales Calculate Weekly Sales Cumulative To-Date 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 Data Validate Customer Data Customer Data

1.0

Customer Data

Validate Customer Data

Valid Customer Data

1.0 Get Customer Data Customer Data

2.0 Take Customer Order

Order Customer Data

3.0 Process Customer Order

1.0 Get Customer Data

2.0

3.0

Customer Data

Take Customer Order

Order

Process Customer Order

2.0 Customer Data Take Customer Order

1.0
Get Customer Data Customer Data

3.0

Validate 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 Information Get Customer Address Customer Address

1.1 Customer Phone Get Customer Phone 1.3 Customer Address Request Customer Address Customer Phone

1.2 Lookup Customer Address Customer Address

1.0 Customer Information Get Customer Address Customer Address

1.1 Customer Phone Invalid Phone Number Message Customer Address Get Customer Phone 1.3 Request Customer Address Customer Phone

1.2 Lookup Customer 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 Hours Worked D2 Employee Time File

D1 Employee Master Employee Record Employee Time Record 1.0 Calculate Gross Pay Gross Pay 2.0 Calculate Withholding Amount Withholding

D1 Employee Master

Employee Record

Check Reconciliation Record

D3 Check Reconciliation

4.0 Print Employee Paycheck

Net Pay

3.0 Calculate Net Pay

Employee Paycheck Employee

Employee Hours Worked 5.0 Create Time Record Employee Time Record D2 Employee Time File D1 Employee Master 6.0 Reconcile Pay Check

D4 Withholding Tables Number of D1 Employee Master Dependents Withholding Rates Employee Record 1.0 Calculate Gross Pay Gross Pay 4.0 Print Employee Paycheck Gross Pay 2.0 Calculate Withholding Amount Withholding Amount

Employee Time Record

Employee Record Paycheck Information

Net Pay

3.0 Calculate Net Pay

Check Reconciliation Record D3 Check Reconciliation

Employee Paycheck 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
1.0 Take Order

Cook

Places Order

Customer

Name

Hours

Name Address

Inventory
2.0 Convert Order to Cooking Instructions Cooking Instructions D1 Order Log Cook Inventory Processing Processed Order 3.0 Convert Order to Ingredient List

Item

Quantity

Ingredients

Incorrect ERD

Example DFD and ERD

OrderId

Customer

Order

Time Date

DFD
1.0 Take Order
Contains

ItemQuantity

Includes

Ingredient

2.0 Convert Order to Cooking Instructions Cooking Instructions D1 Order Log Cook Processed Order

3.0 Convert Order to Ingredient List

Item

Ingredient Quantity

Description

Requires ItemId ItemName Index

Cooking Instructions

Ingredients

StepId

Description

Inventory Processing

Correct ERD