Data Flow Diagrams A structured analysis technique that

  • Slides: 30
Download presentation
Data Flow Diagrams A structured analysis technique that employs a set of visual representations

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

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 -

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

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 # Process Data Flow # Data Store

Four Basic Symbols Source/ Sink # Process Data Flow # Data Store

Context Level Diagram • Just one process • All sources and sinks that provide

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 Student Payment Receipt

Running Example Course Registration: Context level Diagram Class roster Class Request Student Payment Receipt Student Schedule Professor 0 Course Registration System Enrollment statistics Registrar

Modeling Dilemma: Scope • Deciding whether an entity is an external source/sink or an

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

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

Running Example Course Registration: Current Logical Level 0 Diagram Class Request Student Payment Receipt 1. 0 Register Student for Course 2. 0 D 1 Student Class Records Collect Student Fee Student and Student Course Data Class Record Payment Student Class Record 3. 0 Produce Student Schedule Student Class Record 4. 0 Produce Class Roster Professor Payment Information D 2 Student Payments Student Class Record 5. 0 Produce Enrollment Report Registrar

Child Diagrams • “Explode” one process in level 0 diagram • Break down into

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 D 3 Semester Schedule Available Seats

Running Example Course Registration: Current Logical Child Diagram D 3 Semester Schedule Available Seats 1. 1 Class Request Check Prerequisites Met Valid Class Request Error 1. 2 Feasible Class Check Request for Availability Error Student Record D 4 Course Record Student Transcripts D 5 Course Catalogue 1. 3 Enroll Student in Class Student and Course Data D 1 Student Class Records

Physical DFDs • Model the implementation of the system • Start with a set

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 D 3 Semester Schedule DB Available

Running Example Course Registration: Current Physical Child Diagram D 3 Semester Schedule DB Available Seats 1. 1 Class Request 1. 2 Check Prerequisites Met Student Notified (manual) Advisement Authorization Feasible Class Check for Request Availability (my. UMBC) (verbally) Student File Course Description D 4 Department Student File 1. 3 D 5 Course Catalogue (text) Enroll Student in Class (STARS) Unavailability Message Student and Course Data D 1 Semester Enrollment DB

Running Example Course Registration: Proposed Physical Child Diagram D 3 Semester Schedule DB Available

Running Example Course Registration: Proposed Physical Child Diagram D 3 Semester Schedule DB Available Seats 1. 1 1. 2 Class Request Check Prerequisites Met Student Notified (automated) Authorized Class Request Check for Availability (automated) 1. 3 (email) Student Record Course Record D 4 Registrar’s Student DB Enroll Student in Class (automated) Valid Class Request D 5 Course Catalogue DB Student Emailed Student and Course Data D 1 Semester Enrollment DB

Partitioning a physical DFD • Part of system design • System architecture – high-level

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) D 3 Semester Schedule DB Available Seats

Running Example Course Registration: Physical diagram (partitioned) D 3 Semester Schedule DB Available Seats 1. 1 1. 2 Class Request Check Prerequisites Met Student Notified (automated) Authorized Class Request Check for Availability (automated) 1. 3 (email) Student Record Course Record D 4 Registrar’s Student DB Enroll Student in Class (automated) Valid Class Request D 5 Course Catalogue DB Student Emailed Student and Course Data D 1 Semester Enrollment DB

Balancing • Most important rule in data flow diagramming • Every child diagram must

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 Information Directory Name 1. 1 Customer Information Directory Name Lookup Customer Entry 1.

Customer Information Directory Name 1. 1 Customer Information Directory Name Lookup Customer Entry 1. 1 Lookup Customer Entry 1. 0 Get Customer Address Customer Record Customer Address 1. 2 Extract Customer Address Customer Zip Code 1. 2 Extract Customer Address

Balancing Exceptions • A data flow at one level may be decomposed at a

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 Information Customer Phone 1. 1 Get Customer Phone 1. 3 Customer

1. 0 Customer Information Customer Phone 1. 1 Get Customer Phone 1. 3 Customer Address Request Customer Address Get Customer Address Customer Phone Customer Address 1. 2 Lookup Customer Address

1. 0 Customer Information Customer Phone Invalid Phone Number Message 1. 1 Get Customer

1. 0 Customer Information Customer Phone Invalid Phone Number Message 1. 1 Get Customer Phone 1. 3 Customer Address Request Customer Address Get Customer Address Customer Phone Customer Address 1. 2 Lookup Customer Address

