Action diagrams

Action diagrams

65.1 Purpose

Action diagrams are used in Martin’s information engineering methodology² to plan and document both an overview of program logic and the detailed program logic.

65.2 Strengths, weaknesses, and limitations

Action diagrams are relatively easy to draw and require no special tools. Unlike most software design tools, action diagrams can be used to describe both an overview of program logic and the detailed program logic. In addition to documenting logical relationships and structures, action diagrams provide details about tests and conditions. The action diagrams are relatively easy to convert into program code. The structure of an action diagram helps to reduce such errors as infinite loops.

Often, program logic is more easily described by using such tools as pseudocode (Chapter 59) and structured English (Chapter 60). Relatively few analysts or information systems consultants are familiar with action diagrams. Some advanced features require knowledge of data normalization.

65.3 Inputs and related ideas

Programs are designed in the context of a system. The system is planned during the systems analysis stage of the system development life cycle (Part IV). Pseudocode (Chapter 59) or structured English (Chapter 60) are used within the context of an action diagram to describe detailed program logic. The basic logical structures (sequence, selection, and iteration) are discussed in Chapter 62.

Other tools for documenting or planning routines or processes include logic flowcharts (Chapter 55), Nassi-Shneiderman charts (Chapter 56), decision trees (Chapter 57), decision tables (Chapter 58), pseudocode (Chapter 59), structured English (Chapter 60), and input/process/output (IPO) charts (Chapter 64). Tools for documenting or planning program structure include Warnier-Orr diagrams (Chapter 33), structure charts (Chapter 63), and HIPO (Chapter 64).

65.4 Concepts

Action diagrams are used in Martin’s information engineering methodology to plan and document both an overview of program logic and the detailed program logic.

65.4.1 Conventions

The basic building block of an action diagram is a bracket that represents a program module. Within the bracket, the module’s code is designed using pseudocode, structured English, or fourth-generation language statements. Action diagrams are assembled from sets of brackets. The brackets can be any length, and they can be nested (Figure 65.1).

Figure 65.2 shows the action diagram notation for a simple IF-THEN-ELSE block and for a case structure. Note how horizontal lines are used to partition the bracket into mutually exclusive routines.

Figure 65.3 shows three repetition structures. A double line at the top of the bracket indicates a DO WHILE loop, while a double line at the bottom indicates a DO UNTIL loop. Some designers use an arrow pointing inside the bracket to indicate the next iteration of a loop (Figure 65.3, bottom).

Figure 65.1  The basic building block of an action diagram is a bracket that represents a program module. The brackets can be any length, and they can be nested.

Figure 65.2  Decision (or selection) logic.

Figure 65.3  Repetition (or iteration) logic.

An arrow drawn through a bracket (or set of brackets) represents a termination action, such as EXIT, QUIT, or BREAK (Figure 65.4). A dotted arrow represents an intentional break such as a GOTO statement.

Subprocesses, subprocedures, subroutines and subsystems are shown by round-cornered rectangles (Figure 65.5). A vertical line near the left of the round-cornered rectangle indicates a common subprocedure (e.g., a square root function). Some designers add a wavy line at the right of the rectangle to indicate a not-yet-designed subprocedure. The detailed logic associated with the subprocedure is documented in a separate action diagram.

65.4.2 Some examples

Figure 65.6 shows an overview action diagram for a sales database maintenance program that documents the primary options available on the program’s main menu. Given an overview diagram, the designer decomposes the high-level routine by creating an action diagram for each primary function; for example, Figure 65.7 shows the Maintain customer function. The subprocesses are documented in lower-level action diagrams.

Figure 65.4  An arrow drawn through a bracket (or set of brackets) represents a termination action.

Figure 65.5  Subprocesses are shown by round-cornered rectangles.

65.4.3 Input, output, and database operations

Sometimes, a bracket is expanded into a rectangle to show the data entering and leaving a process (Figure 65.8). By convention, input data are noted at the top right and output data are noted at the bottom right of the rectangle.

Simple database actions (e.g., CREATE, READ, UPDATE, or DELETE a single record or transaction) are represented by a rectangular box inside the bracket (Figure 65.9). The type of action is noted to the left of the box, and the record is identified inside the box.

Compound database actions (CREATE, READ, UPDATE, or DELETE a whole file, and such functions as SEARCH, SORT, SELECT, JOIN, PROJECT, and DUPLICATE) are represented as a double rectangular box (Figure 65.9, bottom). The type of action is noted to the left of the box, the record is identified inside the box, and any conditions are noted to the right of the box.

Figure 65.6  An overview action diagram for a sales database maintenance program.

A concurrency relationship exists between two processes that can be performed concurrently. An arc connecting the two processes’ brackets designates a concurrency relationship.

65.5 Key terms

Action diagram —

A tool used in Martin’s information engineering methodology to plan and document both an overview of program logic and the detailed program logic.

Bracket —

The basic building block of an action diagram.

Figure 65.7  A detailed action diagram for the Maintain customerfunction.

Concurrency relationship —

A relationship between two (or more) processes that can be performed concurrently.

65.6 Software

The action diagrams in this chapter were created using Visio.

Figure 65.8  A bracket can be expanded into a rectangle to show the data entering and leaving a process.

Figure 65.9  Database actions.

65.7 References

1.  Conner, D., Information Systems Specification & Design Road Map, Prentice-Hall, Englewood Cliffs, NJ, 1985.

2.  Martin, J., Information Engineering: Planning and Analysis, Vol. 2, Prentice-Hall, Englewood Cliffs, NJ, 1990.

3.  Martin, J. and McClure, C., Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, NJ, 1985.