Structure charts

By -

Structure charts

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 (Chapter 62) based on a hierarchy chart (Chapters 62 and64). 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 (Chapter 35). Additionally, it is useful to define the physical file and database structures (Chapters 43, 44, and 45), the required input and output data structures (Chapters 46 through 51), and the algorithms (Chapters 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.

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-01
Figure 63.1  A partial structure chart.

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.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However
Read more