Data Flow Diagramming Rules Processes –a process must have at least one input –a process must...

Preview:

Citation preview

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

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

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

Practice

• Develop a context diagram for a college course registration system

Course Registration: Context level Diagram

0

CourseRegistration

System

Student

Registrar

Professor

Class 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

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

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

Course Registration: Proposed Physical Child Diagram

1.2

Checkfor

Availability(automated)

1.1

CheckPrerequisites

Met(automated)

1.3

EnrollStudentin Class

(automated)

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

D3 Semester Schedule DB

Class Request AuthorizedClass Request

Valid ClassRequest

Available Seats

Available Seats

Studentand Course

Data

Student Notified(email)

StudentEmailed

StudentRecord

Course Record

Course Registration: Current Physical Child Diagram

1.2

Checkfor

Availability(Banner)

1.1

CheckPrerequisites

Met(Banner)

1.3

EnrollStudentin Class(Banner)

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

Practice

• Develop a context diagram for a pizza place (SUNYIT Pizza) that delivers

SUNYIT Pizza: Context Level Diagram

0

CustomerOrder

System

Customer

Cook

Management

Phone Number

Customer Order

Customer Info

DeliveryInformation

WeeklyReport

Cook OrderDeliveryPerson

SUNYIT 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

SUNYIT Pizza: Current Logical Child Diagram

3.1

DetermineCustomerDiscount

3.2

RecordDiscount

3.3

PrintDelivery

Instructions

OrderInformation

DiscountAmount

DeliveryInformation

D2 Customer History

D3 Sales Records

CustomerHistory

DiscountInformation

CustomerInformation

SUNYIT Pizza: Current Logical Child Diagram

5.1

RecordCustomer

Information

5.2

StoreCustomer

Record

D1 Customer Master

Customer Information RawCustomer

Information

CustomerRecord

SUNYIT 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

SUNYIT 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 of

Order Slips& Del. Printouts

CustomerHistoryRecord

PhonedCustomer

Order

SUNYIT Pizza: Proposed Physical Level 0 Diagram

1.0System Finds

CustomerRecord

7.0System Prints

WeeklyTotals(batch)

5.0Clerk AddsCustomer

Record

2.0Clerk Enters

CustomerOrder

(by phone)

3.0System Prints

DeliveryOrder

Customer

PhonedCustomer

Info

PhoneNumber

PhonedCustomer Order

D1 Customer DB

CustomerRecord

CustomerRecord

CustomerInformation

D2 Customer History DB

D3 Sales DB

OrderInfo

OrderInfo

CustomerHistoryRecord

DeliveryPrintout

Cook Management

SalesRecords

Weekly ReportPhone #

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

StoreCustomer

Data

CustomerInformation

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data

D2 Customer Preferences

CustomerData Customer

Preferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data

D2 Customer Preferences

CustomerData

CustomerPreferences

2.1

StoreCustomer

Data

CustomerInformation

D1 Customer Data

D2 Customer Preferences

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

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

LookupCustomer

Record

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

CustomerOrder

CustomerAddress

CustomerInformation

2.0

LookupCustomer

Record

1.0

TakeCustomer

Order

3.0

PrintDelivery

Instructions

CustomerOrder

CustomerAddress

1.0

CalculateWeekly

Sales

DailySales

CumulativeTo-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

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 are exactly the same

CustomerData

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

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

1.0

CalculateGrossPay

D2 Employee Time File

Employee

Employee

D1 Employee Master

D3 Check Reconciliation

D1 Employee Master

2.0

CalculateWithholding

Amount

3.0

CalculateNetPay

4.0

PrintEmployeePaycheck

HoursWorked

EmployeeTime

Record

GrossPay

Withholding

NetPay

EmployeeRecord

EmployeeRecord

CheckReconciliation

Record EmployeePaycheck

1.0

CalculateGrossPay

D2 Employee Time File

Employee

Employee

D1 Employee Master

D3 Check Reconciliation

D1 Employee Master

2.0

CalculateWithholding

Amount

3.0

CalculateNetPay

4.0

PrintEmployeePaycheck

HoursWorked

EmployeeTime

Record

GrossPay

WithholdingAmount

NetPay

EmployeeRecord

EmployeeRecord

CheckReconciliation

Record

EmployeePaycheck

5.0

CreateTime

RecordEmployee

Time Record

Number ofDependents

GrossPay

D4Withholding Tables

WithholdingRates

6.0

ReconcilePay

Check

PaycheckInformation

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

Cook Customer

Inventory

PlacesOrder

Name Hours Name

Address

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

Recommended