How To Draw DFD’s

Use a Data Flow Diagram (DFD) to show the relationships among the
business processes within an organization to:

• external systems,
• external organizations,
• customers,
• other business processes.

Method

Data flow diagrams are used to describe how the system transforms
information. They define how information is processed and stored and
identify how the information flows through the processes.

When building a data flow diagram, the following items should be

considered:

• where does the data that passes through the system

come from and where does it go,

• what happens to the data once it enters the system (i.e.,

the inputs) and before it leaves the system (i.e., the outputs),

• what delays occur between the inputs and outputs (i.e.,

identifying the need for data stores).

Components of a Data Flow Diagram

STEPS TO DRAW A DATA FLOWDIAGRAM

Steps
•Start from thecontextdiagram. Identify the parent process and
theexternal entitieswith their net inputs andoutputs.
•Place the external entities on thediagram. Draw the boundary.
•Identify thedata flowsneededto generate the net inputs and
outputs to the externalentities.
•Identify thebusiness processesto perform the work needed to
generate the input and output dataflows.
•Connect the data flows from theexternal entities to the
processes.
•Identify thedatastores.
•Connect the processes and data storeswith data flows.
•Apply theProcess Model Paradigmto verifythat the diagram
addresses the processing needs of all externalentities.
•Apply theExternal Control Paradigmto furthervalidate that the flows
to the external entities arecorrect.
•Continue to decompose to thenthlevel DFD. Draw all DFDs at
onelevel before moving to the next level of decomposing detail.
You should decompose horizontally first to asufficient nth level to
ensure that the processes are partitioned correctly;then you can
begin to decompose vertically.
Tips andHints
Considercreating adataaccess modelto document the processes that
create, update, and delete datain the system.
As analternative to functional decomposition, consider using a bottom-up
approachwhen the details about the system are well known.
When analyzing the business system under study in terms of its
response to events (for example, user interaction with windowed
systems), consider the following:

Using External Events to Build DFDs

Components of Data Flow

Diagrams
Craig Borysowich | Feb 14, 2007 | Comments (13)

Whatever convention is used to construct the Data Flow Diagram, all

DFDs are composed of the following components:

EXTERNAL ENTITIES ON A DFD

External entities are also known as terminators, sources/sinks, and actors.

External entities define the sources and destinations of information entering and
leaving the system. An external entity can be a person, system, or organization
that has pre-defined behaviour.

External entities are mandatory on context diagrams but optional on data

flow diagrams.

Description of External Entities

External entities are components that interact with a business process on

the DFD but fall outside of the boundaries of the DFD.

External entities can be:

• initiators of data (i.e., spontaneous generators) flowing

into the business process,

• end recipients of data (i.e., data sinks) flowing from the

business process.

Examples

Examples of external entities include:

• End User,
• Purchasing Department,
• Inventory System.

Drawing External Entities on a DFD

 Place external entities on the diagram with all data flows.

To reduce the visual complexity of the drawing, an external entity can be

used more than once on the same DFD. Draw a diagonal line across the
lower-left corner of the external entity square to indicate another
occurrence of the external entity elsewhere on the same DFD.

Document External Entities

Provide a description of external entities to support the DFD.

FLOWS

Definition

Flows define the interfaces between the components within the system, and the
system and its external components.

Types of Flows

Flows that transport data around the data flow diagram are called data flows.

Description of Data Flows

Data flows are the pipelines through which data are transmitted between
any two components on a DFD. The composition of data is known and
defined in a data dictionary.

A data flow is also called a data flow vector.

Examples of data flows are:

• purchase order,
 • customer profile,
• account number,
• product.

Naming Data Flows

Data flows must be given a name that describes the content of the data
being transmitted and a description of the data flow listing the data
elements. For example:

Data Flow Name: Employee Info,

Description: Information stored about an employee,
Data elements: Employee Name,
Employee Date of Birth,
Employee ID.

Bi-Directional Data Flows

Bi-directional data flows are used only when the information flowing in
each direction is identical.

Data Flows with the Same Name

Multiple data flows can have the same name on a DFD. When this
occurs, the data transmitted in all of the flows with the same name must
be identical.

Complex Data Flows

Data flows are described as complex when there is more than one data
flow going in the same direction between any two entities.

Name the complex data flow to encompass the contents of all the data
flowing along the pipeline.
Trivial Data Flows

DFDs do not show trivial (relative to the specification of functional

requirements) flows, such as error messages, keys for retrieving data
from a data store, or data store updating instructions.

Guidelines for Drawing Data Flows on a DFD

Connect the data flows from/to external entities to/from business

processes within the boundary of the DFD.

Connect internal business processes to data stores and other internal

processes with appropriate data flows.

Label all data flows with care for they indicate the interface requirements
for a process. Use descriptive names for labelling data flows.

Ensure that all flows to external entities on lower level diagrams balance
with data flows from external entities on upper level diagrams. In other
words, a new data flow cannot be created at a lower level if it was not
identified on an upper level diagram.

Double-headed data flows are permitted when the data flowing in both
directions are identical.

Data flows from/to external entities to/from data stores are not permitted.
All data must flow through a process.

Be careful not to produce long names for complex data flows.

As a rule of thumb, a DFD component (process, data store, or external

entity) should not have more than seven data flows connected to it.

Flows that access stored data are called access flows.

Flows that are used to synchronize the system control flow and do not require
data are called event flows. Common uses include starting, stopping, and
changing the system status. Event flows are also known as control flows.

Flows can be continuous or discrete. A discrete flow is only present for an

instant of time. A continuous flow persists over time.

Types of Flows Example:

Guidelines

A data flow name should be a singular noun phrase (e.g., delivery list, customer
information, credit limit).

Naming access flows is optional.

