Unified Control and Data Flow Diagrams Applied to Software Engineering and other Systems

📝 Abstract

More often than not, there is a need to understand the structure of complex computer code: what functions and in what order they are called, how information travels around static, input, and output variables, what depends on what. As a rule, executable code and data are scattered among multiple files and even multiple modules. Information is transmitted among variables which often change names. These tangled relations greatly complicate the development, maintenance, and redevelopment of code, its analysis for complexity and its robustness. As of now, there is no tool which is capable of presenting the real-life, useful diagram of actual code. Conventional flowcharts fail. Proposed is the method which overcomes these difficulties. The main idea is that functionality of software can be described through flows of control, which is essentially flows of time, and flows of data. These are inseparable. The second idea is to follow very strict system boundaries and distinctions with respect to modules, functions, blocks, and operators, as well as data holders, showing them all as subsystems, in other words, by clearly expressing the system structure when every piece of executable code and every variable may have its own graphical representation. The third is defining timelines as the entities clearly separated from the connected blocks of code. Timelines allow presentation of nesting of the control flow as deep as necessary. As a proof of concept, the same methods successfully describe production systems. Keywords: flowchart, UML, software diagram, visual programming, extreme programming, extreme modeling, control flow, data flow.

💡 Analysis

More often than not, there is a need to understand the structure of complex computer code: what functions and in what order they are called, how information travels around static, input, and output variables, what depends on what. As a rule, executable code and data are scattered among multiple files and even multiple modules. Information is transmitted among variables which often change names. These tangled relations greatly complicate the development, maintenance, and redevelopment of code, its analysis for complexity and its robustness. As of now, there is no tool which is capable of presenting the real-life, useful diagram of actual code. Conventional flowcharts fail. Proposed is the method which overcomes these difficulties. The main idea is that functionality of software can be described through flows of control, which is essentially flows of time, and flows of data. These are inseparable. The second idea is to follow very strict system boundaries and distinctions with respect to modules, functions, blocks, and operators, as well as data holders, showing them all as subsystems, in other words, by clearly expressing the system structure when every piece of executable code and every variable may have its own graphical representation. The third is defining timelines as the entities clearly separated from the connected blocks of code. Timelines allow presentation of nesting of the control flow as deep as necessary. As a proof of concept, the same methods successfully describe production systems. Keywords: flowchart, UML, software diagram, visual programming, extreme programming, extreme modeling, control flow, data flow.

📄 Content

Unified Control and Data Flow Diagrams Applied to Software Engineering and other Systems by Igor Polkovnikov 2016, October 3 San Francisco, CA, USA Introduction More often than not, there is a need to understand the structure of complex computer code: what functions and in what order they are called, how information travels around static, input, and output variables, what depends on what. As a rule, executable code and data are scattered among multiple files and even multiple modules. Information is transmitted among variables which often change names. These tangled relations greatly complicate the development, maintenance, and redevelopment of code, its analysis for complexity and its robustness. As of now, there is no tool which is capable of presenting the real-life, useful diagram of actual code. Conventional flowcharts fail. Proposed is the method which overcomes these difficulties. The main idea is that functionality of software can be described through flows of control, which is essentially flows of time, and flows of data. These are inseparable. The second idea is to follow very strict system boundaries and distinctions with respect to modules, functions, blocks, and operators, as well as data holders, showing them all as subsystems, in other words, by clearly expressing the system structure when every piece of executable code and every variable may have its own graphical representation. The third is defining timelines as the entities clearly separated from the connected blocks of code. Timelines allow presentation of nesting of the control flow as deep as necessary. As a proof of concept, the same methods successfully describe production systems. Keywords: flowchart, UML, software diagram, visual programming, extreme programming, extreme modeling, control flow, data flow. If one intends to make a diagram which reflects the structure of the current code, the data and control flows must both be present. Since these flows are fundamentally different, they are represented by two different directed lines:

• A straight angled thin line represents control flow.
• A curved thicker line represents data flow. Thinking philosophically, control flow is a flow of the time allotted for different components. Most software processes have essentially a sequential nature, but, of course, there are “parallel” ones. Hardware works in such a way as to grant time from higher-level processes, or functions and operators, to the lower-level ones. If so, it is then possible to say that “time flows from one component to another”.

Data flow is a flow of information from one data holder to another. A data holder is a register, memory location, or even a signal and therefore a variable, file, paper, and so on. We say that information flows from one location to another. Mechanisms providing this are processes. Both data and control flows are essential to understanding the structure and the way of operating of a software process, on both a small and on a large scale. Representing it with a diagram was the dream of many generations of software developers, especially those who “think visually”. The complexity of even simple pieces of code prevented it from becoming successful. Many attempts have been made to diagram the software, but it has ether drowned in unnecessary details or is too simple and does not represent the real system with all its bugs, unintended logical and hardware dependencies, and language particularities. It is therefore, of little value in solving practical problems. Many attempts has been made to overcome these difficulties. Let me present one more. Process Data

• A rectangle represents a process. (A “process” in the most general meaning) It is hard to believe that a diagram is capable of representing the entire complexity of the relations of any working software. If it is made, because of its vastness, humans would not be capable of comprehending it in detail, unless it is of interest to overview the system as whole, grasping the intuitive properties that are most visible. That can be useful. However, in practice, a hierarchical way would be preferred, where the diagram complexity is chosen based on a task to solve. Therefore the same diagramming method has to be able to present the lower level, down to single operators or even the assembler, up to functions, classes, and processes within a single program, computer, or network. Abbreviations have to be identical. If so, it means that the abstraction of underlying information processes have been found. If the same method could be applied to other systems such as devices, machinery, tools, and production lines, that would support the strength and correctness of the method.
• An ellipse represents a data holder. Software specifies data holders as physical entities. Information is transferred among data holders by means of processes. Note, that method presented here does not deal with the structure of information. I

This content is AI-processed based on ArXiv data.