18-09-2012, 03:38 PM
Understanding Data Flow Diagrams
DFD_over_Flowcharts.pdf (Size: 60.28 KB / Downloads: 170)
Data flow diagrams (DFDs) reveal relationships among
and between the various components in a program or
system. DFDs are an important technique for modeling a
system’s high-level detail by showing how input data is
transformed to output results through a sequence of
functional transformations. DFDs consist of four major
components: entities, processes, data stores, and data
flows. The symbols used to depict how these components
interact in a system are simple and easy to understand;
however, there are several DFD models to work from,
each having its own symbology. DFD syntax does remain
constant by using simple verb and noun constructs. Such
a syntactical relationship of DFDs makes them ideal for
object-oriented analysis and parsing functional
specifications into precise DFDs for the systems analyst.
Entity-Relationship Diagrams (ERDs)
Entity-Relationship Diagrams (ERDs) are another way
of showing information flow for a process. An ERD
shows what data is being used in the process or program,
and how the files are related. The E-R (entityrelationship)
data model views the real world as a set of
basic objects (entities) and relationships among these
objects. It is intended primarily for the database design
process by allowing for the specification of an enterprise
scheme. This enterprise scheme represents the overall
logical structure of the database. ERDs do not show any
program functions, nor data flow. An ERD is shown in
Figure 2.
Process for Developing DFDs
Data flow diagrams can be expressed as a series of
levels. We begin by making a list of business activities to
determine the DFD elements (external entities, data
flows, processes, and data stores). Next, a context
diagram is constructed that shows only a single process
(representing the entire system), and associated external
entities. The Diagram-0, or Level 0 diagram, is next,
which reveals general processes and data stores (see
Figures 5 and 6). Following the drawing of Level 0
diagrams, child diagrams will be drawn (Level 1
diagrams) for each process illustrated by Level 0
diagrams.
Some Guidelines About Valid and Non-
Valid Data Flows
Before embarking on developing your own data flow
diagram, there are some general guidelines you should
be aware of.
Data stores are storage areas and are static or passive;
therefore, having data flow directly from one data store
to another doesn't make sense because neither could
initiate the communication.
Data stores maintain data in an internal format, while
entities represent people or systems external to them.
Because data from entities may not be syntactically
correct or consistent, it is not a good idea to have a data
flow directly between a data store and an entity,
regardless of direction.
Data flow between entities would be difficult because it
would be impossible for the system to know about any
communication between them. The only type of
communication that can be modeled is that which the
system is expected to know or react to.
Processes on DFDs have no memory, so it would not
make sense to show data flows between two
asynchronous processes (between two processes that
may or may not be active simultaneously) because they
may respond to different external events.
CONCLUSION
Data flow diagramming is a highly effective technique
for showing the flow of information through a system.
DFDs are used in the preliminary stages of systems
analysis to help understand the current system and to
represent a required system. The DFDs themselves
represent external entities sending and receiving
information (entities), the processes that change
information (processes), the information flows
themselves (data flows)