Project Report of Electricity Billing System Page - 31 There are seven rules for construct a data flow diagram. i) Arrows should not cross each other.
ii) Squares, circles and files must wears names.
iii) Decomposed data flows must be balanced.
iv) No two data flows, squares or circles can be the same names.
v) Draw all data flows around the outside of the diagram.
vi) Choose meaningful names for data flows, processes & data stores.
vii) Control information such as record units, password and validation
requirements are not penitent to a data flow diagram.
Additionally, a
DFD can be utilized to visualize data processing or a structured design.
This basic DFD can be then disintegrated to a lower level diagram demonstrating
smaller steps exhibiting details of the system that is being modeled.
On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process. It is common
practice to draw a
context-level data flow diagram
first, which shows the interaction
between the system and external agents, which act as data sources and data sinks. On
the context diagram (also known as the Level 0 DFD’), the system's interactions with the
outside world are modeled purely in terms of data flows across the system boundary.
The context diagram shows the entire system as a single process, and gives no clues
as to its internal organization.
This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some
of the detail of the system being modeled. The Level 1 DFD shows how the system is
divided into sub-systems (processes), each of which deals with one or more of the
data flows to or from an external agent, and which together provide all of the
functionality of the system as a whole. The level 1 DFD is further spreaded and split
into more descriptive and detailed description about the project as level 2 DFD.The
level 2 DFD can be a number of data flows which will finally show the entire
description of the software project.