Process-Oriented Design
7. Summary
In this chapter, structured design which follows structured analysis in development, was discussed. The results of structured analysis-a set of leveled data flow diagrams, data dictionary, and procedural requirements-are the inputs to the design process. The major results of structured design are program specifications which detail the mapping of functional requirements into the production hardware and software environment.
First, using either transaction or transform analysis, the DFD is partitioned into afferent, efferent, and central transform processes. The streams of processing are factored to develop a structure chart. The processes are further decomposed into system-like subprocesses until further decomposition would change the nature of the process. Data requirements are documented in data couples; control is documented in control couples. The chart is evaluated for fan-out, fan-in, skew, cohesion, coupling, scope of effect, and scope of control. The structure chart is revised and reevaluated as required.
The physical database is designed. Data needs for each data flow in the application are listed by process. Data similarities are matched and used to define user views. The access method and physical mapping are then decided. Physical database design walk-throughs may be held to validate the design. Test and production databases are created.
Program packages are decided based on the application concept and timing. The packages define which modules will communicate and how. Pseudo-code for processes is finalized and uses only structured programming constructs-iteration, sequence, and selection. Decision tables and trees are used, as necessary, to document complex decisions.
Finally, program specifications are written to document all known information about each module, function, or program. Specifications include data, process, interface, constraint, and production information needed for a programmer to code and unit test
the work.