0% found this document useful (0 votes)
118 views

How To Create Data Flow Diagram (DFD

The document provides information on data flow diagrams (DFDs), including what they are, their purpose, types, and levels. It explains that DFDs visually show the flow of data through processes in a system and include external entities, data flows, processes, and data stores. It also provides an example DFD for a food ordering system to illustrate these components at different levels of the diagram.

Uploaded by

Darwin Vargas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
118 views

How To Create Data Flow Diagram (DFD

The document provides information on data flow diagrams (DFDs), including what they are, their purpose, types, and levels. It explains that DFDs visually show the flow of data through processes in a system and include external entities, data flows, processes, and data stores. It also provides an example DFD for a food ordering system to illustrate these components at different levels of the diagram.

Uploaded by

Darwin Vargas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

How to Create

Data Flow
Diagram (DFD)?
Data flow diagram (DFD) is a
diagram being used frequently
in software design. It visually
represents the flow of data
throughout processes in a
given system. DFD shows the
kind of information that will be
input to and output from
processes as well as where the
data will be stored.

What is Data
Flow Diagram?
A typical information system involves processing a lot of information
and processes. The purpose of Data Flow Diagrams is to view systems
as a whole with its scopes and boundaries while it illustrates the
movement of information between components. The focus of DFD is on
the flow of data throughout the system, not process flow. DFD allows
readers to easily see how the system will operate by knowing the kind
and flow of information involved.

Purpose of Data Flow Diagrams


There are two main types of DFD:
Physical and Logical.
Physical DFD: Focuses on the physical
aspect of the system by showing “how”
the system will be implemented
Logical DFD: Focuses on a higher-
level view of the system and “what” it
will achieve.

DFD Types
Data Flow Diagram Levels

Unlike other diagrams, DFD can be drawn at different levels, based on the
purpose they are drawn to serve.

Context Data Flow  Diagram


Context DFD is sometimes referred to as level 0 DFD. It’s the top-level
diagram among all, which illustrates the entire system in its relationship to
any external entities.

Data Flow Diagram Level  1


Level 1 DFD is the level under the context-DFD. It illustrates the main
functions within the system. Level 1 breakdown the context level by including
more details. It represents how the data enters and exits the system, where it
is stored and how the basic processes convert it from one form to another.

Data Flow Diagram Level  2


Level 2 DFD (or further) goes into deeper detail. It shows how the data flows
within the main process of the system.
You should create as many levels of DFD as you need until the desired level
of detail is met.
Data Flow Diagram (DFD) provides a visual
representation of the flow of information (i.e. data)
within a system. By drawing a Data Flow Diagram,
you can tell the information provided by and
delivered to someone who takes part in system
processes, the information needed to complete the
processes and the information needed to be stored
and accessed. This article describes and explains
the Data Flow Diagram (DFD) by using a food
ordering system as an example.

Data Flow Diagram: Examples - Food Ordering System


Context DFD

A context diagram is a data flow diagram that only shows the top
level, otherwise known as Level 0. At this level, there is only one
visible process node that represents the functions of a complete
system in regard to how it interacts with external entities.

Some of the benefits of a Context Diagram are:


Shows the overview of the boundaries of a system
No technical knowledge is required to understand with the simple
notation
Simple to draw, amend and elaborate as its limited notation

The Food Ordering System Example


The figure below shows a context Data
Flow Diagram that is drawn for a Food
Ordering System. It contains a process
(shape) that represents the system to
model, in this case, the "Food Ordering
System". It also shows the participants
who will interact with the system, called
the external entities. In this example,
the Supplier, Kitchen, Manager,
and Customer are the entities who will
interact with the system. In between the
process and the external entities, there
is data flow (connectors) that indicate
the existence of information exchange
between the entities and the system.

Context DFD is the entrance of a data flow model. It


contains one and only one process and does not show
any data store.
The figure below shows
the level 1 DFD, which is
the decomposition (i.e.
break down) of the Food
Ordering System process
shown in the context DFD.
Read through the diagram
and then we will introduce
some of the key concepts
based on this diagram.

Level 1 DFD
The Food Order System Data Flow Diagram example contains three
processes, four external entities, and two data stores.
Based on the diagram, we know that a Customer can place an Order. The Order
Food process receives the Order, forwards it to the Kitchen, store it in the Order data
store, and store the updated Inventory details in the Inventory data store. The process also
delivers a Bill to the Customer.

The Manager can receive Reports through the Generate Reports process, which


takes Inventory details and Orders as input from the Inventory and Order data store
respectively.
The Manager can also initiate the Order Inventory process by providing Inventory order.
The process forwards the Inventory order to the Supplier and stores the updated Inventory
details in the Inventory data store.
Data Flow
Diagram Tips
and Cautions
1. Process labels should be verb phrases; data stores are
represented by nouns
2. A data store must be associated with at least a process
3. An external entity must be associated with at least a
process
4. Don't let it get too complex; normally 5 - 7 average
people can manage processes
5. DFD is non-deterministic - The numbering does not
necessarily indicate sequence, it's useful in identifying
the processes when discussing with users
6. Datastores should not be connected to an external
Tips
entity, otherwise, it would mean that you're giving an
external entity direct access to your data files
7. Data flows should not exist between 2 external entities
without going through a process
8.A process that has inputs but without outputs is
considered to be a black-hole process
Don't mix up data flow and process flow
Some designers may feel uncomfortable when seeing a connector
connecting from a data store to a process, without seeing the step
of data request being shown on the diagram somehow. Some of
them will try to represent a request by adding a connector
between a process and a data store, labeling it "a request" or
"request for something", which is wrong.
Keep in mind that Data Flow Diagram was designed for

Cautions
representing the exchange of information. Connectors in a Data
Flow Diagram are for representing data, not for representing
process flow, step or anything else. When we label a data flow
that ends at a data store "a request", this means we are passing a
request as data into a data store. Although this may be the case
in implementation level as some of the DBMS do support the use
of functions, which intake some values as parameters and return
a result, in Data Flow Diagram, we tend to treat data store as a
sole data holder that does not possess any processing capability.
If you want to model the system flow or process flow, use  
UML Activity Diagram or BPMN Business Process Diagram
 instead. If you want to model the internal structure of a
datastore, use an Entity Relationship Diagram.
The Securities Trading Platform
Example
The figure shows a context
Data Flow Diagram that is
drawn for a security trading
platform. It contains a process
(shape) that represents the
system to model, in this case,
the "securities trading
platform". It also shows the
participants who will interact
with the system, called the
external entities. In this
example, CS
Assistant, Customer and Broke
r are the entities who will
interact with the system. In
between the process and the
external entities, there are
data flow (connectors) that
indicate the existence of
information exchange between
the entities and the system.

Context DFD Context DFD is the entrance of a data flow model. It


contains one and only one process and does not show
any data store.
The figure below shows
the level 1 DFD, which is
the decomposition (i.e.
break down) of the
securities trading
platform process shown in
the context DFD. Read
through the diagram, and
then we will introduce
some of the key concepts
based on this diagram.

Level 1 DFD
The securities trading platform Data Flow Diagram example contains five
processes, three external entities and three data stores. Although there is no
design guidelines that governs the positioning of shapes in a Data Flow
Diagram, we tend to put the processes in the middle and data stores and
external entities on the sides to make it easier to comprehend.

Based on the diagram, we know that a Customer Service Assistant provides customer details to
the Open Account process. The result is the Customer details being stored in Customer data
store and Account details being stored in Account data store. Although we said that the attempt
to store customer and account details happens after the details are being provided by
the Customer Service Assistant, the Data Flow Diagram implies no such thing. It is our common
sense that lead us to interpret the diagram in the way that we understand it naturally. Strictly
speaking, the diagram only tells us the Open Account process receives customer details and
produce customer and account details, with no order specified. Note that Data Flow Diagram
does not answer in what way and in what order the information is being used throughout a
system.
The process Check
Transaction receives Transaction details from
the Transaction data store and pass it on
to Customer.

A Customer can Deposit Cash by providing


the Deposit amount and the result is the Updated
account balance being stored in the Account data
store.

Similarly, a Customer can Withdraw Cash. The


result is that he will receive the Withdrawn
amount and the Updated account balance will be
stored in the Account data store.

Finally, both the Customer and Broker can initiate


the Place Order process, which results in
the Transaction details being stored in
the Transaction data store. The Place
Order process also passes the Transaction
details to the Stock Exchange Center, which is an
entity out of the system scope. In the next section,
we will introduce a way to represent this kind of
entity.
Just like the process in context
DFD, processes in level 1 DFD
can also be decomposed into a
deeper level or even levels of
process details. The figure
below shows the level 2 DFD
of the Place Order process.

Level 2 DFD
The external entities and data stores in this DFD correspond with
those shown in the upper level (i.e. the diagram above). What
makes it different is the breakdown of Place Order process
into Place Order (Online) process and Place Order
(Offline) process.

Based on this diagram, we know that a Customer can


perform Place Order (Online) by supplying Order details while
a Broker can perform Place Order (Phone) also by supplying Order
details; in either case causing Transaction details to be stored in
the Transaction data store and passed to the Stock Exchange
Center.

You might also like