Ontech25 (c) 2010

Modularity
Modules and Modularity 5th form
The programs we have written so far are simple with not too many lines of code. However,
programs are seldom written as one long series of steps. As programs increase in complexity, it
becomes more and more difficult to consider the solution as a whole. Instead, the problem is
divided into smaller parts or units, referred to as modules. Modules are as a result of a structured
design style (modularity) that breaks down (decomposes functionally or otherwise) a program
into distinct portions (modules), each of which, ideally, accomplishes a single task or procedure.
To break up a problem into modules, the following steps should be taken:
- identify the major tasks to be performed then divide the problem into sections that represent
those tasks
- look at each subtask and identify within them further subtasks and so on
This process of identifying first the major tasks, then further subtasks within them is known as
top-down design or functional decomposition. Each subtask will eventually become a module
within a program. Top-down design methodology allows the programmer to concentrate on the
overall design of the algorithm without getting too involved with the details of the lower-level
modules (abstraction).
A module must be large enough to perform its task and must include only the operations that
contribute to the performance of that task. The name of the module usually indicates the task of
function that the module is to perform, for example, calculate_sales_tax or validate_input_data.
Benefits:
-

Useful in the design of very large programs

Source of errors is easier to identify
Improved design efficiency through re-use of repeated logic.
Programming efforts can be divided among a team, by modules/functions, resulting in
faster and more efficient program development.

Hierarchy Charts
A hierarchy or structure chart is a diagrammatic representation of the hierarchical relationship of
modules to each other (similar to an organizational chart within a company). It is also referred to
as a structure chart. At the top of the hierarchy chart is the main module. On the next level are the
modules immediately subordinate to the main module. On the next level are the modules

Ontech25 (c) 2010

subordinate to the module on the first level, and so on. The main module will pass control to
(call) the subordinate module when it is ready for that module to perform its task. The module
that controls a subordinate module is referred to as the calling module and the subordinate
module, the called module. On completion of its task, the called module returns control to the
calling module.

Generic Hierarchy Chart

Main
Module

Module1

Module3

Module2

Module

Module

2a

2b

The Main Driver Module

Every modular program has a main processing module that provides the master control that ties
all the modules together (calls them) and coordinates their activity. This main processing module
is also referred to as the main driver module or simply, main. It shows the main processing
functions and the order in which they are performed. It also shows the flow of data and the major
control structures. Generally, you should be able to look at the main driver module and see
exactly what is being done in the program. When a program is divided into several parts or
modules, the main module can be designed first, leaving the details until later. Only the main
module contains a START and a STOP. It is referred to as a calling module because it calls or
references other modules. These other modules are referred to as called modules, and will return
control back to the calling module. The main driver module is not necessarily the only module
that calls other modules. Any module that calls or triggers the activity of a module below itself (a
subordinate module) acts as a driver module. Therefore, it is possible for a module to be both a
calling module and a called module. There is however, only one main driver module in any

Ontech25 (c) 2010

program. It is important to note that a called module may be invoked any number of times, or in
some instances, not at all.
Communication between modules in a structure chart is allowed only through a calling module.
Modules can send data between themselves. This process is known as parameter passing. The
parameters are contained in a list that is a definition of the data passed to the function by the
caller module. However, parameter passing will be looked on later on.
Let us look at an example of Modularity using Psuedocode Development:

Ontech25 (c) 2010

Write a program that will print the numbers between 1 and 10, and state whether each is
even or odd e.g. 1 is odd, 2 is even
If we were writing this without using modularity, our pseudocode would look like this:
START
DECLARE count as INTEGER
FOR count = 1 to 10 DO
IF count % 2 = 0 THEN
WRITE count is even
ELSE
WRITE count is odd
ENDIF
ENDFOR

(Remember the Modulus symbol)

STOP

We have only one program main, in which all instructions are defined. However, if we used
modularity, where we have one module called by main to do the program then we would have:
START
CALL oddAndEven
STOP

The module oddAndEven has a particular task to be completed. The task in this case is to
display all the odd and even numbers between 1 and 10. This task has to be clearly defined. The
definition of this module is NEVER done inside the main module. It is done outside, usually at
the end of the main program.
PROCEDURE oddAndEven
ENTER
DECLARE count as INTEGER
FOR count = 1 to 10 DO
IF count %2 = 0 THEN
WRITE count is even
ELSE
WRITE count is odd
ENDIF
ENDFOR
RETURN

The main module in the above example does nothing more than call the subordinate module
oddAndEven to do the work. The oddAndEven module is called a procedure. A procedure is a

Ontech25 (c) 2010

module that is called to do a particular task and given no values from the called module. Upon
completion it returns nothing to the calling module except full control.
Scope of a Variable
The scope of a variable is the portion of a program in which that variable has been defined and to
which it can be referred. Variables can be global, where the scope of the variable is the whole
program, or local, where the scope of the variable is simply the module in which it is defined.