4.

1 Modular Design Review

The basic idea underlying modular design is to organize a complex system (such as a large
program, an electronic circuit, or a mechanical device) as a set of distinct components that can be
developed independently and then plugged together. Although this may appear a simple idea,
experience shows that the effectiveness of the technique depends critically on the manner in
which systems are divided into components and the mechanisms used to plug components
together. The following design principles are particularly relevant to parallel programming.
Provide simple interfaces.
Simple interfaces reduce the number of interactions that must be considered when verifying that
a system performs its intended function. Simple interfaces also make it easier to reuse
components in different circumstances. Reuse is a major cost saver. Not only does it reduce time
spent in coding, design, and testing, but it also allows development costs to be amortized over
many projects. Numerous studies have shown that reusing software is by far the most effective
technique for reducing software development costs.
As an example, a modular implementation of a climate modeling system (Figure 2.3) may define
distinct modules concerned with atmosphere modeling, ocean modeling, etc. The interfaces to
each module can comprise a small set of procedures that access boundary data, advance the
simulation, and so on. Hence, there is no need for the user to become familiar with the
implementation of the various modules, which collectively may comprise hundreds of
procedures and tens of thousands of lines of code.
Ensure that modules hide information.
The benefits of modularity do not follow automatically from the act of subdividing a program.
The way in which a program is decomposed can make an enormous difference to how easily the
program can be implemented and modified. Experience shows that each module should
encapsulate information that is not available to the rest of a program. This information hiding
reduces the cost of subsequent design changes. For example, a module may encapsulate

related functions that can benefit from a common implementation or that are used in
many parts of a system,

functionality that is likely to change during later design or deployment,

aspects of a problem that are particularly complex, and/or

code that is expected to be reused in other programs.

Notice that we do not say that a module should contain functions that are logically related
because, for example, they solve the same part of a problem. This sort of decomposition does not
normally facilitate maintenance or promote code reuse.
Use appropriate tools.
While modular designs can in principle be implemented in any programming language,
implementation is easier if the language supports information hiding by permitting the
encapsulation of code and data structures. Fundamental mechanisms in this regard include the
procedure (or subroutine or function) with its locally scoped variables and argument list, used to
encapsulate code; the user-defined datatype, used to encapsulate data; and dynamic memory
allocation, which allows subprograms to acquire storage without the involvement of the calling
program. These features are supported by most modern languages (e.g., C++ , Fortran 90, and
Ada) but are lacking or rudimentary in some older languages (e.g., Fortran 77).
Design checklist.
The following design checklist can be used to evaluate the success of a modular design. As
usual, each question should be answered in the affirmative.
1. Does the design identify clearly defined modules?
2. Does each module have a clearly defined purpose? (Can you summarize it in one
sentence?)
3. Is each module's interface sufficiently abstract that you do not need to think about its
implementation in order to understand it? Does it hide its implementation details from
other modules?
4. Have you subdivided modules as far as usefully possible?
5. Have you verified that different modules do not replicate functionality?
6. Have you isolated those aspects of the design that are most hardware specific, complex,
or otherwise likely to change?

Example

Database search:

We use a simple example to illustrate how information hiding considerations can influence
design. To search a database for records matching a specified search pattern, we must read the
database, search the database, and write any matching records found. One possible

decomposition of this problem defines input, search, and output modules with the following
interfaces.
input(in_file, database)

search(database, search_pattern, matches)

output(out_file, database, matches)

An examination of what must be done to read a database, perform a search, and so on could then
lead us to define the procedures that comprise the input, search, and output modules.
This design provides simple interfaces. However, all three modules depend on the internal
representation used for the database, and hence must be modified if this representation is
changed. In addition, each module probably duplicates database access functions.
An alternative decomposition, driven by information hiding concerns, focuses on the internal
representation of the database as something potentially complex, likely to change, and common
to many components. Hence, this information is hidden in a single database module that provides
operations such as the following.
read_record(file, id, record)

add_record(id, record, database)

get_record(id, record, database)

write_record(file, id, record)

The rest of the program can now be written without knowing anything about how the database is
implemented. To change the internal representation of the database, we need simply to substitute
a different implementation of the database module, which furthermore is ideally suited for reuse
in other applications.