Data Flow Diagram.pdf

Running ExampleCourse Registration: Current Logical Level 0 Diagram1.0RegisterStudent for Course D1 Student Class Records D2 Student Payments 2.0CollectStudent Fee Payment 3.0Produce Stu

Data Flow Diagrams

A structured analysis technique that employsa set of visual representations of the data thatmoves through the organization, the paths

through which the data moves, and the

processes that produce, use, and transformdata.

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 architectureor high-level design

• Child diagrams - increasing levels of detail

• Primitive diagrams - lowest level ofdecomposition

• 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 ExampleCourse Registration: Context level Diagram

0CourseRegistration

System

Student

RegistrarProfessor

Class RequestPaymentReceiptStudent 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 ExampleCourse Registration: Current Logical Level 0 Diagram

1.0RegisterStudent for

Course

D1 Student Class Records

D2 Student Payments

2.0CollectStudent Fee

Payment

3.0Produce

StudentSchedule

4.0Produce

ClassRoster

5.0ProduceEnrollment

Report

PaymentInformationStudent and

Course Data

StudentClass Record

Student Class Record Student Class Record

Student Class Record

Student Schedule Class Roster Enrollment

Report

Student

Class Request

ReceiptPayment

Running ExampleCourse Registration: Current Logical Child Diagram

1.2Check

forAvailability1.1

CheckPrerequisites

Met

1.3EnrollStudentin Class

D1 Student Class RecordsD5 Course Catalogue

Available Seats

StudentRecord

Course Record

Studentand Course

DataError

Error

Physical DFDs

• Start with a set of child diagrams or withlevel 0 diagram

• Add implementation details

– indicate manual vs automated processes– describe form of data stores and data flows– extra processes for maintaining data

Running ExampleCourse Registration: Current Physical Child Diagram

1.2Check

forAvailability(myUMBC)1.1

CheckPrerequisites

Met(manual)

1.3EnrollStudentin Class(STARS)

D1 Semester Enrollment DBD5 Course Catalogue (text)

D4 Department Student File

D3 Semester Schedule DB

Class Request Advisement

Authorization

Feasible ClassRequestAvailable Seats

Available Seats

Studentand Course

DataStudent Notified

(verbally)

UnavailabilityMessageStudent

File

Course Description

Running ExampleCourse Registration: Proposed Physical Child Diagram

1.2Check

forAvailability(automated)1.1

CheckPrerequisites

Met(automated)

1.3EnrollStudentin Class(automated)

D1 Semester Enrollment DBD5 Course Catalogue DB

Available Seats

Studentand Course

DataStudent Notified

(email)

StudentEmailedStudent

Record

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 ExampleCourse Registration: Physical diagram (partitioned)

1.2Check

forAvailability(automated)1.1

CheckPrerequisites

Met(automated)

1.3EnrollStudentin Class(automated)

D1 Semester Enrollment DBD5 Course Catalogue DB

Available Seats

Studentand Course

DataStudent Notified

(email)

StudentEmailedStudent

Record

Course Record

Another ExamplePerfect Pizza: Context Level Diagram

0Customer

OrderSystem

Customer

CookManagement

Phone NumberCustomer Order

Customer Info

DeliveryInformation

WeeklyReport

Cook Order

DeliveryPerson

Another ExamplePerfect Pizza: Current Logical Level 0 Diagram

1.0FindCustomer

Record

7.0PrintWeekly

Totals

6.0SendOrderto Cook

5.0AddCustomer

Record

2.0TakeCustomer

Order

3.0PrintDelivery

Order

Customer

CustomerInfo

PhoneNumber

Customer Order

D1 Customer MasterCustomer

Record

CustomerRecord

CustomerInformation

D2 Customer History

D3 Sales RecordsOrder

Information

OrderInformation

CustomerHistory

DeliveryInformation

Customer

CustomerOrder

Cook

CookOrder

Management

Sales InfoWeekly Report

DiscountInfo

DeliveryPerson

Another ExamplePerfect Pizza: Current Logical Child Diagram

3.1Determine

Customer

RecordDiscount3.3

PrintDeliveryInstructionsOrder

Information

DiscountAmount

DeliveryInformation

D2 Customer History

D3 Sales Records

CustomerHistory

DiscountInformationCustomer

Information

Another ExamplePerfect Pizza: Current Logical Child Diagram

5.1RecordCustomerInformation

5.2StoreCustomer

Record

D1Customer Master

Customer Information Raw

CustomerInformation

CustomerRecord

Another ExamplePerfect Pizza: Physical Child Diagram

5.3Clerk VisuallyConfirmsCust Info.5.1

Clerk TypesCustomerInformation

5.2SystemValidatesCustomerInformation

5.4FormatCustomer

RecordPhoned

CustomerInformation

RecordedCustomerInformation

Valid CustomerInformationSyntax

Errors

CancelledTransaction

New CustomerInformationD1 Customer DB

CustomerRecordPhone

Number

Another ExamplePerfect Pizza: Current Physical Level 0 Diagram

1.0Clerk Finds

CustomerRow

7.0Mgr Prints

WeeklyTotals(batch)

6.0Clerk Sends

Orderto Cook

(paper)5.0

Clerk AddsCustomer

Row

2.0Clerk Takes

