10.2 An Overview of Data-Flow-Analysis Approach


The system design phase is the development stage where the overall architecture and structure of the
proposed system is decided.
The system is divided into a set of sub-systems that interact with each other.
Then, the specifications of each sub-system are defined by the system analyst as well as the system
requirements.
To perform data-flow analysis of programs, flow equations representing every node of the control flow graph
are created by the system analyst.
The equations are used to calculate the output, based on the input of each node until the whole program is
'stabilized'.
Efforts have been expanded to formulate guidelines for application of analysis and design principles based on
data flow based methods.
Analysis and design principles based on data flow-based methods are powerful means to support the
requirements analysis process.
They bridge the gap between requirements analysis and the computational aspects of data flow oriented
models; and provide a systematic approach for effective structuring and managing complexity in the system
under consideration.

10.2 An Overview of Data-Flow-Analysis Approach


Data flow diagrams (DFDs) were invented by Larry Constantine, the original developer of structured design.
Most of his work concerning data flow diagrams was derived from Martin & Estrin's data flow graph model of
computation.
DFDs can be described as being one element (out of three) of the Structured-Systems Analysis and Design
Method (SSADM).
In order to produce effective DFDs, the stakeholders of the project/software system have to be involved in all
the stages of the design.
DFDs play a major role in the design process as they allow users, as well as designers to picture how the
system will work, what will it achieve, and how it will be put together to achieve its objectives.
As well as this, DFDs provide users with the opportunity to see how their input affects the system as whole as
well as adjacent parts of the system.
One important step in system design is to design a valid and efficient data flow model that accurately specifies
the execution sequence of activities in the proposed project/system.
The data flow constraints, which define the data input and output of each activity in a project/system, can be
used to analyze the dependencies among different activities and determine a proper work flow model for a
particular project/system.

10.2 An Overview of Data-Flow-Analysis Approach


Disadvantages of using data flow diagrams in system analysis and design include the following:
It is difficult to determine the processes (graph nodes) appropriately
Graph nodes have difficulty to be partitioned in a meaningful and mutually agreed upon manner.
A large documentation size is required to understand Data Flow Graphs.
The DFDs are strongly functional in nature and thus subject to frequent change
Although data flow is emphasized in DFDs, data modeling is not.
In addition, customers can have hard times to follow how the system concepts are mapped into data
flow graph nodes, it has also been very hard for the designers to implement these graphs.
Details of input/output are weakly displayed.
DFDs do not represent time
Advantages of using data flow diagrams in system analysis and design include the following:
Users as well as designers will be able to picture how the system will work, what will it achieve, and how
it will be put together to achieve its objectives.

10.2 An Overview of Data-Flow-Analysis Approach


The system developers may draw new versions of the system using new data flow diagrams and
then compare these new DFGs with old system's dataflow diagrams and use these comparisons
to implement a more efficient system.
DFDs provide users with the opportunity to see how their input affects the system as whole as well as
adjacent parts of the system.
A system is development can be determined through a dataflow diagram.