<ch62 toc ch64>

63 Structure charts

63.1 Purpose
63.2 Strengths, weaknesses, and limitations
63.3 Inputs and related ideas
63.4 Concepts
63.5 Key terms
63.6 Software
63.7 References

63.1 Purpose

A structure chart is a hierarchy chart with arrows showing the flow of data and control information between the modules. Structure charts are used as design tools for functionally decomposing structured programs.

63.2 Strengths, weaknesses, and limitations

A structure chart graphically highlights tightly coupled, excessively dependent modules that can cause debugging and maintenance problems. A structure chart is an extension of a hierarchy chart, so the core of this tool is consistent with other tools. A complete structure chart that shows all the data and control flows for a program can be very difficult to read, however.

63.3 Inputs and related ideas

A structure chart is a functional decomposition tool (# 62) based on a hierarchy chart (#s 62 and 64). Before a structure chart is prepared, each module’s inputs and outputs must be known. The necessary logical data structures and the program’s primary processes are defined during the systems analysis phase (Part IV). Often, the results of analysis are documented in the requirements specification (# 35). Additionally, it is useful to define the physical file and database structures (#s 43, 44, and 45), the required input and output data structures (#s 46 through 51), and the algorithms (#s 55 through 60) before starting to create a structure chart.

63.4 Concepts

A structure chart is a hierarchy chart that shows the data and control information flows between the modules. (Figure 63.1 shows a partial structure chart.) Each module is represented as a rectangle. Each data flow (or data couple) is shown as an arrow with an open circle at the origin end. A control couple (a flow of control information such as a flag or a switch setting) is shown as an arrow with a solid circle at the origin end, see the control couple labeled Reorder flag between Process sale and Process transaction in Figure 63.1. (Note: In this program design, Initiate reorder is an independent (not shown) level-2 module called by Process transaction when the Reorder flag is set.) As appropriate, the names of the data elements, data composites, and/or control fields are written alongside the arrows.


Figure 63.1  A partial structure chart.

A structure chart does not show the program’s sequence, selection, or repetitive logical structures; those details are inside the modules, which are viewed as black boxes. However, some designers identify high-level case structures by adding a transaction center to a key control module. For example, the solid diamond (the transaction center symbol) at the bottom of the Process transaction module indicates that, based on the transaction type, either Process sale, Process customer return, or Process shipment arrival is called.

A data couple might list a composite item; for example, Get data passes a complete transaction and the associated master record back to Process transaction. Higher-level modules generally select substructures or specific data elements from a composite and pass them down to their children. At the bottom of the structure, the detailed computational modules accept and return data elements.

The structured program designer’s objective is to define independent, cohesive, loosely coupled modules. Coupling is a function of the amount of data and control information flowing between two modules, and the structure chart graphically shows the data and control flows. An excessive number of data or control flows suggests a poor design or a need for further decomposition.

63.5 Key terms

Cohesion —
A measure of a module’s completeness.
Control couple —
A flow of control information, such as a flag or a switch setting, between two modules.
Control structure —
A hierarchical model of the flow of control through a program. The control structure resembles a military chain of command or an organization chart. At the top is a main control module that calls secondary control structures. At the bottom are the computational routines, each of which implements a single algorithm.
Coupling —
A measure of a module’s independence. Fewer parameters flowing into or out from a module imply looser coupling.
Data couple —
A flow of a data composite and/or data element between two modules.
Functional decomposition —
A program design methodology in which the program is broken down (or decomposed) into modules based on the processes or tasks they perform.
Hierarchy chart —
A diagram that graphically represents a program’s control structure.
Structure chart —
A hierarchy chart with arrows showing the flow of data and control information between the modules.

63.6 Software

McDonnell Douglas Automation Company’s STRADIS/DRAW is a useful tool for creating and evaluating structure charts. Numerous CASE products support structure charts.

63.7 References

1.  Martin, J. and McClure, C., Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, NJ, 1985.
2.  Yourdon, E. and Constantine, Structured Design, Prentice-Hall, Englewood Cliffs, NJ: 1979.
<ch62 toc ch64>