CSE1204 - Information Systems 1
Process Modelling
Data Flow Diagrams
Process Modelling
Process modelling aims to graphically
represent the processes which capture,
manipulate, store
and distribute data.
•
•
•
•
data flow diagrams
function decomposition
structured English
decision tables and decision
trees
Data flow Diagrams
Data flow diagrams model the flow of data into, through,
and out of an information system:
• show the processes that change or transform
data
• show the movement of data between
processes
• represent a system as a network of
processes which transform data flowing
between them
1
Example DFD
DFDs fit neatly onto a single page
• the user is not overwhelmed by a DFD
WAREHOUSE
ORDERS
invalid orders
CUST OMERS
shipping details
order details
1.
RECEIVE
ORDER
orders
books
2.
SHIP
BOOKS
c ustomer name,
c ustomer address
CUST OMERS
billing information
c ustomer name,
c ustomer address
books
INVOICES
c ustomer name,
invoic e details
3.
COLLECT
PAYMENT S
invoic es, statements
CUST OMERS
payments,
enquiries
Data Flow Diagrams
Data flow diagrams (or DFDs):
•
•
•
•
a well-known process modelling technique
easily understood
a good communication tool
model both manual and automated processes
Components of a DFD
2
1.
Process
calculate
price
2.
Data flow
loan application
3.
Data store
Products
4.
External agent
Suppliers
(Source/Sink)
2
1. Process
• transforms incoming data flows into outgoing
flows:
the work performed on data which changes it
data
• each process has a unique number and name
2
calculate
price
1. Process
• name each process using a verb and a noun phrase
eg.
calculate price
check customer details
accept supplier delivery
• the name of a process should describe what the
process does
• avoid vague names where possible
e.g.
"process data"
2. Data Flow
• a data flow represents data in motion, moving from one
place in the system to another
• describes a "packet" of data or data that moves
together:
a data flow may consist of many individual, related
pieces of data that move together to a common
destination
loan application
3
• name each data flow using a noun or noun phrase
eg. customer order
• the name of a data flow should describe the contents of the
data "packet"
• the name should include as much information as possible
about the data flow eg."customer payment" rather than just "payment"
customer order
2
validate
customer
order
valid customer
order
invalid
customer order
3. Data Store
• a data store represents a collection of data flows "at
rest"
• each data store has a unique name
• the name should describe the contents of the
data store
• a data store may represent many different types of
physical locations of data
• a data store may be a temporary or a permanent
repository of data
The Data Store
different notations
4
data flows to and from a data store can remain unlabelled
if all attributes in the store are moving,
i.e. if an entire data packet (or packets) is going into
or out of the data store
2
sales order
check
sales
order
Sales orders
3
produce
weekly
sales
totals
weekly sales
totals
4. External Agent (Source/Sink)
• an external agent represents an entity with which the system
communicates and which is outside the scope of the system
eg.
an outside organisation or individual,
another department or another system,
a person or group within the department supported by the system who
interacts with the system
• an external agent is a source if it is an origin of data coming
into the system
• an external agent is a sink if it is a destination of data leaving
the system
Suppliers
4. External Agent (Source/Sink)
• data flows connecting the external agents to the
processes within the system represent the interface
between the system and its environment
• external agents are outside the system and define its
boundaries
• an external agent may be both a source and a sink
what a sink does with data it receives from the system and how a
source produces data which it inputs to the system are outside the
boundary of the system and are not shown on the data flow
diagram
5
Example DFD
sales order
Sales Order
System
purchase order
Suppliers
goods returned
goods unavailable
notice
Inventory
System
shipping slip
supplier delivery
checked supplier
invoice
Warehouse
Accounts
Department
Example Data Flow Diagram
Customers
sales order
1
check
sales
order
Suppliers
Sales orders
2
produce
purchase
order
purchase order
Guidelines for Drawing DFDs
• each object on a data flow diagram must have a unique name
• each process must have at least one data flow coming in
(input) and at least one data flow going out (output)
• the inputs to a process are different from the outputs of that
process
• a process must be able to build its outputs using only the
information in its input data flows plus any constant
information
6
Guidelines for Drawing DFDs
data flows are permitted:
• between processes
• from a data store to a process
• from a process to a data store
• from a source to a process
• from a process to a sink
Guidelines for Drawing DFDs
data flows are NOT permitted:
•
between external agents
•
between data stores
•
from an external agent to a data store
Identify six errors in this abstract DFD
Data Store 2
EE1
Data store 1
1
process2
EE2
2
EE3
Process1
7
Levelling Data Flow Diagrams
Any "real" system is too large to represent as a single data
flow diagram
•
the solution is to decompose the system into a hierarchy
of levels of processing
•
the process model of the system then consists of a set of
levelled data flow diagrams
•
levelling of DFDs improves their readability and
usefulness as a communication tool
Levelling of DFDs
Levelling creates a hierarchical decomposition
of the processing within the system
Context diagram
• Level 0 diagram
Level 1 diagrams
Level 2 diagrams
.
.
.
Level n diagrams
Levelling of DFDs
Context diagram
Level 0 diagram
Level 1
diagrams
Level 2 1.1.1
diagrams
1.1
1.1.2
1
1.2
2
1.3
2.1
3
2.2
3.1
4
3.2
3.2.1
4.1
4.2
4.3
3.2.2
8
Context Diagram
• the highest level data flow diagram is the context diagram
• the context diagram shows the interaction of the system with its environment
in terms of data flows
• the context diagram defines the boundary of the system (the scope of the
system)
• only the data flows which leave the system and the data flows which come from
outside the system are shown
Context Diagram
• the entire system is represented as a single process
• all external agents (sources and sinks) are shown
• no data stores are shown: they are inside the boundary of the system
EASY GO
HOTEL
Example Context Diagram
sales order
Sales Order
System
purchase order
Suppliers
goods returned
goods unavailable
notice
shipping slip
Warehouse
Inventory
System
supplier delivery
checked supplier
invoice
Accounts
Department
9
Level Zero Diagram
• the level zero data flow diagram is the diagram at the level
immediately below the context diagram
• it "expands" the single process on the context diagram to show the
major, high-level processes (or functions) within the system
4.0
1.0
2.0
3.0
Level Zero Diagram
• all external agents (sources and sinks) are included
because the level zero diagram, like the context
diagram, represents the entire system
• the number of each process ends in .0 which
corresponds to the level of the diagram:
e.g.
1.0, 2.0, 3.0 etc.
often just 1, 2, 3 etc. are used
Example Level Zero Diagram
Order Entry
System
purchase order
Suppliers
sales order
2.0
Monitor
Stock
levels
3.0
1.0
out of stock
notice
Fill
Sales
Orders
Accept
Deliveries
supplier
delivery
Stock file
shipping slip
Warehouse
checked supplier
invoice
Accounts
Department
10
Level 1 and lower level diagrams
each Level 1 diagram and diagrams at lower levels (e.g. Level 2,
Level 3) show only a part of the processing
Level 1 processes are numbered 1.1, 1.2, 1.3, and 2.1, 2.2, 2.3 etc
that part is shown in more detail than on the Level zero diagram
no external agents are shown on a Level 1 or lower diagrams, as
the entire system is not being represented
Level 1 diagrams
a set of data flow diagrams is created at Level 1
there is one Level 1 diagram for each of the processes at Level zero
each diagram decomposes a Level zero process into several processes
2.4
2.1
2.3
2.5
2.2
Levelling DFDs
1
2
Context diagram
3
Level zero diagram
2.1
3.1
2.2
3.2
Diagram 3 (level 1)
Further diagrams or
process descriptions
Diagram 3 (level 1)
11
Example Level zero diagram
SUPPLIERS
CUSTOMERS
Customer details
Product
details
product qty product
holding
1
p.o.
number
INVENTORY
product
delivered
qty
product product holding
order qty
Record
and
Invoice
Sales
SALES ORDERS
customer
invoice
p.o. invoice
product
order
qty
2
delivery
qty
Maintain
Product
Inventory
product
order qty
Example Level 1 diagram
Check
Stock Available
1.1
Check
Customer
Credit
Product
details
customer credit
status
product
qty
product
product
holding
INVOICES
available qty
SALES ORDERS
1.4
1.3
product
qty
INVENTORY
1.2
Customer
details
Record
Sales
Demand
Create
Sales
Invoice
customer
invoice
Guidelines for Levelling DFDs
• numbering:
when a process is decomposed, its diagram is given the same
number as that process
• balancing of DFDs:
all data flows entering and leaving a process must appear on the
corresponding diagram which decomposes that process
• external agents:
are only included on the two diagrams which represent the entire
system, i.e. the context and level zero diagrams
12
Guidelines for Levelling DFDs
balancing data flows:
if data flows are decomposed at lower levels then the
contents of the data flows across levels must be balanced
sales order
customer
shipping
details
1
out of stock
notice
customer
order items
1.1
Fill
Sales
Orders
1.2
Check
shipping
details
Check
stock
available
shipping slip
sales order
=
customer
+
shipping details
customer order
items
Guidelines for Levelling DFDs
The access to data stores across levels of diagrams must be consistent:
•the direction of accesses must match and all accesses on higher level
diagrams must appear on corresponding lower level diagrams
•a data store is first shown on the highest level diagram where it is accessed
by more than one process
•it can then appear on all lower level diagrams where it is accessed
1
1.1
1.2
1.3
2
Guidelines for Levelling DFDs
partition processes to:
• form cohesive, related groups of activities
• minimise the data flows between them
all parts of the system need not be decomposed to the same
level
13
Guidelines for Levelling DFDs
How many levels should be in a set of DFDs?
• each diagram usually has between 3 and 7 processes
• level the diagrams until bottom level or primitive processes are
reached
primitive processes cannot be further decomposed as a data flow diagram
An example - Context Diagram
Line
Applicant
Manager
Address
Position Spec
Applicant name
Position
Acknowledgement
Successful
Applicant
Employment
System
Decision
Payroll
System
Position
An example - Level zero diagram
Applicant
Position
Address
Acknowledgement
1
Applicant
name
Line
Manager
Ackn’d
Appn
Accept
Application
Position Spec
Decision
2
Evaluate
Applicants
Applicant
Position
Unsuccessfuls file
Evaluation
results
Successful
Applicant
Payroll
System
14
Level 1- Diagram 1
Address
Applicant name
Position
1.1
Acknowledgement
Verified
Application
1.2
Verify for
Completeness
Acknowledge
Application
Acknowledged
Application
Level 1 - Diagram 2
Ackn’d
Appn
Position Spec
Qualified
applicant
2.1
Screen
Applicants
unqualified
applicant
Decision
2.2
Reject
Unsuitabl
es
2.3
Schedule
Evaluation
Decision
Unsuccessfuls file
Evaluation
results
Successful
Applicant
References
WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis
and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 8
HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems Analysis
and Design, Benjamin/Cummings, Massachusetts.
Chapter 7
15