Chapter 9: Inter-Module Communication

A primary characteristic of structured programming is that it comprises modular programs. Modular programs consist of a series of mainline routines, subroutines, subprograms, and subprocedures—all referred to as modules. The term module, used throughout this chapter, refers to an independent section of program code (i.e., a task). There is not necessarily a one-to-one correspondence between the AS/400 *MODULE object and the term module used in this chapter. However, isolating application modules at the *MODULE level can be beneficial.

With traditional programming, an application and all of its components are placed into a few large multifunction programs. With modular programming, an application is broken into multiple, single-function modules. Whether a module is a subroutine or a subprogram depends on its complexity and the requirements of the application.

BENEFITS OF MODULAR PROGRAMMING

Modular programming provides several benefits that contribute to reduced cost and simplification of the programming task. For example:

• Applications are broken into multiple modules and the programming tasks required for different modules can be spread among several programmers. Therefore, an application program often can be completed more quickly.

• Modules that consist of a few functions often can be developed more reliably. This is primarily due to reduced opportunity for errors that normally occur during module development. Once the module performs correctly, it can be "put away" without impact to the other modules in the application.

• Individual modules can be maintained with little or no impact to the other modules. For example, if the aging routine in an invoicing application needs maintenance, it can be revised without impact to the rest of the application. In addition, if the module is used by more than one application, program maintenance need be performed only once.

• Occasionally, modules can be reused by other applications. For example, a set of program utility functions that simplifies data translation, program-to-program communication, or Internet access would be of use in several applications.

Modular programs consist of two types of modules:

• Logic control modules.

• Function modules.

Logic control modules contain mostly choice constructs and repetition constructs (see chapter 8 for more information on constructs). The logic of a routine is driven by logic control modules. There is little or no work, in the traditional sense, performed in a logic control module. Only relationship testing (choice), looping (repetition), and conditional branching through structured operations are performed.

Function modules consist primarily of sequence constructs. The processes of the application are performed by function modules. A function module also contains choice and repetition constructs that control branching and looping within the function module. Function modules exist at the lowest level of the program design. They perform one and only one task, and then return to the logic control module.

To guarantee the top-down (i.e., vertical) relationship between logic control modules and function modules, a hierarchy chart should be created that illustrates the module relationship. A proper program and, consequently, a proper module exhibits the following characteristics:

• One entry and one exit point.

• No unusable program code.

• No infinite loops.

In addition, to ensure correctness in the application module hierarchy, the following guidelines should be kept in mind when designing an application:

• Logic control modules control access to all lower-level modules.

• Module access is always vertical (never horizontal). A module can call only lower-level modules (not modules at the same or higher level). An exception is that any module may call itself when recursive programming is required.

• Modules are reusable. In other words, modules may be called by multiple modules.

Figure 9.1 shows a hierarchy chart. Each module is depicted by a rectangle. When a module is reused, additional vertical lines on the left and right edge of the rectangle identify the module as reusable (see module B).

Figure 9.1: Hierarchy chart of a modular application.

Each module can be a subroutine, a subprocedure, or a subprogram. When a module is a subprogram, it can be further defined by a program hierarchy chart. The top-most box of the program's hierarchy is the core of the program. It exhibits the functionality of the module. A program hierarchy chart is essentially the same as an application hierarchy chart. A program hierarchy chart, however, supports an additional symbol that identifies a module as being further defined by a flowchart. See Figure 9.2. The additional horizontal line at the top of the rectangle identifies the module as one that is further defined by a flowchart.

Figure 9.2: Flowchart definition symbol.