Data Flow Diagrams - University of Maryland,cseaman/ifsm636/lect0913.pdf · Data Flow Diagrams A...

Data Flow Diagrams

A structured analysis technique that employsa set of visual representations of the data thatmoves through the organization, the pathsthrough which the data moves, and theprocesses that produce, use, and transformdata.

2

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

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 theinputs and outputs of the system

• Level 0 diagram - decomposes the processinto the major subprocesses and identifieswhat data flows between them

• Child diagrams - increasing levels of detail• Primitive diagrams - lowest level of

decomposition

• 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

Recommended Progression

Four Basic Symbols

Source/Sink

Data Flow

#

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

0Course

RegistrationSystem

Student

Registrar

ProfessorClass Request

Payment

Receipt

Student Schedule

Class roster

Enrollmentstatistics

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

Student RegistrarProfessor

1.0

RegisterStudent for

Course

D1 Student Class Records

D2 Student Payments

2.0

CollectStudent Fee

Payment

3.0

ProduceStudent

Schedule

4.0

ProduceClassRoster

5.0

ProduceEnrollment

Report

PaymentInformation

Student andCourse Data

StudentClass Record

Student Class Record Student Class Record

Student Class Record

Student Schedule Class RosterEnrollment

Report

StudentClass Request

Receipt

Payment

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

1.2

Checkfor

Availability

1.1

CheckPrerequisites

Met

1.3

EnrollStudentin Class

D1 Student Class RecordsD5 Course CatalogueD4 Student Transcripts

D3 Semester Schedule

Class Request Valid ClassRequest

Feasible ClassRequest

Available Seats

Available Seats

StudentRecord

Course RecordStudent

and CourseData

Error

Error

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

1.2

Checkfor

Availability(myUMBC)

1.1

CheckPrerequisites

Met(manual)

1.3


(STARS)

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

D3 Semester Schedule DB

Class Request AdvisementAuthorization

Feasible ClassRequest

Available Seats

Available Seats

Studentand Course

Data

Student Notified(verbally)

UnavailabilityMessage

StudentFile

Course Description

Running Example

Course Registration: Proposed Physical Child Diagram

1.2

Checkfor

Availability(automated)

1.1

CheckPrerequisites

Met(automated)

1.3


(automated)

D1 Semester Enrollment DBD5 Course Catalogue DBD4 Registrar’s Student DB


Class Request AuthorizedClass Request

Valid ClassRequest

Available Seats

Available Seats

Studentand Course

Data

Student Notified(email)

StudentEmailed

StudentRecord

Course Record

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 groupedtogether in the system components

Running Example

Course Registration: Physical diagram (partitioned)

1.2

Checkfor

Availability(automated)

1.1

CheckPrerequisites

Met(automated)

1.3


(automated)

D1 Semester Enrollment DBD5 Course Catalogue DBD4 Registrar’s Student DB


Class Request AuthorizedClass Request

Valid ClassRequest

Available Seats

Available Seats

Studentand Course

Data

Student Notified(email)

StudentEmailed

StudentRecord

Course Record

Another Example

Perfect Pizza: Context Level Diagram

0Customer

OrderSystem

Customer

Cook

ManagementPhone Number

Customer Order

Customer Info

DeliveryInformation

WeeklyReport

Cook OrderDeliveryPerson

Another Example

Perfect Pizza: Current Logical Level 0 Diagram

1.0Find

CustomerRecord

7.0Print

WeeklyTotals

6.0SendOrder

to Cook

5.0Add

CustomerRecord

2.0Take

CustomerOrder

3.0Print

DeliveryOrder

Customer

CustomerInfo

PhoneNumber

Customer Order

D1 Customer Master

CustomerRecord

CustomerRecord

CustomerInformation

D2 Customer History

D3 Sales Records

OrderInformation

OrderInformation

CustomerHistory

DeliveryInformation

CustomerCustomerOrder

Cook

CookOrder

Management

Sales Info

Weekly Report

DiscountInfo

DeliveryPerson

Another Example

Perfect Pizza: Current Logical Child Diagram

3.1DetermineCustomerDiscount 3.2

RecordDiscount

3.3Print

DeliveryInstructions

OrderInformation

DiscountAmount

DeliveryInformation

