DATA FLOW DIAGRAM

Presented by
Your Name
What is DFD?
• A data flow diagram (DFD) illustrates how data is processed by a system
in terms of inputs and outputs. As its name indicates its focus is on the
flow of information, where data comes from, where it goes and how it
gets stored.
History of Data Flow Diagrams
• Data flow diagrams became popular in the 1970s in software
development. They were first described in a classic text about
Structured Design written by Larry Constantine and Ed Yourdon.
Yourdon & Coad's Object Oriented Analysis and Design (OOA/OOD) was
a way of visualizing software systems before UML diagrams.
Data Flow Diagrams Symbols
• There are essentially two different types of notations for data flow
diagrams (Yourdon & Coad or Gane & Sarson) defining different visual
representations for processes, data stores, data flow and external entities.
• Yourdon and Coad type data flow diagrams are usually used for system
analysis and design, while Gane and Sarson type DFDs are more common
for visualizing information systems.
• Visually, the biggest difference between the two ways of drawing data flow
diagrams is how processes look. In the Yourdon and Coad way, processes
are depicted as circles, while in the Gane and Sarson diagram the processes
are squares with rounded corners.
Process Notations
• . A process transforms incoming data flow into outgoing data flow.
Datastore Notations.
• Datastores are repositories of data in the system. They are sometimes
also referred to as files.
Dataflow Notations
• . Dataflows are pipelines through which packets of information flow.
Label the arrows with the name of the data that moves through it.
External Entity Notations.
• External entities are objects outside the system, with which the system
communicates. External entities are sources and destinations of the
system's inputs and outputs.
Data Flow Diagram Levels
• Context Diagram. A context diagram is a top level (also known as "Level 0") data
flow diagram. It only contains one process node ("Process 0") that generalizes
the function of the entire system in relationship to external entities.
• DFD Layers. Draw data flow diagrams can be made in several nested layers. A
single process node on a high level diagram can be expanded to show a more
detailed data flow diagram. Draw the context diagram first, followed by various
layers of data flow diagrams.
• DFD Levels. The first level DFD shows the main processes within the system.
Each of these processes can be broken into further processes until you reach
pseudo code
Context Diagram
LEVEL 1
Level 2
Data Flow Diagram Tips and Cautions
Be aware of the level of details
• In most cases, Data Flow Diagram is drawn in the early phase of system
development, where many details are yet to be confirmed. The use of
general terminologies like "details", "information", "credential" certainly
leave room for discussion. However, using general terms can be kind of
lacking details and make the design lost it usefulness. So it really
depends on the purpose of your design.
Don't overdrawn
• In a Data Flow Diagram, we focus on the interactions between the
system and external parties, rather than the internal communications
among interfaces. Therefore, data flows between interfaces and the
data stores used are considered to be out of scope and should not be
shown in the diagram.
Don't mix up data flow and process flow
• Some designers may feel uncomfortable when coming across a connector connecting from a data
store to a process, without showing the step of data request being specified on the diagram. Some
designers will attempt to put a request attached to the connector between a process and a data store,
labeling it "a request" or "request for something", which is surely unnecessary.
• Keep in mind that Data Flow Diagram was designed for 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 literally 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, however, 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,
you could use either Activity Diagram or BPMN Business Process Diagram instead. If you want to
model the internal structure of data store, you may use Entity Relationship Diagram.