An event flow name should be a singular verb or noun phrase (e.g., start, stop,
item available, processing complete).

If a data flow contains multiple attributes (i.e., data elements), an attribute list
should be provided.

STORES

Definition

Stores represent information (i.e., data or control) at rest. Stores are used when
different processes need to share information but are active at different times.
Information can be written to a store and read from a store.

Types of Stores

Stores that contain data are called data stores.

DATA STORES ON A DFD

Identifying Data Stores

Data stores are usually derived from the entities in an entity-relationship

diagram.
Creation of Data Stores

Data stores are created to store information for later use. They represent
data that is temporarily at rest between processes. For example, a data
store is needed to store data that is generated on a daily basis but is
required for a process that runs weekly.

Local and Shared Data Stores

Local data stores are data stores whose accesses are contained
completely within the boundary of a DFD.

A data store crossing the boundary of a DFD process indicates that it is

shared by processes on another DFD.

Drawing Data Stores on a DFD

A data store can be drawn on the same DFD more than once to reduce
the visual complexity of the drawing. An extra vertical bar is drawn in the
duplicated data stores to indicate that it appears elsewhere on the same
diagram.

Stores that contain status or control information are called event stores. Event
stores are used to save events that have occurred but have not yet been used.
Unlike a data store, an event store has behaviour associated with it which is not
apparent when looking at the data flow diagram. If the system accesses an event
store and the event has not occurred, the system will be suspended until the
event occurs. Once an event has occurred, accessing it will remove it from the
event store.

Types of Stores Example

Guidelines
 The data stores on the data flow diagram map to the entities on the entity-
relationship diagram.

Minimize the use of event stores on the DFD. Try using flags instead.

PROCESSES

Definition

Processes are also known as data transforms. Processes transform input flows
into output flows in a defined manner.

A process is a distinct activity (or set of activities) described by its inputs and
outputs. A process describes a unique behaviour that has a beginning and an
end. A process is performed repeatedly.

Types of Processes

A data process transforms input data into output data. Data processes act
directly on data, either from flows or stores. They represent the functionality of
the system.

A control process transforms input events into output events and is used on a
data flow diagram to indicate the presence of a state transition diagram. Control
processes cannot transform data but can control processes that do. A state
transition diagram describes the behaviour of the control process.

Types of Processes Example

Guidelines
 A process name and number must be unique. A process can only exist once on a
data flow diagram.

A process must have at least one input and one output. In other words, a process
is asked (i.e., triggered) to do something and then must deliver (i.e., respond).

A data process cannot input or output discrete event flows (i.e., a data process
should not control the system, it should do the work).

A control process cannot input or output data flows (i.e., a control process
should control the system, not do the work).

A process name should start with an active verb (e.g., Produce Items, Control
Production).

A process exists to do something (i.e., transform input flows into output flows),
therefore a process must have an incoming set of requirements to which it must
conform.

An nth-level (i.e., next level of detail) data flow diagram must describe its parent
process. An nth-level data flow diagram is a decomposition of its parent process
and cannot introduce new functionality.

Notation

There are several conventions used to depict the DFD.

NOTATION ON A DATA FLOW DIAGRAM

Gane and Sarson

The notation described below and used in this technique was

popularized by Gane and Sarson:

• Round-ended rectangles represent processes.

• Squares identify external entities.

• Arrows indicate flows.

• Open-ended rectangles identify stores.

• Diagonal line across the lower-left corner of an external

entity square indicates it appears elsewhere on the same DFD.

• Extra diagonal line on a data store rectangle indicates it

appears elsewhere on the same DFD.

• Double-headed arrow indicates the same data flowing in

both directions.

Yourdon, DeMarco, and Others

Another notation popularized by Yourdon, DeMarco, and others is

described below:
 • Circles represent processes.

• Squares identify external entities.

• Arrows indicate flows.

• Rectangles open on both ends identify stores.

Extensions

To support the use of DFDs in describing how systems respond to

events, the notation has been extended to include the control-oriented
information typically needed to describe real-time systems. The widely
adopted convention is to represent the control components using dashed
lines. The extensions apply to both notations described above

Using External Events to Derive Data

Flow Diagrams
Craig Borysowich | Feb 15, 2007 | Comments (10)

Identify the external events (from the event list) that have a data event
classification. Data events cause data to be transformed. A data flow diagram is
used to describe this type of behaviour.

An external event may have multiple classifications. If one of the external

event's classifications is "D" (i.e., data event) then a data flow diagram is used to
model the data transformation component of the system response.

USING EXTERNAL EVENTS TO IDENTIFY PROCESSES

The event response can be used to determine the required behaviour and name
of a process. Responses and processes are not necessarily at the same level of
abstraction. Responses that represent low-level activities must be grouped into
related processes. Responses that represent high-level functions must be
decomposed into low-level processes.

Group related responses together. Responses can be related by the activities that
they perform (i.e., if responses do the same things you may want to group them
together). Responses can also be related by the data that they use (i.e., if
responses use the same data you may want to group them together).

If there are multiple responses to an event, multiple processes may be required.

If an event has multiple responses and each response processes different data,
then a different process should be created for each response since each process
will use different data flows and data stores. Separating the processes will
simplify their interfaces.

Different processes should also be created when different external events have
similar responses but process different data.
 The same process may be used by different responses as long as the process's
behaviour and data requirements are the same for each event.

USING EXTERNAL EVENTS TO GROUP PROCESSES

You can also use external events to group related processes (i.e., identify parent
processes).

Identify control events (i.e., the events that use a state transition diagram to
describe the system's response). State transition diagrams describe processing
sequence, therefore the processes controlled by a state transition diagram should
be grouped together with the control process that prompts (i.e., controls) them.

Identify the data processes controlled by a control process. Group the data
processes and the control process together under the same parent process.