Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 1
Process Modeling and Dataflow Diagrams (DFDs)
Merrill WarkentinMississippi State University
© Merrill Warkentin, 20052
Major Topics
process modeling
data flow diagram symbols
data flow diagram levels
creating data flow diagrams
physical and logical DFDs
partitioning
(event driven modeling)
(use case and data flow diagrams)
© Merrill Warkentin, 20053
Process Modeling
Graphically representing the functions, or processes, which capture, manipulate, store, and distribute data between a system and its environment and between components of a systemData Flow Diagram (DFD)
© Merrill Warkentin, 20054
Data Flow Diagrams (DFD)graphical representation of data processesand flows throughout the organization
emphasizes logic of underlying system
based on general systems model
Input Process Output
© Merrill Warkentin, 20055
Why Use DFD?
logical information flow of the system
determination of physical system construction requirements
simplicity of notation
establishment of manual andautomated systems requirements
© Merrill Warkentin, 20056
Advantages of DFD
early understandingof system technical implications
establishment of inter-relatednessbetween business and systems
user involvementwith system development
determine if data and processes have been defined properly
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 2
© Merrill Warkentin, 20057
DFD - Four Symbols
© Merrill Warkentin, 20058
DFD - Four Symbols
Process - work or actions performed on data so that they are transformed, stored, or distributed
Date Store - data at rest, notebook, file folder, database
Source/Sink - origin and/or destination of the data (external entities)
Data flow - data in motion
© Merrill Warkentin, 20059
DFD Formatting Symbols
Entity
D3 DataStore
2.1
Process
Data Flow
external to boundaries of systemsources and destinations of data
data movementelectronic exchangepaper documents(sometimes shown as)
transformation of datafrom input to output
data depository forelectronic filespaper files(sometimes shown as)
© Merrill Warkentin, 200510
External Entities
supply data to the system
receive data/information from the system
but not considered part of the system
Entity
Purchase order
2.1
ProcessEnterorders
Entity
© Merrill Warkentin, 200511
Data Flowsrepresent data being moved to or from
an external entitya processa data store
shown as a line with arrowheadslabeled with description ofthe type of data, document, or report
Order data2.1
ProcessEnterorders D3 Data
StoreOpen
order file
© Merrill Warkentin, 200512
Processesset of tasks performed on datato convert inputs to outputs
labeled as a verb/noune.g., ENTER ORDERS
data flow out always labeled differently than data flow in
2.1
ProcessEnterorders
Orderdata D3 Data
StoreOpen
order filePurchase
orderEntity
2.1
Process
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 3
© Merrill Warkentin, 200513
Processes - 4 Types
create new data change quality but not content of input
e.g., verify customer numberoutput = input = (verified) customer number
reorganize inputsortreformatfilter/select
convey input without any change
© Merrill Warkentin, 200514
Data Storesdata at restcorresponds to data files or tablescan be electronic or paper filesshown as a rectangle (electronic)arrow into file means data writtenarrow out means data read
D3 DataStore
Orders
2.1
ProcessEnterorders
Orderdata D3 Data
StoreOpen
order file
D1 DataStore
Customer data
D2 DataStorePOFile
1.0
© Merrill Warkentin, 200515
Balancing DFDs
Inputs and outputs must be conserved between levels of DFDsLevel n & n+1 must have the same inputs and outputs
© Merrill Warkentin, 200516
Five guidelines for drawing DFDs
Completeness - all necessary components are included and describedConsistency - information on one level is included on other levelsTiming - a DFD does NOT indicate when the system is flowingIterative development - it may take 3 or more DFDs to get it rightPrimitive DFDs (the lowest level DFD) - stop decomposing when the lowest logical level is reached
© Merrill Warkentin, 200517
Problems with DFDs
Identify problems on the DFD(see handout)
© Merrill Warkentin, 200518
Describe problems (handout)
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 4
© Merrill Warkentin, 200519
DFD Development/Levels
context diagramgeneral highest level diagramone process representing entire system
diagram 0exploded view of the entire systemup to nine processesall external entities and data stores
child diagramsexploded view of each individual processoutlined in Diagram 0
© Merrill Warkentin, 200520
DFD Organization
Process
Input B
ExternalEntity
1
1.0
Name ofSystem
Input A
ExternalEntity
2
ExternalEntity
3Output C
Input B
ExternalEntity
1
D1 Data Store1
1.0
ProcessA
Input A
ExternalEntity
2
ExternalEntity
3
2.0
ProcessB
Record A
Record A
D2 Data Store2
4.0
ProcessD
Output C
3.0
ProcessC
Record E
Record E
Data Flow B
Data Flow D
Data Flow C
3.1
DetailedProcess
C-A
3.2
DetailedProcess
C-BD5 RecordStore 1Record 1 Record 1
Record E
Data Flow D
© Merrill Warkentin, 200521
Creating the Context Diagramoriginal should be an overview
basic inputsgeneral systemoutputs
highest level
contains only one process
© Merrill Warkentin, 200522
Context Diagram Example
© Merrill Warkentin, 200523
Drawing Diagram 0explode context diagram
more detailclose-ups of processesdata storeslower-leveldata flows
may includeup to 9 processes
© Merrill Warkentin, 200524
Drawing Diagram 0
start with data flowfrom an external entitywork backwardsfrom an output data flowexamine data flowanalyze well defined processtake note of problem areas
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 5
© Merrill Warkentin, 200525
Diagram 0 Example
© Merrill Warkentin, 200526
Creating Child Diagrams
more detailed levelseach process exploded further
parent processexploded diagram 0 process
child diagramresulting diagramentities usually not shown at this levelmay have error lines here only
© Merrill Warkentin, 200527
Child Diagram Examples
© Merrill Warkentin, 200528
Child Diagram Examples
© Merrill Warkentin, 200529
Child Diagram Examples
© Merrill Warkentin, 200530
Rules & Guidelines for DFD
A data store must always be connected to a process.
D4 DataStore
This:
Not this:
Nor this: Entity
2.1
ProcessD3 Data
Store
Data Flow
Data Flow
Data Flow
D3 DataStore
D4 DataStore
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 6
© Merrill Warkentin, 200531
External entity must always be connected to a process.
OK -
not OK -
Data may flow out of one process and into another.
OK - Data Flow
2.2
Process
Rules & Guidelines for DFD
Entity
Entity
Data Flow
Data FlowD4 Data
Store
2.1
Process
2.1
Process
© Merrill Warkentin, 200532
Naming Rules for Data Flows
data flows must be nameduse a NOUN(what data are being used by a process?)
output flow from a processmust have a different name than the input flowoutput cannot be the same as the input
data traveling togethershould be shownand named as one data flowexample: orders and payments flowing togethershould be labeled as “orders and payments”
© Merrill Warkentin, 200533
Data Stores’ Rules & Guidelines
if no input data flowing to them,may not be properly represented
where did the datain the data store come from?
should be uniquely numberedon the flow diagramdescription of the data attributes should be contained in a similarly numbered tablestructure / data attribute dictionary
you can create the dictionary by printing out the ACCESS data structures for each table
© Merrill Warkentin, 200534
Rules & Guidelines for Processes
process performs one simple, well-defined task, activity or functionmust have at least one input andone output data flow
if no input, process is creating output from “thin air”(where is the data to be processedinto output coming from?if no output, process is “black hole” or “data sink”(why is data flowing to a processthat does not produce any output?)
data should be sent only to processesthat use them
© Merrill Warkentin, 200535
should be uniquely named and numbered
description of the process should bein a similarly numbered and indexed“process dictionary”
data store to can be the only receiverof output from a process
data store to can be the only sourceof input to a process
Rules & Guidelines for Processes
© Merrill Warkentin, 200536
Common Errorsnot including data flow placing arrowhead in the wrong directiondirectly connecting data stores & external entitieslabeling incorrectlyincluding more than 9 processesomitting data flowhaving unbalanced composition
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 7
© Merrill Warkentin, 200537
Common DFD Errors
2.1
ProcessD3 Data StoreD3 Data Store
2.1
Process
Entity
D3 Data Store
Entity
Entity
2.1
Process
Dual/SplitData Flows
Entity to Entity/Data Store Communication No Data Output
No Data Input Data to Data Communication
© Merrill Warkentin, 200538
B1 B2 B1 B1
B1 B1
B1 B1
DS1 DS2 DS1
a process is needed to
exchange data flows between
boundaries
a process is needed to update (or use) a data
store
a process is needed to
present data from a data
store
a process is needed to move data
from one data store to another
DS2
DS1
DS1 DS1
DS1
Illegal Data Flowsillegal data flows corrected data flows
© Merrill Warkentin, 200539
Practice Question - THINKWhich is an error condition?
© Merrill Warkentin, 200540
DFD for Hoosier Burger (food ordering system)
Context diagram - highest view of the system
© Merrill Warkentin, 200541
DFD for Hoosier Burger (food ordering system)
Level-0 DFD -
systems major processes, data flows, and data stores
Level-n DFD -
n nested decompositions of sub-processes from the level-0 diagram
© Merrill Warkentin, 200542
DFD for Hoosier Burger (food ordering system)
Level-1 - decomposes process 1.0 from level-0
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 8
© Merrill Warkentin, 200543
DFD for Hoosier Burger (food ordering system)
Level-1 - decomposes process 4.0 from level-0
© Merrill Warkentin, 200544
DFD for Hoosier Burger (food ordering system)
Level-2 Diagram Showing the Decomposition of Process 4.3 from the Level-1 Diagram for Process 4.0
© Merrill Warkentin, 200545
Logical DFD
focus on how the business operatesprocesses that exist regardless of the typeof system implemented
© Merrill Warkentin, 200546
Physical DFD
details physical system requirementscontains construction specifications(software, hardware, people)
© Merrill Warkentin, 200547
Logical to Physical DFDcreate a logical DFD of the current systemadd all data and processes not in the current system which must be present in the new systemderive the physical data flow diagram forthe new systemlogical DFD of the current system will leadto appropriate logical DFD of the new systemphysical DFD will follow naturally ifthe logical DFD is accurate
© Merrill Warkentin, 200548
Logical to Physical DFD
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 9
© Merrill Warkentin, 200549
Logical DFD - Advantages
better communication
more stable systems
better understanding
flexibility and maintenance
elimination of redundancies
© Merrill Warkentin, 200550
Physical DFD - Advantages
clarifying manual & automated processes
detailed process description
sequencing processes
identifying temporary data stores
specifying name of files and printouts
adding controls
© Merrill Warkentin, 200551
Partitioning Data Flow Diagrams
identify separate user groupsprocess timingsimilar taskefficiencydata consistencysecurity
The process of separating activities into groupsbased on automation, manual, and user needs
© Merrill Warkentin, 200552
Reasons for Partitioning
different user groups
timing
similar tasks
efficiency
consistency
security
© Merrill Warkentin, 200553
Partitioning the DFD
Look . . .© Merrill Warkentin, 200554
Indicate with dotted line
Chapter 7Process Modeling and Data Flow Diagrams (DFD)
Copyright 2005, Merrill Warkentin page 10
© Merrill Warkentin, 200555
Separate batch programs
© Merrill Warkentin, 200556
Practice Question - THINK
Which of the following is NOT a reasonfor partitioning processes into separateprograms?
© Merrill Warkentin, 200557
Summary
standard communication tool for design team
promotes better understanding of system
ensures that all components are included
leads to effective logical design
Copyright NoticeThis document may not, in whole or part,
be copied, photocopied, reproduced, translated, transmitted,or reduced to any electronic medium or machine readable form
without explicit permission and written authorization from Dr. Merrill Warkentin.
[email protected]://www.MISProfessor.com