Structured programming can be used to develop a large system in an evolving tree structure of nested program modules, with no control branching between modules except for module calls defined in the tree structure. By limiting the size and complexity of modules, unit debugging can be done by systematic reading, and the modules can be executed directly in the evolving system in a top down testing process.
Large systems programming today is dominated by the integration and debugging problem because it is commonly assumed that logic errors are inevitable in programming systems (in contrast to syntax errors, which are detected by translators). There is no doubt that programmers are fallible and always will be. But it now appears possible to organize and discipline the program design and coding process in order to (1) prevent most logic errors in the first place and (2) detect those errors remaining more surely and easily than before.
We will use the term "structured programming" to denote a complex of ideas of organization and discipline in the programming process. There are two major principles involved. First, beginning with a functional specification, we will show that it is possible to generate a sequence of intermediate systems of code and functional subspecifications so that at every step, each system can be verified to be correct, that is, logically equivalent to its predecessor system. The initial system is the functional specification for the program, each intermediate system includes the code of its predecessor, and the final system is the code of the program. The transitivity of these step-by-step equivalences then insures the correctness of the final code with respect to the initial functional specifications. The code of the program is generated from the "top down" in this sequence of intermediate systems. Second, it can also be shown that the control logic of each successive system of code and functional subspecifications can be completely organized in terms of a few basic control structures, each with a single entry and a single exit. Three basic control structures sufficient for control logic are (1) simple sequencing, (2) IF-THEN-ELSE, and (3) DO-WHILE structures, already known in several languages, for example, PL/1. For efficiency, a CASE structure may also be desirable, for example, as defined in PL360.
The iterated expansions of functional specifications and of intermediate functional subspecifications into code and possibly into more detailed functional subspecification reflect a rigorous step-by-step process of program design. Each functional subspecification defined in an intermediate system represents only a mapping of initial data into final data for some segment of coding yet to be specified. The expansion process describes the means selected for this mapping, using possibly more detailed mappings to be similarly described later.
In traditional terms this programming design process is carried out top down on paper, using flowcharts or any other conceptual objects available to describe the design structure selected for each portion of the system. Once the design is completed, the resulting modules defined are coded, unit tested, integrated into subsystems, then into a system, and finally debugged as a system, in a bottom up coding and testing process.
In the structured programing process this design structure is carried out directly in code, which can be at least syntax checked, and possibly executed, with program stubs standing in for functional subspecifications. Instead of paper flowcharts, the structured design is defined in IF-THEN-ELSE and DO-WHILE code, which connect newly defined subspecifications. In fact, program stubs can be used to simulate the estimated core and throughput requirements of the code yet to be developed for given functional subspecifications, during executions of intermediate systems.
The functional expansion process can be carried out literally in a page of code at a time, in which new functional subspecifications are denoted by names of dummy members of a programming library, which will eventually hold the code for the next level of expansion. Such a page, called a segment, is itself identified by name and corresponding functional subspecification at the next higher level segment in the programming system. The segments of a program form a tree structure.
A functional subspecification, as a mapping from initial data to final data, has no implicit control logic, and this is reflected in its corresponding segment. A segment has only one entry, at the top; and one exit, at the bottom. If other segments are named within it, such segments are in turn entered at the top and exited out the bottom, back into the naming segment. As such, a named segment behaves precisely as a simple data transformation statement (possibly quite complex, according to its functional subspecification), without any possible side effects in program control.
Yes. Nothing like what we do in Agile. Good stuff at the time.