Another Example Perfect Pizza: Context Level Diagram Weekly Report Phone Number Customer Delivery Person

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

Another Example Perfect Pizza: Current Logical Level 0 Diagram Customer Order Customer Phone Number

Another Example Perfect Pizza: Current Logical Level 0 Diagram Customer Order Customer Phone Number 1. 0 Find Customer Record Customer Information Customer Record 2. 0 Take Customer Order Information Customer History Order Information D 2 Customer History D 1 Customer Master Customer Record 5. 0 Add Customer Record 3. 0 Print Delivery Order D 3 Sales Records Sales Info Weekly Report Management 7. 0 Print Weekly Totals Delivery Information Delivery Person Discount Info 6. 0 Send Order to Cook Order Cook Customer Order

Another Example Perfect Pizza: Current Logical Child Diagram Customer History Order Information 3. 1

Another Example Perfect Pizza: Current Logical Child Diagram Customer History Order Information 3. 1 Determine Customer Discount D 2 Customer History Customer Information 3. 2 Record Discount Amount 3. 3 Print Delivery Instructions Delivery Information Discount Information D 3 Sales Records

Another Example Perfect Pizza: Current Logical Child Diagram Customer Information 5. 1 Record Customer

Another Example Perfect Pizza: Current Logical Child Diagram Customer Information 5. 1 Record Customer Information Raw Customer Information 5. 2 Store Customer Record D 1 Customer Master

Another Example Perfect Pizza: Physical Child Diagram Phoned Customer Information Phone Number Syntax Errors

Another Example Perfect Pizza: Physical Child Diagram Phoned Customer Information Phone Number Syntax Errors 5. 1 Clerk Types Customer Information D 1 Recorded Customer Information Customer DB 5. 2 System Validates Customer Information Customer Record Cancelled Transaction Valid Customer Information 5. 4 Format Customer Record 5. 3 Clerk Visually Confirms Cust. Info. New Customer Information

Another Example Perfect Pizza: Current Physical Level 0 Diagram Phoned Customer Order Customer Phone

Another Example Perfect Pizza: Current Physical Level 0 Diagram Phoned Customer Order Customer Phone Number 2. 0 1. 0 Clerk Finds Customer Clerk Takes Customer Information Customer Order Row (by phone) Phoned Customer Info Customer Record Cust. Info. D 1 Customer Spreadsheet Customer Record Phone # 5. 0 Clerk Adds Customer Row Customer & Order Info Copy of Order Slip 3. 0 System Prints Delivery Order Customer History Record D 2 Customer History DB Delivery Person Delivery Printout Customer History Record 8. 0 Mgr Updates Customer History (nightly) Copies of D 3 Sales Records File Order Slips & Del. Printouts Copies of Order Slips 7. 0 Mgr Prints Weekly Report Weekly Totals (batch) Management Cook 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 Phoned Customer Order Info Phone

Another Example Perfect Pizza: Proposed Physical Level 0 Diagram Phoned Customer Order Info Phone Number Order Info 3. 0 System Prints Delivery Order Customer History Record D 2 Customer History DB Customer DB D 3 Customer Record Phone # Sales DB Discount Info 2. 0 1. 0 System Finds Customer Clerk Enters Customer Information Customer Order Record (by phone) Order Customer Info Phoned Cust. Record Customer Info D 1 D 3 Sales DB Sales Records 5. 0 Clerk Adds Customer Record Cook 7. 0 System Prints Weekly Report Weekly Totals (batch) Management Delivery Printout Delivery Person

Another Example Perfect Pizza: Partitioned Physical Level 0 Diagram Phoned Customer Order Info Phone

Another Example Perfect Pizza: Partitioned Physical Level 0 Diagram Phoned Customer Order Info Phone Number Order Info 3. 0 System Prints Delivery Order Customer History Record D 2 Customer History DB Customer DB D 3 Customer Record Phone # Sales DB Discount Info 2. 0 1. 0 System Finds Customer Clerk Enters Customer Information Customer Order Record (by phone) Order Customer Info Phoned Cust. Record Customer Info D 1 D 3 Sales DB Sales Records 5. 0 Clerk Adds Customer Record Cook 7. 0 System Prints Weekly Report Weekly Totals (batch) Management Delivery Printout Delivery Person