DFD(Data Flow Diagram)

Data flow diagram (DFD)

• A data flow diagram (DFD) is a graphical or visual representation using
a standardized set of symbols and notations to describe a business's
operations through data movement.
How are data flow diagrams used?

• DFDs make it easy to depict the business requirements of applications

by representing the sequence of process steps and flow of
information using a graphical representation or visual
representation rather than a textual description.
• When used through an entire development process, they first
document the results of business analysis.
• Then, they refine the representation to show how information moves
through, and is changed by, application flows.
Logical DFD vs. Physical DFD

• Logical DFDs represent logical information flows .

• This means that they will identify general processes, systems and
activities but not provide technology detail.
• Physical DFDs show more physical information flow detail, particularly
details of information systems, applications and databases.
• They will also often have more elements to better depict what information
is flowing, what actions are taken on or with the data and the resources
associated with those actions.
• It's important to note that there are many interpretations of "logical"
and "physical" with respect to DFDs.
• Enterprise architects and line organizations will tend toward logical
DFDs and will often show fewer details on physical DFDs.
Development teams have the opposite orientation and will tend to
use physical over logical DFDs.
DFD notions/Symbols

• External entity: an outside system that sends or receives data,

communicating with the system being diagrammed.
• They are the sources and destinations of information entering or
leaving the system.
• They might be an outside organization or person, a computer system
or a business system.
• They are also known as terminators, sources and sinks or actors.
• They are drawn on the edges of the diagram.
• Process: Any process that changes the data, producing an output.
It might perform computations, or sort data based on logic, or direct the data
flow based on business rules.

• Data store: files or repositories that hold information for later use, such as a
database table or a membership form.

• Data flow: The route that data takes between the external entities, processes and
data stores.
It portrays the interface between the other components and is shown with
arrows.
• Different DFD methodologies use different symbol conventions.
• The differences and symbol rules are divergent enough to make it
difficult for technologists to read the DFDs of methodologies they're
not familiar with.
• For example, in Gane and Sarson, entities are boxes with square
corners and processes have rounded corners.
• However, in Yourdon and De Marco, entities have square corners, but
processes are circles.
• SSADM(Structured systems analysis and design method ) almost
reverses Gane and Sarson conventions.
• Stores in Yourdon and De Marco are shown as parallel lines, but all
the other methodologies use a different representation.
• For this reason, it's important for a company to select a methodology
and symbology and stay with it.
DFD levels and layers:
• From context diagrams to pseudocode
• A data flow diagram can dive into progressively more detail by using
levels and layers, zeroing in on a particular piece.
• DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3
or beyond.
• The necessary level of detail depends on the scope of what you are
trying to accomplish.
• DFD Level 0 is also called a Context Diagram.
• It’s a basic overview of the whole system or process being analyzed or
modeled.
• It’s designed to be an at-a-glance view, showing the system as a single high-
level process, with its relationship to external entities.
• It should be easily understood by a wide audience, including stakeholders,
business analysts, data analysts and developers.
• DFD Level 1 provides a more detailed breakout of pieces of the
Context Level Diagram.
• You will highlight the main functions carried out by the system, as you
break down the high-level process of the Context Diagram into its
subprocesses.
• DFD Level 2 then goes one step deeper into parts of Level 1.
• It may require more text to reach the necessary level of detail about
the system’s functioning.
• Progression to Levels 3, 4 and beyond is possible, but going beyond
Level 3 is uncommon.
• Doing so can create complexity that makes it difficult to
communicate, compare or model effectively.
• By becoming sufficiently detailed in the DFD, developers and
designers can use it to write pseudocode, which is a combination of
English and the coding language.
• Pseudocode facilitates the development of the actual code.
DFD balancing
• Balancing DFD : Parent dfd having inflow and out flow of data should
match data flow at next child level. This is known as balancing a DFD.
Level1 DFD
• In Level 1 DFD, data items D1 flow out of bubble 2 and item D2 flows into
bubble 2. In next level, bubble 2 is decomposed into three sub process(2.1,
2.2, 2.3).
It has data item D1 flowing out and D2 flowing in.
So DFD is balanced here.
A bubble representing a process should have minimum one input and one
output flow.
When a bubble has input flow without any output flow, it is known as “black
hole”.
When a process has output flows but no input flows, it is called a “miracle”.
A processing step may have outputs that are greater than sum of its inputs is
called Grey holes.
Common mistakes to avoid while constructing
DFDs :
• DFDs should always represent data flow and there should be no
control flow.
• All external entities should be represented at context level.
• All functionality of system must be captured in dfd and none should
be overlooked. Also, only those functions specified in SRS should be
represented.
• Arrows connecting to data store need not be annotated with any data
name.
• DFDs should always be balanced at all levels. Dataflow in and out of
parent process must be present in child diagram.
• Context level bubble always contains name of entire system in form of
noun and no verb can be used in its representation.
• There should not be any database in level 0. Level 0 contains only one
bubble and external entities.
• All bubbles having unique process in DFDs should be connected to
another process or to a data store. It cannot exist by itself,
unconnected to rest of system.
Example:Library Information System
• Level 1 DFD –
At this level, the system has to show or exposed with more details of
processing.
The processes that are important to be carried out are:
• Book delivery
• Search by topic
• List of authors, List of Titles, List of Topics, the bookshelves from
which books can be located are some information that is required for
these processes. Data store is used to represent this type of
information.
Level1 DFD
Level2 DFD
• DFD vs. Unified Modeling Language (UML)
• While a DFD illustrates how data flows through a system, UML is a
modeling language used in Object Oriented Software Design to
provide a more detailed view.
• A DFD may still provide a good starting point, but when actually
developing the system, developers may turn to UML diagrams such as
class diagrams and structure diagrams to achieve the required
specificity.
What tools can be used to create a DFD?
• While it is possible to draw DFDs by hand.
Some DFD tools include:
• Lucidchart
• Visual Paradigm
• Smartdraw
• ConceptDraw
• Creately
• https://www.techtarget.com/searchdatamanagement/definition/data
-flow-diagram-
DFD#:~:text=A%20data%20flow%20diagram%20(DFD)%20is%20a%20
graphical%20or%20visual,and%20Design%20Method%20(SSADM).
• https://www.lucidchart.com/pages/data-flow-diagram