Process Modeling

Data Flow Diagram

Dr. Jyoti Deshmukh
 Process Modeling Objectives
• Define systems modeling and differentiate logical and physical
models.

• Define process modeling and explain its benefits.

• Recognize and understand basic concepts and constructs of a

process model.

• Read and interpret a data flow diagram.

• Explain when to construct process models and where to store them.

• Construct a context diagram to illustrate a system’s interfaces with

its environment.

• Identify use cases, external and temporal business events.

• Perform event partitioning and organize events in a
functional decomposition diagram.

• Draw event diagrams and merge them into a system

diagram.

• Draw primitive data flow diagrams and describe the

elementary data flows in terms of data structures and
procedural logic.

• Document the distribution of processes to locations.

• Synchronize data and process models using a CRUD

matrix.
 Models: Logical and Physical
Model – a pictorial representation of reality.
Just as a picture is worth a thousand words, most
models are pictorial representations of reality.

Logical model – a Physical model – a

nontechnical pictorial technical pictorial
representation that depicts representation that depicts
what a system is or does. what a system is or does and
Synonyms or essential how the system is
model, conceptual model, implemented. Synonyms are
and business model. implementation model and
technical model.
9-4
 Why Logical System Models
• Logical models remove biases that are the result
of the way the system is currently implemented,
or the way that any one person thinks the
system might be implemented.

• Logical models reduce the risk of missing

business requirements because we are too
preoccupied with technical results.

• Logical models allow us to communicate with

end-users in nontechnical or less technical
languages.
9-5
 Process Modeling and DFDs
Process modeling – a technique used to
organize and document a system’s processes.
– Flow of data through processes
– Logic
– Policies
– Procedures
Data flow diagram (DFD) – a process model
used to depict the flow of data through a system
and the work or processing performed by the
system. Synonyms are bubble chart,
transformation graph, and process model.
– The DFD has also become a popular tool for
business process redesign.
9-6
 Differences Between DFDs
and Flowcharts
• Processes on DFDs can operate in parallel (at-
the-same-time)
– Processes on flowcharts execute one at a time

• DFDs show the flow of data through a system

– Flowcharts show the flow of control (sequence and
transfer of control)

• Processes on a DFD can have dramatically

different timing (daily, weekly, on demand)
– Processes on flowcharts are part of a single program
with consistent timing
9-7
 External Agents
External agent – an outside person, unit,
system, or organization that interacts with a
system. Also called an external entity.
– External agents define the “boundary” or
scope of a system being modeled.
– As scope changes, external agents can
become processes, and vice versa.
– Almost always one of the following:
Gane and Sarson shape
• Office, department, division.
• An external organization or agency.
• Another business or another
information system.
• One of system’s end-users or managers
DeMarco/Yourdon shape
– Named with descriptive, singular noun
9-8
 Data Stores
Data store – stored data intended for later
use. Synonyms are file and database.
– Frequently implemented as a file or database.
– A data store is “data at rest” compared to a data
flow that is “data in motion.”
– Almost always one of the following:
• Persons (or groups of persons)
• Places
• Objects
• Events (about which data is captured) Gane and Sarson shape
• Concepts (about which data is important)
– Data stores depicted on a DFD store
all instances of data entities
(depicted on an ERD)
– Named with plural noun
9-9
DeMarco/Yourdon shape
 Process Concepts
Process – work performed by a system in
response to incoming data flows or
conditions. A synonym is transform.
– All information systems include
processes - usually many of them
– Processes respond to business
events and conditions and transform Gane and Sarson shape
data into useful information
– Modeling processes helps us to understand the
interactions with the system's environment, other
systems, and other processes.
– Named with a strong action verb followed by object
clause describing what the work is performed on/for .
9-10
 Process Decomposition
Decomposition – the act of breaking a system
into sub-components. Each level of abstraction
reveals more or less detail.

9-11
 Decomposition
diagram:
a tool used to
depict the
decomposition of
a system. Also
called hierarchy
chart.

9-12
 Types of Logical Processes
Function – a set of related and ongoing activities of a
business.
– A function has no start or end.

Event – a logical unit of work that must be completed as

a whole. Sometimes called a transaction.
– Triggered by a discrete input and is completed when process
has responded with appropriate outputs.
– Functions consist of processes that respond to events.

Elementary process – a discrete, detailed activity or

task required to complete the response to an event. Also
called a primitive process.
– The lowest level of detail depicted in a process model.

9-13
 Data Flows & Control Flows
