ENMA 6010:
Data Flow Diagrams
Modeling System Functions
Primary Reference: Wikipedia – Data Flow Diagrams
©2010 – Mark Polczynski
All rights reserved
ENMA 6010: Data Flow Diagrams
1
We will be studying four modeling approaches:
Detail
• Data flow diagram – system function
• State transition diagrams – time dependent behavior
• Entity relationship diagram – stored data/material
• Process flow diagrams – actions and decisions
To understand the rationale behind this modeling tool,
We need to review the reasons for modeling,
And the characteristics of good model.
ENMA 6010: Data Flow Diagrams
2
Goals of System Modeling:
1.
To focus on important system features while downplaying less important
features,
2.
To discuss changes and corrections to the user’s requirements at low cost
and with minimal risk,
3.
To verify that we understand the user’s environment,
4.
To verify that we have documented our understanding in a way that
would allow others to construct/maintain the system.
Data flow diagrams are a good tool for modeling system functions.
Additional tools are typically required to meet this complete set of goals.
ENMA 6010: Data Flow Diagrams
3
Characteristics of Good Models
1.
Graphical, with support for detailed text descriptions: Picture is worth a
thousand words  picture links to a thousand words.
2.
Top-down partitionable: Globe  Continents  Countries 
3.
Minimally redundant: Make changes in just one place in the model.
4.
Transparent: Requires no expertise in
model building to understand the model.
ENMA 6010: Data Flow Diagrams
4
Data Flow Diagrams
Low-hanging
apple
Data flow diagrams focus on:
Pick apple
1.
Processes within a system that
a) Transform data/material
inputs to outputs
Picked apple
Picked apples
b) Store data/materials
2.
Flows
a) Within the system between the processes and stores,
b) To/from entities outside of the system.
ENMA 6010: Data Flow Diagrams
5
Origins and Uses
• Data flow diagrams began to be widely used in the 1970’s.
• They are a key tool in software engineering.
• They are associated with the general field of structured analysis.
• So, they are good for modeling business systems.
• They focus on data (information), but in a general sense, they can
represent any type of flow, e.g., money flow, material flow.
• Thus, they are a good tool for modeling inventory flow and storage in a
manufacturing system.
• But in their basic form they are primarily qualitative vs. quantitative.
• That being said, they can be an excellent high-level representation for
streamlining systems and reducing inventory.
ENMA 6010: Data Flow Diagrams
6
Data, Materials, and Objects
•
Because DFDs came out of software engineering, the focus was on data.
•
But as we see, the modeling approach accommodates any kind of flow,
including data, materials, money (which is now data, not materials like
silver and gold), etc.
•
So here, we will just use the generic term “object” for whatever is flowing.
•
As it turns out, this term will show up in other modeling tools.
ENMA 6010: Data Flow Diagrams
7
Data Flow Diagram Symbols
Process
Process (or function) which transforms data or material
(objects) inputs to outputs. Black box - does not indicate
how or when the transform is done. Shorthand = “bubble”.
Store
Place where objects come to rest. You only store object
that the system needs to “memorize”.
Flow
Directed pathways between processes, stores, and
terminators. Use a different flow for each type of object.
External
Terminator
Entities outside the system. Where flows start and end.
Outside the scope of the model.
ENMA 6010: Data Flow Diagrams
8
Example Data Flow Diagram: Book Shipping and Receiving System
Alternate
shape
From Yourdon –
Some inconsistencies!
ENMA 6010: Data Flow Diagrams
9
Naming Data Flow Diagram Elements
Constructing and understanding data flow diagrams can be enhanced by
sticking to some simple naming conventions:
Process
Verb-object phrase: “Calculate sales tax”. Don’t use the name
of the person/computer/etc. Rather, describe the function
(keep it general).
Flow
Noun: Name of the object flowing, e.g. “Apple”. If it is
“Apple, Pear, Banana”, and you process them all the same
way call it “Fruit”.
Store
Typically, plural of the object being stored: “Apples”
External
Terminator
This is typically some physically distinct entity – person,
computer, company, agency, another system.
ENMA 6010: Data Flow Diagrams
10
Some Implementation Notes:
• If you are struggling with defining meaningful names for diagram elements
(e.g. “valid tax return” vs. “input”), then you probably don’t understand the
system.
• To increase clarity, you can show terminators and stores more than one
time in a diagram (see BODS example), but each process bubble can
appear only once.
• Terminators are outside the system being modeled. If you start drawing
flows between terminators, then you are, in essence, expanding the
boundaries of the system you are modeling.
• You can’t have processes or stores with inputs but no outputs (sinks), or
outputs but no inputs (sources).
• Only terminators can be sources or sinks of objects.
ENMA 6010: Data Flow Diagrams
11
Implementation Note on Terminators:
• Usually, your customer defines the scope of the system that you will be
modeling.
• This defines the terminators for the DFD.
• Terminators are outside of the system, and, by definition, the modeler
cannot change the contents, organization, or internal procedures of
terminators.
• Therefore, the DFD is an essential document for customer interaction and
model scope definition.
• It is essential to controlling customer expectations.
ENMA 6010: Data Flow Diagrams
12
Further Information on Implementation
The Yourdon text has detailed guidelines on do’s and dont’s of drawing DFDs.
We will not cover this detail here, but it is highly recommended that someone
on your team reads through this and does a thorough check of your project
DFD.
That being said, there are some key issues we still need to touch on:
•
Logical model vs. physical model,
•
Top-down modeling,
•
Bottom-up modeling,
•
Data dictionary
•
Extensions for real-time control.
ENMA 6010: Data Flow Diagrams
13
DFD Logical Model vs. Physical Model
• The logical model contains only the diagram elements absolutely needed
to make a system meet the customer requirements.
• This is sometimes termed the essential model.
• The physical model contains process, store, and flow elements that are
added by the designer to make implementation easier.
• This may be called the environmental model.
• The logical model is implementation independent…
…The physical model is implementation dependent.
ENMA 6010: Data Flow Diagrams
14
Great! What Does That Mean?!
This is a very critical distinction…
and an essential part of building good models.
Let’s start with a simple example: Making a PBJ sandwich…
ENMA 6010: Data Flow Diagrams
15
Processes and Flow
Here is the logical model for preparing your sandwich.
The model contains all the essential processes and flows.
But what if you were preparing the sandwich in the morning,
and it is supposed to be your lunch?
ENMA 6010: Data Flow Diagrams
16
Process, Flow, and Storage
Here, the sandwich is constructed and stored
for later consumption.
Thus, the storage element is required to
implement this system,
But it is not required to make a PBJ sandwich.
ENMA 6010: Data Flow Diagrams
17
Logical Model:
Ideally, orders are
processed
immediately.
Physical Model:
In this implementation
of the ideal system,
orders are processed in
batches, so they need
to be stored before
processing.
Un-Lean
This is an example of a physical model containing
an implementation-dependent data store.
ENMA 6010: Data Flow Diagrams
18
Here is an example of a necessary data store in an order entry system…
Here, it is absolutely necessary to keep a long-term record of Orders
for government accounting regulations, warrantee coverage, etc…
So this should be included in the logical model.
ENMA 6010: Data Flow Diagrams
19
Using Logical and Physical Models
Typically, you develop the logical model first to understand the system,
Then build the physical model to use as a design spec showing actual
implementation.
The physical model represents compromises that add cost to the system.
In the physical model, the diagram elements turn into the names of:
• People,
• Physical pieces of hardware,
• Software packages,
• File or databases,
• Inventory locations,
• Etc…
ENMA 6010: Data Flow Diagrams
20
Buffers and Work-In-Process
• In practice, a primary difference between logical and physical models lies in
the stores.
• In logical models, only the objects that needs to be stored for future use
(“memorized” for data) appear in the model.
• The added data stores in physical models represent buffers needed for realworld systems to level out flow between processes.
• Since data flow and data store can also represent material flow and material
store, data stores represent inventory or work-in-process.
• Comparison of logical and physical models is an excellent way of
identifying and reducing work-in-process.
Goal is to make physical model look like logical model.
ENMA 6010: Data Flow Diagrams
21
Logical vs. Physical Model
In a sense, the logical model represents an ideal future state of a system.
Thus, the logical represents a “to-be” model that our kaizen efforts should be
directed toward.
It is important to build the logical model first, since we really need a description
of the to-be state.
Now, whether you are designing a new system or analyzing an old system, you
must always ask:
•
Why do I need this storage element in the physical model?
•
How could I eliminate the need for this physical element?
ENMA 6010: Data Flow Diagrams
22
Top-Down Modeling
• Obviously, a system with many processes, flows, and stores can result
in a data flow diagram that is impossible to understand, maintain, and
improve.
• The field of structured analysis allows top-down design, modeling, and
documentation, where processes are decomposed into multiple sublevels.
• Data flow diagrams support this approach.
Let’s see how this works…
ENMA 6010: Data Flow Diagrams
23
Returning to the Book Order and Delivery System, we see a bunch of
process blocks, storage blocks, terminator blocks, and flows.
So we can easily find the system boundaries right away…
Process
Store
Flow
External
Terminator
ENMA 6010: Data Flow Diagrams
24
Context Diagram
By observing system boundaries, we can draw a Context Diagram which shows
the system we are analyzing (target system), and the systems that our system
interacts with.
Target system
for analysis
Note: Drawing the Context
Diagram resolved some
inconsistencies in Yourdon’s
original example!
ENMA 6010: Data Flow Diagrams
25
Context Diagram
The Context Diagram is the top level in our top-down model.
Target system
for modeling
Once we settle on what is inside and outside the system we will model,
And how our system interacts with the outside world,
We can focus our attention on modeling the target system.
ENMA 6010: Data Flow Diagrams
26
Level 0
Returning to Yourdon’s example, Level 0 shows the major functions and
stores inside the Context Diagram target system.
Note the
numbering on
the functions
ENMA 6010: Data Flow Diagrams
27
Top-Down Modeling – Process Decomposition
Next, you draw data flow diagrams for what is happening inside each Level 0
function, etc….
Note the numbering convention
on the processes.
System
Context Diagram
2
3
3.1
3.3
1
Level 0
3.2
Level 1
Level 2
ENMA 6010: Data Flow Diagrams
28
Top-Down Decomposition Implementation Notes:
•
Try to limit each DFD level to about 6 processes and stores (1 .ppt slide).
•
If you have more than 6 processes, try to group them, and then create
sub-level showing detail.
•
You will rarely go beyond Level 2.
Remember!
DFD just shows:
•
WHAT processes (transforms, functions) are performed on data/materials.
•
Not HOW the processes are performed.
•
We’ll use other tools to show the HOWs.
ENMA 6010: Data Flow Diagrams
29
Top-Down Modeling for System Design
The top-down approach works well when designing a new system.
Since you don’t know details, you can start by identifying the main object
transformations.
Then figure out later (or delegate) how each major transformation will be done.
This generates the lower levels of the diagram.
Note: As you do this, you may choose to change the boundaries of upper layers,
e.g., move Process 3.3 inside of Process 2.
3
3.1
3.3
2
3.2
1
Level 0
Level 1
ENMA 6010: Data Flow Diagrams
30
DFD Modeling Process: Bottom-Up Modeling
We saw how to build a top-down for a new process, but it is also possible to draw
DFDs using a bottom-up approach.
Bottom-up works OK for existing systems, but kind of difficult for systems that
don’t exist yet. Here’s how you do it:
1. Start by just writing down “events” (things that happen in your system) on
post-it notes. These events represent the process elements (bubbles).
2. For each process, identify what data or material is needed for the process
function.
3. Find the process that provides the needed object and draw a flow line.
4. Create new processes where there is no source of the required object.
5. Add stores where they are absolutely required.
6. Processes which are read-only or write-only are terminators, or you haven’t
analyzed the system correctly.
ENMA 6010: Data Flow Diagrams
31
Enter
Process
Walkthrough
Group and
Organize
Test
Model
List all events
that occur in the system
Attach flows in and out
to events (processes)
Walk through system
operation using the
model
For each event, identify
the data/material in
Attach data/material
stores to flow
in and out
For each event, identify
data/material out
Create diagram from
flow/process/store sets
sets
For each data/material,
identify stores as
needed
Eliminate duplicate
flow/process/store
elements
Identify missing
processes, flows, and
stores
Exit
Process Flow Diagram for
Bottom-Up Data Flow
Diagramming
No
Put events,
data/materials, stores
on self-stick notes
Review
and Revise
Model
accurate?
Yes
Use the
model
ENMA 6010: Data Flow Diagrams
32
Data Dictionary
You can collect the names of all
of the stored objects into a text
document.
Then, you can describe the
characteristics of that object.
This is the data dictionary…
It consists of what it is that we
need to “remember” about each
object.
Of course, you can treat
materials just like data, which
results in an inventory list vs. a
data dictionary
ENMA 6010: Data Flow Diagrams
33
Extensions for Real-Time Control
Consider our PBJ System.
Assumedly, we just don’t keep making and storing sandwiches,
Or just keep eating sandwiches all day long…
So, what turns the bubbles
on and off?
ENMA 6010: Data Flow Diagrams
34
Control
flow
Control
function
ENMA 6010: Data Flow Diagrams
35
Control Function
•
The control function coordinates the activities of the other DFD functions.
•
Control function inputs and outputs are 1-bit on/off yes/no signals.
•
No data/materials flowing on control lines!
•
These signals “wake up” other functions when the function needs to
transform inputs to outputs.
•
These could be expected or unexpected conditions.
•
Typically there is no more than one control function for a particular data
flow diagram.
ENMA 6010: Data Flow Diagrams
36
What A Mess!!
Yes, these models can get pretty complicated and messy,
But whose fault is that?!
One way to help keep things under control is to put your DFDs in matrix format:
To
Function 1
Function 2
…
Terminator 1
…
…
Terminator 1
…
Function 2
Function 1
From
Flow A
Store X
Flow B
ENMA 6010: Data Flow Diagrams
37
OK, let’s convert Yourdon’s example to matrix form…
Start with functions:
1. Receive order
2. Ship books
3. Collect payments
Then terminators:
• Customers
• Warehouse
Now build the matrix…
ENMA 6010: Data Flow Diagrams
38
DFD Matrix – Step 1
To
Warehouse
Customers
3. Collect
payments
2. Ship
books
1. Receive
order
From
1. Receive order
2. Ship books
3. Collect payments
Customers
Warehouse
Now let’s fill in the cells…
ENMA 6010: Data Flow Diagrams
39
DFD Matrix – Step 2
To
1. Receive order
2. Ship books
Warehouse
S: Customers F: Orders
S: Orders
F: Books
F: Payments,
inqiries
3. Collect payments S: Invoices
Customers
Customers
3. Collect
payments
2. Ship
books
1. Receive
order
F = Flow
S = Store
From
F: Invalid
orders
F: Ship books F: Invoices
Warehouse
ENMA 6010: Data Flow Diagrams
40
Why would you do this?
To
1. Receive order
Warehouse
Customers
3. Collect
payments
2. Ship
books
1. Receive
order
From
S: Customers F: Orders
2. Ship books
S: Orders
3. Collect payments
S: Invoices
Customers
F: Invalid
orders
F: Books
F: Payments,
inqiries
F: Ship books F: Invoices
Warehouse
Does Ship books send
anything to warehouse?
Well, for example, now it’s pretty easy to go to each empty cell and ask
if there actually should be a data flow that we missed in our analysis.
ENMA 6010: Data Flow Diagrams
41
Characteristics of Good Models
1.
Graphical, with support for detailed text descriptions: Picture is worth
a thousand words  picture links to a thousand words.
2.
Top-down partitionable: Globe  Continents  Countries 
3.
Minimally redundant: Make changes in just one place in the model.
4.
Transparent: Requires no expertise in model building to understand the
model.
Data flow diagrams have these characteristics.
ENMA 6010: Data Flow Diagrams
42
Goals of System Modeling:
1.
To focus on important system features while downplaying less important
features,
2.
To discuss changes and corrections to the user’s requirements at low cost
and with minimal risk,
3.
To verify that we understand the user’s environment,
4.
To verify that we have documented our understanding in a way that would
allow others to construct/maintain the system.
Data flow diagrams are a good tool for modeling system functions.
Additional tools are required to meet this complete set of goals.
ENMA 6010: Data Flow Diagrams
43
We will be studying several modeling approaches, including:
Detail
• Data flow diagram – system function
• State transition diagrams – time dependent behavior
• Entity relationship diagram – stored data/material
• Process flow diagrams – actions and decisions
Can you be more specific?
ENMA 6010: Data Flow Diagrams
44
Preview of coming lectures…
State transition
diagram
Process flow
diagram
Entity relationship
diagram
ENMA 6010: Data Flow Diagrams
45
Notes on using Visio to draw data flow diagrams…
ENMA 6010: Data Flow Diagrams
46
Forget it!
See next slide
My favorite shapes…
ENMA 6010: Data Flow Diagrams
47
Start with
“Dynamic connector”…
Then select line
and right click…
Then choose
“Curved Connector”
ENMA 6010: Data Flow Diagrams
48