Home » Technology » Software Re-engineering » Recording the Data Flow in the Program

Recording the Data Flow in the Program

© Faisal Bin Bashir

The fifth step is to develop a data-flow model. First of all, what is data-flow in a program? Data-flow is the flow of data among different data items or variables inside a program. This tells us if a data item is dependent on another, then what is the nature of the dependency. This thing helps in the impact analysis of the program, i.e., if a variable is changed, what are the other variables that would be impacted by this change, or, if it is OK to change a variable or not? Software change impact analysis is a separate topic and involves both the data-flow and the control-flow in the program. I'll dedicate some articles on this topic later. The purpose was to give you a general picture why the data-flow is important. Take the example of the Millenium Date Problem. If you want to change a variable containing date in a COBOL program, you have to search its path from the beginning till the end, so that you know what value is coming into this variable (how the previous variables influence this variable) and what are the variables that would be impacted if this variable is changed so that you can add an appropriate patch to the code.

Structured design gives guidelines for transforming data-flow diagrams into structure charts. To some extent, these guidelines can be reversed. The idea is to identify transformations on data expressed in the detailed design and use these transformations to create processes in a data-flow model.

The data-flow model consists of a hierarchy of the data flow diagrams. The top-level diagram shows a single process representing the program and its input sources and output destinations. The process in the top-level diagram is then expanded in a diagram. This second level diagram show processes that together do the transformation attributed to the top-level process. Each of these processes can be expanded into lower level diagrams that show even more detailed transformations. Processes can be expanded into more detailed data-flow diagrams until atomic processes are reached.

Data-flow diagrams can be constructed from the recovered detailed design in a number of ways. One of the procedures could be to identify the data transformations in the detailed design using a two step process. In the first step, each node in the structure chart becomes a process in a data-flow diagram. The names given to processes in the data-flow diagrams can be different from the structure chart nodes. Descriptive process names that suggest the task of a process can be used. This step creates a hierarchy of data-flow diagrams. In the second step, the PDL associated with each structure chart node is examined and data transformations are identified. Such transformations are then added to the appropriate data-flow diagram as new processes with descriptive names. In this fashion all data transformations present in the detailed design are captured in the data-flow model.