Data flow – data that is input to or
output from a process.
– A data flow is data in motion Data flow name
– A data flow may also be used to
represent the creation, reading, deletion,
or updating of data in a file or database
(called a data store).
Composite data flow – a data flow
that consists of other data flows.
Control flow name
Control flow – a condition or
nondata event that triggers a
process.
– Used sparingly on DFDs.
9-14
 Composite and Elementary
Data Flows

Composite
flow

Elementary
flows

Junction indicates that

any given order is an
instance of only one of
9-15 the order types.
 Data Conservation
Data conservation – the practice of
ensuring that a data flow contains only
data needed by the receiving process.
– Sometimes called starving the processes.
– New emphasis on business process
redesign to identify and eliminate
inefficiencies.
– Simplifies the interface between those
processes.
– Must precisely define the data composition
of each data flow, expressed in the form of
data structures.
9-16
 Data Structures
Data attribute – the smallest piece of data that
has meaning to the users and the business.

Data structure – a specific arrangement of data

attributes that defines an instance of a data flow.
• The data attributes that comprise a data flow are
organized into data structures.
• Data flows can be described in terms of the following
types of data structures:
– A sequence or group of data attributes that occur one after
another.
– The selection of one or more attributes from a set of attributes.
– The repetition of one or more attributes.
9-17
 Data Structure for a Data Flow
DATA STRUCTURE ENGLISH ENTERPRETATION

ORDER= An instance of ORDER consists of:

ORDER NUMBER + ORDER NUMBER and
ORDER DATE and
ORDER DATE+ Either PERSONAL CUSTOMER NUMBER
[ PERSONAL CUSTOMER NUMBER, or CORPORATE ACCOUNT
CORPORATE ACCOUNT NUMBER
NUMBER]+ and SHIPPING ADDRESS (which is
SHIPPING ADDRESS=ADDRESS+ equivalent to ADDRESS)
(BILLING ADDRESS=ADDRESS)+ and optionally: BILLING ADDRESS
1 {PRODUCT NUMBER+ (which is equivalent to
ADDRESS)
PRODUCT DESCRIPTION+ and one or more instances of:
QUANTITY ORDERED+ PRODUCT NUMBER and
PRODUCT PRICE+ PRODUCT DESCRIPTION and
PRODUCT PRICE SOURCE+ QUANTITY ORDERED and
EXTENDED PRICE } N+ PRODUCT PRICE and
SUM OF EXTENDED PRICES+ PRODUCT PRICE SOURCE and
PREPAID AMOUNT+ EXTENDED PRICE
and SUM OF EXTENDED PRICES and
(CREDIT CARD PREPAID AMOUNT and
NUMBER+EXPIRATION DATE) optionally: both CREDIT CARD NUMBER
(QUOTE NUMBER) and EXPIRATION DATE

ADDRESS= An instance of ADDRESS consists of:

(POST OFFICE BOX NUMBER)+ optionally: POST OFFICE BOX NUMBER
STREET ADDRESS+ and
STREET ADDRESS and
CITY+ CITY and
[STATE, MUNICIPALITY]+ Either STATE or MUNICIPALITY
(COUNTRY)+ and optionally: COUNTRY
9-18 POSTAL CODE and POSTAL CODE
 Data Structure Constructs
