Department of Electrical and Computer Engineering
Dalhousie University

Introduction to Dataflow Diagrams

Dr. Larry Hughes

Introduction

A dataflow diagram is a modelling tool that displays the system as a network of functions (or processes) interconnected by streams of data. Dataflow diagrams are particularly useful when describing a system in terms of its functionality, allowing the system analyst to represent things such as:

• the functions the system must perform,

• the flow of data through the system, and

• the interaction of the system with the outside environment.

Dataflow diagrams are far from new; many organizations use them to represent the structure and flow of goods within the organization. More formally, they are graph-theoretic representations of a system (also known simply as "graph theory").

Other names used for dataflow diagrams include bubble chart, bubble diagram, process model, and function model.

The Dataflow Diagram

A dataflow diagram consists of four components: the process, the flow, the store, and the terminator. If drawn correctly, it can give a clear and understandable representation of the overall system. For example, a dataflow diagram for part of a library circulation system, book checkout, could be drawn as follows:

The above dataflow diagram illustrates the simplicity of the dataflow diagram; note the following:

• nothing is said about the patron (a terminator), other than it supplies books and user ids to the checkout process and receives books from the book checkout (a process),

• the flows between the patron, the checkout process, and the database (a store) can be 'physical' (e.g., a book) or they can be 'data' (in the form of the book's barcode number and the user's id),

• the details of the checkout process is hidden, and

• how the information is stored (in the store) is also left as an implementation detail.

Elements of a Dataflow Diagram

Process

A process is an object that takes inputs and transforms them into outputs. A process is always labelled (i.e., given a name); in general, the name should indicate what the process does (for example, DISPENSE TICKET or CALCULATE CHANGE), although in some cases, a process can be the name of the object that performs the task (for example, SERVER 1). Processes can be represented in a number of different ways; typically circles or rounded rectanges:

A useful rule-of-thumb is to create a label that is an action referring to a thing.

Flow

Data traverse between processes; the direction of the data is indicated by a labelled arrow referred to as a flow:

The label associated with the flow usually refers to data within the machine, but it can represent the movement of physical entities as well. For example, a book can be supplied to the libary checkin module, which passes it to the reshelving module, and is subsequently shelved:

A flow should carry a single type of data. For example, rather than referring to a flow consisting of apples, oranges, and pears, a single name should be used, such as fruit, which is defined as including apples, oranges, and pears (how this is defined is part of the data dictionary).

Broadly speaking, there are three types of flow:

Flow into a process or input flow.

Flow out of a process or output flow.

Bidirectional flow into/out of a process or dialog flow.

Flows can diverge and converge, as determined by the requirements of the system:

Store

A store is any object that can hold data. Data flow into the store from one process and out of the store to another process. A store is represented by two parallel line with the name of the data that is held by the store between these line (note that the name is the plural of the name on the flow since the store is assumed to hold many of what traverses the flow):

Although a store is probably some form of electronic media (e.g., disk or tape), there is nothing to stop it from being something such as a library cart holding books, a filing cabinet, or even in in-tray.

If the labels are omitted from the flows into/out of the store, it is assumed that the name in the store is the plural of the flows; for example, in the following diagram, it would be assumed that the flows were labelled Book:

If the systems analyst decides to omit the store from the dataflow diagram, the flow replacing the original flows and store should be the plural of the individual flows:

There are two types of store:

1. A user specified store which must be included in the system, as it is required by the user.

2. An implementation store, which is included in the system because the system analyst deems it necessary. Reasons for an implementation store are:
   • The time at which input flow is expected may occur later than when the output flow was generated. In this case, it is necessary to store the output flow until the input flow takes place.

   • It may be necessary to backup sensitive data.

   • Saving flow values can permit the external examination of the data; for example, for debugging purposes.

   • The system analyst may decide that the user will need this data at sometime in the future.

The store is assumed to be non-destructive; it is assumed, that data within the store cannot be lost.

Terminator

A terminator is an entity that is external to the system being modelled (i.e., it is outside the influence of the system), but communicates with the system. Terminators represents the interface between the outside world and the system; they cannot be changed. A terminator is represented as a labelled rectangle:

Terminators connect to processes or stores via flows; data can flow into or out of a terminator. A terminator's flow can be to or from a store or a process. Since terminators are outside the influence of the system, any flows between terminators are ignored.

© 2005 -- Whale Lake Press