Data Flow Oriented Analysis And Design

Published Date: 02 Nov 2017

Introduction

In this lesson, an overview of data-flow-analysis is provided as well as focusing on the objectives, principles, notations, advantages, and disadvantages of data flow diagrams.

Learning Outcomes

Appreciate the importance of data-flow-analysis.

Be familiar with the objectives, principles, notations, advantages, and disadvantages of data-flow-diagrams.

1.0 Introduction

Data flow analysis is a structured systems analysis and design technique that is used in software engineering to collect certain pieces of information at different parts of a computer program application. The Data Flow Graph (DFG) and Control Flow Graph (CFG) of a program are used to establish the parts of the program in which a variable is given a particular value. Data flow analysis uses the data flow diagram approach, which is considered to be the most popular method available for systems analysis and design.

This lecture presents the data flow analysis technique and approach and its basics, principles and how it is used in software system development process.

2.0 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 interacting with each other. Then, the specifications of each sub-system are defined by the system analyst as well as the requirements of the new system by the end user.

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.

Data flow diagrams 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.

Data Flow Diagrams (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.

Disadvantages of using data flow diagrams in system analysis and design include the following:

It is difficult to determine the processes (graph nodes) appropriately

It is difficult to partition the graph nodes in a meaningful and mutually agreed upon manner,

The size of the documentation needed to understand the Data Flow Graphs is large.

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 to it is hard for the customer 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. 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.

How any system is developed can be determined through a dataflow diagram.

3.0 Data Flow Diagrams (DFDs)

Data Flow Diagram (DFD) tools are structured analysis techniques that are used for analysis and design in software development. A data flow diagram is an essential tool that is used in system analysis and design.

A DFD aid the designers/end users to visualize how the information being inputted travels through the system. The main difference between the system flowchart and the DFD is that a DFD shows the flow of data through the software instead of hardware.

Data Flow Diagram objectives include:

Providing a means for functional decomposition of projects/systems

Used as a primary tool in analysis to model data transformation in the system

As well as being a representation of how information flows in a system, DFDs also highlight the many parts of a system that are interlinked with one another.

In system analysis data flow diagram is the primary step. It shows how the data flows from higher to lower level of the software architecture. This step of using DFDs is very crucial to design. Without this step direct design can be a risky process.

DFD is a graphical representation of the "flow" of data of a software program through an information system that the program represents. DFDs can also be used for the visualization of data processing of software systems and is a tool used in structured design of software systems.

A DFD provides information on 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. A DFD does not provide information about the timing of system processes, or about whether processes operate sequentially or concurrently in parallel.

A DFD is different from a flowchart, as a flowchart illustrates how an algorithm (that is part of a program) operates in terms of what order the algorithm will take place and the various conditions that may be associated with it, if any. A DFD on the other hand concentrates on how the data is affected by the algorithms. How and from where is the data inputted and outputted and how and where it will be stored.

In DFD approach information about the way the variables are used and defined in the project/system is collected. Information at specific parts of the system is collected during the process of data-flow analysis. The parts of the system that are analyzed and have information collected at are called the ‘basic blocks’ of the system.

3.1 Basic Principles of DFDs

Each process (block/node) in the DFD has input, output, and a function. Due to blocks being ordered one after the other, the output of one block will be the input of the next one. The input of a block is always based on the output of the block before it. This produces a set of data-flow equations:

For each block i:

Outputi = functioni(inputi)

In the above equation, functioni is the function of the block i. It works on the input inputi, yielding the output Outputi. Figure 3 shows the graphical representation of block i.

Block i

….

inputi

Outputi

Figure 3: Graphical representation of block i

After solving the set of equations for all blocks of the DFG, the input and output are used to obtain information about the program such as its ‘basic blocks’ properties; for example, when does one block start and finish.

As stated before, each block will have an input and output and both are closely related to one another, as the output of one block will be the input of the next. However, the very first block in the system will not have any output from a predecessor block to use as its input and this makes its entry start a distinct one. This makes the job of solving the block equations an easy one (if no cycles/loops exist in the control flow graph), as the inputs of each block are calculated (based on the output of the preceding block). The initial value of the input states is important to obtain correct and accurate results.

3.2 Notations of Data Flow Diagrams

DFDs use a set of notations that represent various parts of the system i.e. processes, data stores, data flow, and external entities.

Data Flow Diagrams (DFDs) are directed graphs. There are two elements in the DFDs: arcs and nodes. Data is represented using arcs and circles are used to represent processes, which manipulate this data. Processes can be large and complicated but DFDs have the ability to repeatedly break processes down into small parts in order to show the sub-processes and their data flow. In addition to this, these sub-processes can be broken down further using DFDs in order to fully understand how they work and how the information flows between them. In essence, DFDs illustrate the structure of a system as an arrangement of linked processes that serve specific functions.

The lowest levels of sub-processes are processes which do not need to be broken down any further, representing the functionality of the process. The functionality of a process/sub-process is described by a process specification which can be written in many forms, including pseudo-code, flowcharts, or even in natural language e.g. English. There is an associated data dictionary with each DFD. This serves as a set of entry definition for data flows, data elements, files, and databases.

Figure 1 shows the notations and symbols used in DFD.

Represents functions in the system

Represents the external entities

Represents data flows

Represents data stores

Figure 1: The notations and symbols used in DFD

Example:

The program that computes a=(X+Y)*(W-Z) is Figure 2 is represented as a DFG in figure 3. In Figure 2, X,Y, W, and Z are inputs from the environment and A is an output to the environment. T1 and T2 are temporary results (data stores).

T1=X+Y;

T2=W-Z;

A =T1*T2;

Figure 2: A simple program that computes A=(X+Y)*(W-Z)

-

+

+

Z

W

X

Y

A

T1

T2

Figure 3: DFG of the program in Figure 2

3.3 Developing a Data Flow Diagram (DFD)

A data flow diagram is developed using the event partitioning method which was described by Edward Yourdon. This method is described in some detail below.

In the course of event partitioning method and when using DFDs to describe systems, the analyst/designers focuses on decomposing the system into component sub-systems, on identifying the transaction data in the data model. A set of leveled data flow diagrams is created during this process.

In using the data flow approach of the system analysis and design, the system engineer first draws a context-level data flow diagram (level 0 DFD). This diagram shows the interaction between the system and external environment which acts as a data source and a data sink. In this level, the interactions between the system and the outside world are illustrated only as data flows that cross the border between them. The context diagrams show the entire system as a single process, and give no hint or idea about its internal organization. This level shows the overall context of the system and its operating environment and shows the whole system as just one process (represented by a black box). It does not usually show internal details of the design such as data stores.

Context-level DFD is next expanded into Level 1 DFD (low level diagram) that shows some details of the system being modeled. Level 1 DFD shows the division of the system into sub-systems (processes). Each process in level 1 DFD deals with one or more of the data flows to or from the external environment of the system. Each process also identifies internal data processing that shows how the system does its job, and shows the flow of data between the various parts of the system. Level 1 DFD shows all processes with details such as data stores, external entities and internal entities and the data flows between them.

Level 1 DFD is a decomposition of the process shown in Level 0 DFD. Hence, there should be a Level 1 DFD for each and every process shown in a Level 0 DFD. The expanded process in Level 0 DFD is the parent of the processes in the corresponding Level 1 DFD. The processes in Level 1 DFD are children of the process in the corresponding Level 0 DFD.

The purpose of Level 1 DFD is to show the major and high-level processes of the system and their interrelation. Level 1 DFD is also called a process model. It will have one, and only one, Level 1 DFD diagram. Level 1 DFD diagram must be balanced with its parent context level diagram where there must be the same external entities and the same data flows. These external entities and the data flows can be broken down to more detail in the Level 1 DFD. A Level 1 DFD shows the "Process Enquiry" process for the same system that is represented in Level 0 DFD.

As an example, the "design an electronic device" Level 0 DFD could be split into "design data path" and "design control" Level 1 DFD.

Summary

In this lesson, an overview of data-flow-analysis is provided as well as focusing on the objectives, principles, notations, advantages, and disadvantages of data flow diagrams.