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 Original info comes from users - during requirements gathering - can go back and check info with users

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/ Sink Data Flow Process # Data Store # Naming: entities - noun data flows - noun high level process - system name other processes - verb/adjective/noun data stores - noun # Process # Data Store

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 Professor Class roster Class Request Course Registration System Student Payment Receipt Process numbered 0 Student Schedule Registrar Enrollment 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 Guideline - 3 to 9 processes

Running Example Course Registration: Current Logical Level 0 Diagram Student Payment Class Request Receipt 1.0 Register Student for Course 2.0 Collect Student Fee Payment D1 Student Class Records Payment Information Student and Course Data Student Class Record D2 Student Payments Student Class Record Student Class Record Student Class Record 3.0 Produce Student Schedule 4.0 Produce Class Roster 5.0 Produce Enrollment Report Enrollment Report Student Schedule Class Roster 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 - can go more than one level down

Running Example Course Registration: Current Logical Child Diagram Available Seats D3 Semester Schedule Available Seats 1.1 Check Prerequisites Met 1.2 Check for Availability 1.3 Enroll Student in Class Class Request Valid Class Request Feasible Class Request Error Error Student and Course Data 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 1.2 1.3 Class Request Check Prerequisites Met (manual) Advisement Authorization Check for Availability (myUMBC) Feasible Class Request Enroll Student in Class (STARS) Student Notified (verbally) Unavailability Message Student and Course Data Student File Course Description 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 Prerequisites Met (automated) Authorized Class Request Check for Availability (automated) Valid Class Request Enroll Student in Class (automated) Student Notified (email) Student Emailed Student and Course Data Student Record Course Record 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 Prerequisites Met (automated) Authorized Class Request Check for Availability (automated) Valid Class Request Enroll Student in Class (automated) Student Notified (email) Student Emailed Student and Course Data Student Record Course Record 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

1.0 Get Customer Address Customer Information Customer Address Directory Name 1.1 Lookup Customer Entry 1.2 Extract Customer Address Customer Record Customer Information Customer Zip Code Customer Information 1.1 Lookup Customer Entry 1.2 Extract Customer Address Customer Record Customer Address Directory Name

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 Get Customer Address Customer Information Customer Address 1.1 Get Customer Phone 1.2 Lookup Customer Address Customer Phone Customer Phone Customer Address 1.3 Request Customer Address Customer Address

1.0 Get Customer Address Customer Information Customer Address 1.1 Get Customer Phone 1.2 Lookup Customer Address Customer Phone Customer Phone Invalid Phone Number Message Customer Address 1.3 Request Customer Address Customer Address

Another Example Perfect Pizza: Context Level Diagram Management Weekly Report Phone Number Customer Order System Customer Customer Order Customer Info Cook Delivery Person Cook Order Delivery Information

Another Example Perfect Pizza: Current Logical Level 0 Diagram Customer Customer Order Phone Number 1.0 Find Customer Record 2.0 Take Customer Order 3.0 Print Delivery Order Delivery Person Customer Information Order Information Delivery Information Customer Record Customer History Discount Info Customer Info Order Information D2 Customer History 6.0 Send Order to Cook D1 Customer Master Customer Customer Order D3 Sales Records Customer Record Sales Info Cook Order 7.0 Print Weekly Totals 5.0 Add Customer Record Weekly Report Cook Management

Another Example Perfect Pizza: Current Logical Child Diagram Customer History D2 Customer History 3.1 Determine Customer Discount Customer Information 3.2 Record Discount Discount Amount Order Information 3.3 Print Delivery Instructions Discount Information Delivery Information D3 Sales Records

Another Example Perfect Pizza: Current Logical Child Diagram 5.1 Record Customer Information 5.2 Store Customer Record Customer Information Raw Customer Information Customer Record D1 Customer Master

Another Example Perfect Pizza: Physical Child Diagram Syntax Errors Cancelled Transaction Phoned Customer Information 5.1 Clerk Types Customer Information Recorded Customer Information 5.2 5.3 Valid Customer Information System Validates Customer Information Clerk Visually Confirms Cust. Info. Phone Number 5.4 Format Customer Record Customer Record New Customer Information D1 Customer DB

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

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

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