CustomerOrder(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

InfoPhoneNumber

PhonedCustomer Order

D1Customer SpreadsheetCustomer

Record

CustomerRecord

CustomerInformation

InfoCustomer

HistoryRecord

DeliveryPrintout

Customer

Cook

Copy oforder slip

Management

Copies ofOrder Slips

Weekly ReportPhone #

Cust.Info

DeliveryPerson

8.0Mgr Updates

CustomerHistory(nightly)Copies of

Order Slips& Del Printouts

CustomerHistoryRecord

PhonedCustomer

Order

Another ExamplePerfect Pizza: Proposed Physical Level 0 Diagram

1.0System Finds

CustomerRecord

7.0System Prints

WeeklyTotals(batch)5.0

Clerk AddsCustomer

Record

2.0Clerk Enters

CustomerOrder(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

InfoPhoneNumber

PhonedCustomer Order

D1 Customer DB

CustomerRecord

CustomerRecord

CustomerInformation

D2 Customer History DB

D3 Sales DBOrder

Info

OrderInfo

CustomerHistoryRecord

DeliveryPrintout

CookManagement

SalesRecords

Weekly ReportPhone #

Cust.Info

DeliveryPerson

D3 Sales DBOrder

Info

DiscountInfo

Another ExamplePerfect Pizza: Partitioned Physical Level 0 Diagram

1.0System Finds

CustomerRecord

7.0System Prints

WeeklyTotals(batch)5.0

Clerk AddsCustomer

Record

2.0Clerk Enters

CustomerOrder(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

InfoPhoneNumber

PhonedCustomer Order

D1 Customer DB

CustomerRecord

CustomerRecord

CustomerInformation

D2 Customer History DB

D3 Sales DBOrder

Info

OrderInfo

CustomerHistoryRecord

DeliveryPrintout

CookManagement

SalesRecords

Weekly ReportPhone #

Cust.Info

DeliveryPerson

D3 Sales DBOrder

Info

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

GatherData

2.0

CompileStatisticsDemographic

Data

3.0

AnalyzeResponsesSurvey

Responses

FinalReport

2.0

TotalRecords

2.0

QAProcess

2.0CheckCustomer

Credit

2.0

TotalSalesRecords

2.0

InspectFinishedProductsBETTER

BETTER

BETTER

Data Flow Diagramming Rules

• Data stores and sources/sinks

– no data flows between two data stores; must bea process in between

– no data flows between a data store and a sourceor 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

DataCustomer

Information

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.1StoreCustomer

DataCustomer

Information

D1 Customer Data

D2 Customer PreferencesCustomer

DataCustomer

Preferences

DataCustomer

Information

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.1StoreCustomer

DataCustomer

Information

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.2ExtractCustomerPreferencesCustomer

Data

D1 Customer Data

CustomerData

2.0StoreCustomer

Data

D1 Customer Data

CustomerDataCustomer

CustomerInformationCustomer

BillingSystemDoctor

PatientDiagnosis

ServiceInformation

Bill

Data Flow Diagramming Rules

1.0TakeCustomer

Order

3.0PrintDeliveryInstructionsCustomer

OrderOrderInformationOrder

Total

2.0TotalDailySales

1.0TakeCustomer

Order

3.0PrintDeliveryInstructionsOrder

InformationOrder

Total

Record1.0

TakeCustomer

Order

3.0PrintDeliveryInstructionsCustomer

Order

CustomerAddress

CustomerInformation

2.0LookupCustomer

Record1.0

TakeCustomer

Order

3.0PrintDeliveryInstructionsCustomer

Order

CustomerAddress

WeeklySalesDaily

Sales

CumulativeTo-Date

Sales

Data Flow Diagramming

Data

1.0ValidateCustomer

DataCustomer

Data

CustomerData

ValidCustomer

DataCustomer

Data

Order1.0

GetCustomer

Data

3.0ProcessCustomer

OrderCustomer

Data

CustomerDataOrder

2.0TakeCustomer

Order1.0

GetCustomer

Data

3.0ProcessCustomer

OrderCustomer

Data

Order

Data

2.0TakeCustomer

Order

3.0ValidateCustomer

DataCustomer

Data

Only if these are

exactly the same

CustomerData

Data Flow Diagramming

AddressCustomer

Information

CustomerAddress

1.2LookupCustomer

Address1.1

GetCustomer

Phone

1.3RequestCustomer

AddressCustomer

Phone

CustomerAddress

CustomerPhone

CustomerAddress

AddressCustomer

Information

CustomerAddress

1.2LookupCustomer

Address1.1

GetCustomer

Phone

1.3RequestCustomer

AddressCustomer

Phone

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

GrossPayD2 Employee Time File

Employee

EmployeeD1 Employee Master

D3 Check ReconciliationD1 Employee Master

2.0CalculateWithholding

Amount

3.0Calculate

NetPay4.0

PrintEmployee

PaycheckHours

Worked

EmployeeTimeRecord

GrossPay

Withholding

NetPayEmployee

Record

EmployeeRecordCheck

Reconciliation

Paycheck

GrossPayD2 Employee Time File

Employee

EmployeeD1 Employee Master

D3 Check ReconciliationD1 Employee Master

2.0CalculateWithholding

Amount

3.0Calculate

NetPay4.0

PrintEmployee

PaycheckHours

Worked

EmployeeTimeRecord

GrossPay

WithholdingAmount

NetPayEmployee

Record

EmployeeRecord

CheckReconciliation

Record

EmployeePaycheck5.0

CreateTimeRecord

EmployeeTime 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

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 dataelements (listed in the data dictionary) that makeup 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 showup as entities on an ERD

Example DFD and ERD

CookCustomer

InventoryPlaces

TakeOrder

2.0Convert Order

to CookingInstructions

3.0Convert Order

to IngredientListProcessed

Order

D1 Order LogCooking

Instructions Ingredients

Example DFD and ERD

Customer

Cook Inventory

Processing1.0

TakeOrder

2.0Convert Order

to CookingInstructions

3.0Convert Order

to IngredientListProcessed

Order

D1 Order LogCooking

Instructions Ingredients

Correct ERDDFD

Order

Item

Ingredient

CookingInstructionsContains

Includes

RequiresOrderId

IngredientQuantity

Index