Structure Charts

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.

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.

Inputs and related ideas

A structure chart is a functional decomposition tool based on a hierarchy chart . 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.

ADDITIONAL NOTES