Format by Example English Interpretation
Data Structure
(relevant portion is boldfaced (relevant portion is boldfaced)
Sequence of Attributes - The WAGE AND TAX STATEMENT= An instance of WAGE AND TAX
sequence data structure indicates TAXPAYER IDENTIFICATION STATEMENTS consists of:
one or more attributes that may NUMBER+ TAXPAYER IDENTIFICATION
(or must) be included in a data TAXPAYER NAME+ NUMBER and
flow. TAXPAYER ADDRESS+ TAXPAYER NAME and
WAGES, TIPS, AND TAXPAYER ADDRESS and
COMPENSATION+ WAGES, TIPS AND
FEDERAL TAX WITHHELD+… COMPENSATION and
FEDERAL TAX WITHHELD
and…

Selection of Attributes - The ORDER= An instance or ORDER consists

selection data structure allows (PERSONAL CUSTOMER of:
you to show situations where NUMBER, Either PERSONAL
different sets of attributes CORPORATE ACCOUNT CUSTOMER NUMBER or
describe different instances of the NUMBER)+ CORPORATE
data flow. ORDER DATE+… ACCOUNT NUMBER; and
ORDER DATE and…
9-19
 Data Structure Constructs (continued)
Data Structure Format by Example English Interpretation
(relevant portion is boldfaced (relevant portion is boldfaced)

Repetition of Attributes - The POLICY NUMBER+ An instance of CLAIM consists of:

repetition data structure is used to POLICYHOLDER NAME+ POLICY NUMBER and
set off a data attribute or group of POLICY HOLDER ADDRESS+ POLICYHOLDER NAME and
data attributes that may (or must) 0 {DEPENDENT NAME+ POLICYHOLDER ADDRESS
repeat themselves a specific DEPENDENT’S and
number of time for a single RELATIONSHIP} N+ zero or more instance of:
instance of the data flow. 1 {EXPENSE DESCRIPTION+ DEPENDENT NAME and
The minimum number of SERVICE PROVIDER+ DEPENDENT’S
repetitions is usually zero or one. EXPENSE AMOUNT} N RELATIONSHIP and
The maximum number of one or more instances of:
repetitions may be specified as “n” EXPENSE DESCRIPTION
meaning “many” where the actual and
number of instances varies for SERVICE PROVIDER and
each instance of the data flow. EXPENSE ACCOUNT

9-20
 Data Structure Constructs (concluded)
Data Structure Format by Example English Interpretation
(relevant portion is boldfaced (relevant portion is boldfaced)
Optional Attributes - The CLAIM= An instance of CLAIM consists of:
optional notation indicates that an POLICY NUMBER+ POLICY NUMBER and
attribute, or group of attributes in POLICYHOLDER NAME+ POLICYHOLDER NAME and
a sequence or selection date POLICYHOLDER ADDRESS+ POLICYHOLDER ADDRESS
structure may not be included in ( SPOUSE NAME+ and
all instances of a data flow. DATE OF BIRTH)+… optionally, SPOUSE NAME
Note: For the repetition data and
structure, a minimum of “zero” is DATE OF BIRTH and…
the same as making the entire
repeating group “optional.”

Reusable Attributes - For groups DATE= Then, the reusable structures can
of attributes that are contained in MONTH+ be included in other data flow
many data flows, it is desirable to DAY+ structures as follows:
create a separate data structure YEAR+ ORDER=ORDER
that can be reused in other data NUMBER…+DATE
structures. INVOICE=INVOICE
NUMBER…+DATE
PAYMENT=CUSTOMER
NUMBER…+DATE
9-21
 Data Types and Domains
Data attributes should be defined by data
types and domains.

Data type - a class of data that be stored

in an attribute.
– Character, integers, real numbers, dates,
pictures, etc.

Domain – the legitimate values for an

attribute.
9-22
 Diverging and Converging
Data Flows
Diverging data flow – a data flow that splits
into multiple data flows.
– Indicates data that starts out naturally as one flow,
but is routed to different destinations.
– Also useful to indicate multiple copies of the same
output going to different destinations.

Converging data flow – the merger of multiple

data flows into a single packet.
– Indicates data from multiple sources that can (must)
come together as a single packet for subsequent
9-23 processing.
 Diverging and Converging
Data Flows

9-24
 When to Draw Process Models
• Strategic systems planning
– Enterprise process models illustrate important
business functions.
• Business process redesign
– “As is” process models facilitate critical analysis.
– “To be” process models facilitate improvement.
• Systems analysis (our primary focus)
– Model existing system including its limitations
– Model target system’s logical requirements
– Model candidate technical solutions
– Model the target technical solution
9-25
 Creating Data Flow Diagrams
Steps:

1. Create a list of activities

2. Construct Context Level DFD
(identifies external entities and processes)
3. Construct Level 0 DFD
(identifies manageable sub process )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
5. Check against rules of DFD
 DFD Naming Guidelines

• External Entity → Noun

• Data Flow → Names of data
• Process → verb phrase
– a system name
– a subsystem name
• Data Store → Noun
Creating Data Flow Diagrams
Lemonade Stand Example
 Creating Data Flow Diagrams
Example Steps:
The operations of a simple 1. Create a list of activities
lemonade stand will be used
• Old way: no Use-Case Diagram
to demonstrate the creation
of dataflow diagrams. • New way: use Use-Case Diagram
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 0 DFD
(identifies manageable sub processes )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Think through the activities

that take place at a lemonade
stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Also think of the additional

activities needed to support
the basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Group these activities in

some logical fashion,
possibly functional areas.
Customer Order
Serve Product
Collect Payment

Produce Product
Store Product

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 2. Construct Context Level DFD
(identifies sources and sink)
Create a context level
diagram identifying the
Context Level DFD
sources and sinks (users).
Sales Forecast
Order 0.0
CUSTOMER Lemonade Production Schedule EMPLOYEE
Customer Order Product Served System Pay
Serve Product Payment Time Worked
Collect Payment Received Goods
Payment
Purchase Order
Produce Product
Store Product VENDOR

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 3. Construct Level 0 DFD
Create a level 0 diagram (identifies manageable sub processes )
identifying the logical Level 0 DFD
subsystems that may exist.
1.0
Sale
Customer Order Sales Forecast
Customer Order
Product Ordered
Serve Product
Payment
Collect Payment 2.0 Production
CUSTOMER EMPLOYEE
Production Schedule
Product Served
Produce Product
Received Goods Inventory
Store Product
3.0
VENDOR Procure- Order
Purchase Order
Order Raw Materials ment Decisions
Pay for Raw Materials Payment
Pay Time Worked

Pay for Labor 4.0

Payroll
 Creating Data Flow Diagrams
Example 4. Construct Level 1- n DFD
Create a level 1 (identifies actual data flows and data stores )
decomposing the processes Level 1 DFD
in level 0 and identifying
CUSTOMER
data stores.
Customer Order
ORDER
Request for Forecast
Customer Order
1.1
Serve Product Record
Collect Payment Order 1.3
Produce
Severed Order Sales
Produce Product Payment Forecast
Sales Forecast
Store Product
1.2
Receive PAYMENT
Payment
Order Raw Materials
Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying
Product Order
data stores.
ORDER
Customer Order 2.1
Serve Quantity Severed
Serve Product Product
Collect Payment RAW
Production
MATERIALS
Schedule
Produce Product 2.2
Store Product Produce Quantity Used
Product

INVENTORTY
Order Raw Materials Production Data
Pay for Raw Materials
2.3 Quantity Produced &
Store Location Stored
Pay for Labor Product
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying Order Decision
PURCHASE
data stores. 3.1 ORDER
Produce
Purchase
Customer Order Order Quantity On-Hand
Serve Product RAW
Quantity MATERIALS
Collect Payment Received Received
Goods
3.2
Produce Product Receive
Items
Store Product RECEIVED
ITEMS
Payment Approval
Order Raw Materials
VENDOR
Pay for Raw Materials 3.3
Pay
Vendor
Pay for Labor
Payment
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1
decomposing the processes Level 1 DFD
in level 0 and identifying Time Worked

data stores. 4.1 TIME CARDS

Record
Time
Customer Order Worked Employee ID
Serve Product EMPLOYEE
Collect Payment
Payroll Request
4.2
Unpaid time cards
Produce Product Calculate
Payroll
Store Product PAYROLL

Payment Approval
Order Raw Materials
4.3
Pay for Raw Materials Pay
Employe
e PAYMENTS
Pay for Labor
Payment
 Process Decomposition
1.1 1.2
1.0
Record Receive
Sale
Order Payment

2.1 2.2 2.3

2.0
Serve Produce Store
Production
Product Product Product

0.0
Lemonade
System 3.1
3.0 3.2 3.3
Produce
Procure- Receive Pay
Purchase
ment Items Vendor
Order

4.1 4.3
4.2
4.0 Record Pay
Calculate
Payroll Time Employe
Payroll
Worked e

Context Level Level 0 Level 1

 Rules for Data Flows
• A data flow
should never go
unnamed.
• In logical
modeling, data
flow names
should describe
the data flow
without
describing the
implementation
• All data flows
must begin
and/or end at a
process.

9-40
 Common Process Errors on DFDs

9-41
 Data
Flows to
and from
Data
Stores

9-42
 DFD Example: Bus Garage Repairs
• Buses come to a garage for repairs.
• A mechanic and helper perform the repair,
record the reason for the repair and record the
total cost of all parts used on a Shop Repair
Order.
• Information on labor, parts and repair outcome
is used for billing by the Accounting Department,
parts monitoring by the inventory management
computer system and a performance review by
the supervisor.
 DFD Example: Bus Garage Repairs
(cont’d)
• External Entities: Bus, Mechanic, Helper,
Supervisor, Inventory Management System,
Accounting Department, etc.
• Key process (“the system”): performing repairs
and storing information related to repairs
• Processes:
– Record Bus ID and reason for repair
– Determine parts needed
– Perform repair
– Calculate parts extended and total cost
– Record labor hours, cost
 DFD Example: Bus Garage Repairs
(cont’d)
• Data stores:
– Personnel file
– Repairs file
– Bus master list
– Parts list
• Data flows:
– Repair order
– Bus record
– Parts record
– Employee timecard
– Invoices
CSUB Burger’s Order Processing System

• Draw the CSUB Burger’s context diagram

– System
• Order processing system

– External entities
• Kitchen
• Restaurant
• Customer

– Processes
• Customer order
• Receipt
• Food order
• Management report