D2 Customer History

D3 Sales Records

CustomerHistory

DiscountInformation

CustomerInformation

Another Example

Perfect Pizza: Current Logical Child Diagram

5.1Record

CustomerInformation

5.2Store

CustomerRecord

D1 Customer Master

Customer Information RawCustomer

Information

CustomerRecord

Another Example

Perfect Pizza: Physical Child Diagram

5.3Clerk

VisuallyConfirmsCust. Info.

5.1Clerk Types

CustomerInformation

5.2System

ValidatesCustomer

Information

5.4Format

CustomerRecord

PhonedCustomer

InformationRecordedCustomer

Information

Valid CustomerInformation

SyntaxErrors

CancelledTransaction

New CustomerInformationD1 Customer DB

CustomerRecord

PhoneNumber

Another Example

Perfect Pizza: Current Physical Level 0 Diagram

1.0Clerk FindsCustomer

Row

7.0Mgr Prints

WeeklyTotals(batch)

6.0Clerk Sends

Orderto Cook(paper)

5.0Clerk AddsCustomer

Row

2.0Clerk TakesCustomer

Order(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

Info

PhoneNumber

PhonedCustomer Order

D1Customer Spreadsheet

CustomerRecord

CustomerRecord

CustomerInformation

D2 Customer History DB

D3 Sales Records File

Copy ofOrder Slip

Customer& Order

Info

CustomerHistoryRecord

DeliveryPrintout

Customer

CookCopy of

order slipManagement

Copies ofOrder Slips

Weekly ReportPhone #

Cust.Info.

DeliveryPerson

8.0Mgr Updates

CustomerHistory(nightly)

Copies ofOrder Slips

& Del. Printouts


PhonedCustomer

Order

Another Example

Perfect Pizza: Proposed Physical Level 0 Diagram

1.0System Finds

CustomerRecord

7.0System Prints

WeeklyTotals(batch)

5.0Clerk AddsCustomerRecord

2.0Clerk Enters

CustomerOrder

(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

Info

PhoneNumber


D1 Customer DB

CustomerRecord

CustomerRecord

CustomerInformation


D3 Sales DB

OrderInfo

OrderInfo


DeliveryPrintout

Cook Management

SalesRecords


Cust.Info.

DeliveryPerson

D3 Sales DBOrderInfo

DiscountInfo

Another Example

Perfect Pizza: Partitioned Physical Level 0 Diagram

1.0System Finds

CustomerRecord

7.0System Prints

WeeklyTotals(batch)

5.0Clerk AddsCustomerRecord

2.0Clerk Enters

CustomerOrder

(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

Info

PhoneNumber


D1 Customer DB

CustomerRecord

CustomerRecord

CustomerInformation


D3 Sales DB

OrderInfo

OrderInfo


DeliveryPrintout

Cook Management

SalesRecords


Cust.Info.

DeliveryPerson

D3 Sales DBOrderInfo

DiscountInfo

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

GatherData

2.0

CompileStatistics

Demographic Data

3.0

AnalyzeResponses

SurveyResponses

FinalReport

2.0

VisaAuthorization

2.0

TotalRecords

2.0

QAProcess

2.0

CheckCustomer

Credit

2.0

TotalSales

Records

2.0

InspectFinishedProducts

BETTER

BETTER

BETTER


• 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

StoreCustomer

Data

CustomerInformation

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data


CustomerData Customer

Preferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data


CustomerData

CustomerPreferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data


CustomerData

CustomerPreferences

2.2

ExtractCustomer

Preferences

CustomerData

D1 Customer Data

CustomerData

2.0

StoreCustomer

Data

D1 Customer Data

CustomerData

Customer

CustomerInformation

Customer

0

MedicalBillingSystem

Doctor

Patient

Diagnosis

ServiceInformation

Bill


• 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

2.0

TotalDailySales

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

CustomerOrder

OrderInformation

OrderTotal

2.0

TotalDailySales

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

OrderInformation

OrderTotal

2.0

LookupCustomerRecord

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

CustomerOrder

CustomerAddress

CustomerInformation

2.0

LookupCustomerRecord

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

CustomerOrder

CustomerAddress

1.0

CalculateWeeklySales

DailySales

CumulativeTo-Date

Sales

Data Flow DiagrammingGuidelines

• The inputs to a process are differentfrom the outputs

• Every object in a DFD has a uniquename

1.0

ValidateCustomer

Data

1.0

ValidateCustomer

Data

CustomerData

CustomerData

ValidCustomer

Data

CustomerData

2.0

TakeCustomer

Order

1.0

GetCustomer

Data

3.0

ProcessCustomer

Order

CustomerData

CustomerData

Order

2.0

TakeCustomer

Order

1.0

GetCustomer

Data

3.0

ProcessCustomer

Order

CustomerData

Order

1.0

GetCustomer

Data

2.0

TakeCustomer

Order

3.0

ValidateCustomer

Data

CustomerData

Only if these areexactly the same

CustomerData

Data Flow DiagrammingGuidelines

• A data flow at one level may bedecomposed at a lower level

• All data coming into and out of aprocess must be accounted for

• On low-level DFDs, new data flowscan be added to representexceptional situations

1.0

GetCustomerAddress

CustomerInformation

CustomerAddress

1.2

LookupCustomerAddress

1.1

GetCustomer

Phone

1.3

RequestCustomerAddress

CustomerPhone

CustomerAddress

CustomerPhone

CustomerAddress

1.0

GetCustomerAddress

CustomerInformation

CustomerAddress

1.2

LookupCustomerAddress

1.1

GetCustomer

Phone

1.3

RequestCustomerAddress

CustomerPhone

CustomerAddress

CustomerPhone

CustomerAddress

Invalid PhoneNumber Message

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 thedata elements in that data store

1.0Calculate

GrossPay

D2 Employee Time File

Employee

Employee

D1 Employee Master

D3 Check Reconciliation

D1 Employee Master

2.0Calculate

WithholdingAmount

3.0Calculate

NetPay

4.0Print

EmployeePaycheck

HoursWorked

EmployeeTime

Record

GrossPay

Withholding

NetPay

EmployeeRecord

EmployeeRecord

CheckReconciliation

Record EmployeePaycheck

1.0Calculate

GrossPay

D2 Employee Time File

Employee

Employee

D1 Employee Master

D3 Check Reconciliation

D1 Employee Master

2.0Calculate

WithholdingAmount

3.0Calculate

NetPay

4.0Print

EmployeePaycheck

HoursWorked

EmployeeTime

Record

GrossPay

WithholdingAmount

NetPay

EmployeeRecord

EmployeeRecord

CheckReconciliation

Record

EmployeePaycheck

5.0CreateTime

RecordEmployee

Time Record

Number ofDependents

GrossPay

D4Withholding Tables

WithholdingRates

6.0Reconcile

PayCheck

PaycheckInformation

DFDs and ERDs

• DFDs and ERDs are both used to modelsystems, but they show two very differentperspectives on the system

• A DFD shows what the system does as wellas the data that the system manipulates

• An ERD shows only the data that thesystem 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 makeup the data store and data flows on a DFD

• Relationships on an ERD do not correspond toprocesses on a DFD.

• Sources and sinks on a DFD usually do not showup as entities on an ERD

Example DFD and ERD

Cook Customer

Inventory

PlacesOrder

Name Hours NameAddress

Item Quantity

DFD

Incorrect ERD

Customer

CookInventory

Processing

1.0

TakeOrder

2.0

Convert Orderto CookingInstructions

3.0

Convert Orderto Ingredient

List

ProcessedOrder

D1 Order Log

CookingInstructions

Ingredients

Example DFD and ERD

Customer

CookInventory

Processing

1.0

TakeOrder

2.0

Convert Orderto CookingInstructions

3.0

Convert Orderto Ingredient

List

ProcessedOrder

D1 Order Log

CookingInstructions

Ingredients

Correct ERD

DFDOrder

Item

Ingredient

CookingInstructions

Contains

Includes

Requires

OrderId

Date

Time

ItemId ItemName

StepId Description

Description

ItemQuantity

IngredientQuantity

Index

Data Flow Diagrams - University of Maryland,cseaman/ifsm636/lect0913.pdf · Data Flow Diagrams A...

Documents

Transcript of Data Flow Diagrams - University of Maryland,cseaman/ifsm636/lect0913.pdf · Data Flow Diagrams A...