WHAT IS A MODULE?

An early attempt to describe modules is by Stevens, Mayers and Constantine, who defined a module
as:
“ A set of one or more contiguous program statements having a name by which other parts of the
system can invoke it, and preferably having its own distinct set of variable names”.
In other words, a module consists of a single block of code that can be invoked in the way that a
procedure, function, or method is invoked.
Yourdon and Constantine gave a broader definition:
“A module is a lexically contiguous sequence of program statements, bounded by boundary elements,
having an aggregate identifier” [2].

SOFTWARE AND MODULARITY:

Software architecture and design patterns embody modularity; that is, software is divided into
separately named and addressable components i.e. modules that are integrated to satisfy problem
requirements.
It has been stated that “modularity is the single attribute of software that allows a program to be
intellectually manageable”. This means that if we subdivide software indefinitely, the effort required
to develop it will become negligibly small. However, other forces come into play, which can change
this statement. Referring to Fig 1, the effort (cost) to develop an individual software module does
decrease as the total number of modules increases. Given the same set of requirements, more modules
means smaller individual size. However, as the number of modules grows, the effort associated with
integrating the modules also grows. These characteristics led to a total cost or effort curve shown in
the figure. There is a number M of modules that would result in minimum development cost.

Total software cost

Cost to integrate
Region of minimum cost
M
Cost or effort

Number of modules
Fig 1: Modularity and software cost
We modularize a design (and the resulting program) so that development can be more easily
planned; software increments can be defined and delivered; changes can be more easily
accommodated; testing and debugging can be conducted more efficiently and long term maintenance
can be conducted without serious side effects. [1]

EFFECTIVE MODULAR DESIGN:

A modular design can be measured that how clearly the system modules are separated from one
another. Another way to measure the partitioning is to see whether the activity is within a single
module or related to one another. Effective modularity can be measured in terms of following
criteria:
 Functional independence

1
  Coupling
 Cohesion [1]

FUNCTIONAL INDEPENDECE:
Functional independence is achieved by developing modules with “single-minded” function and an
“inversion” to excessive interaction with other modules. In other words, we want to design software
so that each module addresses a specific subfunction of requirements and has a simple interface when
viewed from other parts of the program structure.
Software with effective modularity, that is, independent modules, is easier to develop because
function may be compartmentalized and interfaces are simplified. Independent modules are easier to
maintain (and test) because secondary effects caused by design or code modification are limited, error
propagation is reduced, and reusable modules are possible. In short, functional independence is a key
to good design, and design is the key to software quality.
Independence is assessed using two qualitative criteria: cohesion, the degree of interaction within a
module, and coupling, the degree of interaction between two modules. [1]

COHESION:
Cohesion is the measure of the strength of functional relative ness of elements within a module; that
is putting strongly associated things in the same module. Cohesion implies that a component or class
encapsulates only attributes and operations that are closely related to one another and to the class or
component itself.

LEVELS OF COHESION:
In general, the higher the level of cohesion, the easier the component is to implement, test, and
maintain. We can develop a scale of cohesion, ranging from best cohesion to worst cohesion, as
shown below.
1. Functional cohesion
2. Sequential cohesion (Good)
3. Communicational Cohesion
4. Procedural cohesion
5. Temporal cohesion
6. Logical cohesion
7. Coincidental cohesion (Bad)
Fig 2: Levels of cohesion [2]

FUNCTIONAL COHESION:
Exhibited primarily by operations, this level of cohesion occurs when a module performs one and
only one computation and then returns a result. [1]
Advantages:
 A module with functional cohesion often can be reused because the one action that it
performs often needs to be performed in other products.
 Maintenance is easier to perform on a module with functional cohesion.
 Functional cohesion leads to fault isolation.

2
  Because a module with functional cohesion performs only one action, such a module
generally is easier to understand than a module with lower cohesion. This ease in
understanding also simplifies the maintenance.
 When any change is made, the chance of that change affecting other modules is slight,
especially if the coupling between modules is low.
 Functional cohesion also is valuable when a product has to be extended. [2]
Examples:
Examples of such modules are get temperature of furnace; compute orbital of electron; write
to diskette; and calculate sales commission. [2]

SEQUENTIAL / INFORMATIONAL COHESION:

A sequentially cohesive module is one whose elements are involved in activities such that output of
one activity serves as input data to the next [1].
A module has informational cohesion if it performs a number of actions, each with its own entry
point, with independent code for each action, all performed on the same data structure [2]. This does
not violate the tenets of structured programming; each piece of code has exactly one entry point and
one exit point.
Advantages:
 Sequential cohesion has good coupling and good maintainability.
 This module can be easily reused in the same systems, but won’t be useful in general.
Example:

Definition of
sales region table

Initialize sales region table

Entry
. .
Exit
. .
Entry
update sales region table
. .
Exit
. .
Entry
print sales region table
Exit
. .
. .
Fig 3: Module with informational cohesion [2]

Other examples are:

 Reading numbers from keyboard
 Sum of numbers
 Compute average and
 Display average

COMMUNICATIONAL COHESION:
All operations that access the same data are defined within one class. A module has
communicational cohesion if it performs a series of actions related by the sequence of steps to be

3
followed by the product and if all the actions are performed on the same data. These modules are
quite maintainable but there are problems, as the modules cannot be reused. The solution is to break
such modules into separate modules, each performing one action.
Examples:

 Module Determine Customer Details
o Uses Customer Account Number
o Find Customer Name
o Find Customer Loan Balance
o Return Customer Name, Customer Loan Balance
 End Module
 Update record in database and write it to the audit trial.
 Calculate new trajectory and send it to the printer. [1], [2]

PROCEDURAL COHESION:
In procedural cohesion, components or operations are grouped in a manner that allows one to be
invoked immediately after the preceding one was invoked, even when there is no data passed
between them. The disadvantage is that the actions are weakly connected, and the module is unlikely
to be reusable in another product. The solution is to break up a module with procedural cohesion into
separate modules, each performing one action.
Examples:
 In Average module, Summation is followed by Average and then Display.
 A module with procedural cohesion is read part number from database and update repair
record on maintenance file. [1], [2]

TEMPORAL COHESION:
Temporally cohesive module is one whose elements are unrelated to one another except that they are
carried out at a particular time. That is a module has temporal cohesion when it performs a series of
actions related in time. The actions of such a module are related weakly to one another but more
strongly to actions in other modules. In addition, a module with temporal cohesion is unlikely to be
reusable in a different product. [2]
Examples:
An example of a module having temporal cohesion is one named open old master file, new
master file, transaction file, and print file, initialize sales region table, read first transaction
record, and first old master file record. [2]

1. Code for all input and output

2. Code for input only
3. Code for output only
4. Code for disk and tape I/O
5. Code for disk I/O
6. Code for tape I/O
7. Code for disk input
Fig 4: Module that
performs all input 8. Code for disk output
and output. [2]
9. Code for tape input
10. Code for tape output
4

37. Code for keyboard input

LOGICAL COHESION:
A module has logical cohesion when it performs a series of related actions, one of which is selected
by the calling module. That is, a logically cohesive module is one whose elements contribute to
activities of the same general category, in which activity or activities to be executed are selected from
outside the module. Such a module contains a number of activities of the same general kind. The
activities although different are forced to share only one interface to the module. The data is passed
for parameters required for the activity, and un-required parameters are left blank. [1]
Disadvantages:
 The interface is difficult to understand.
 The code for more than one action may be interwined, leading to severe maintenance
problems.
 It is difficult to reuse such a module in other products. [2]
Examples:
 Module new operation which is invoked as follows:
function code = 7;
new operation(function code, dummy 1, dummy 2, dummy 3);
//dummy 1, dummy 2, and dummy 3 are dummy variables,
//not used if function code is equal to 7.
 An object that performs all input and output. [2]

COINCIDENTAL COHESION:
A module has coincidental cohesion if it performs multiple, completely unrelated actions. [2]
Disadvantages:
 Modules with coincidental cohesion degrade the maintainability of the product, both
corrective maintenance and enhancement.
 These modules are not reusable. [2]
Example:
An example of a module with coincidental cohesion is a module named print next line, reverse the
string of characters comprising the second argument, add 7 to the fifth argument, convert the fourth
argument to floating point. [2]

COUPLING:
Coupling is a qualitative measure of the degree to which classes are connected to one another. As
classes (and components) become more interdependent, coupling increases. In general, it is desirable
to reduce the amount of coupling as much as possible, since connections between software
components inhibit ease of development, modification, or reuse. Eliminating unnecessary
relationships and reducing the number of necessary relationships can minimize coupling. [1]
Reasons for reducing coupling:
 When there are fewer connections between two modules, there is less chance for ripple effect.
 We want to be able to change a module with minimum risk of change in other modules – a
change should affect as fewer modules as possible.
 In maintaining a module, we should not worry about the internal details of other modules –
we want the system to be as simple as possible.

5
LEVELS OF COUPLING:
A number of levels of coupling can be distinguished, as shown in fig 5.
1. Data coupling (Good)
2. Stamp coupling
3. Control coupling
4. Common coupling
5. Content coupling (Bad)
Fig 5: Levels of coupling [2]
DATA COUPLING:
Data coupling occurs when operations pass long strings of data arguments. In other words, two
modules are data coupled if all arguments are homogeneous data items. That is, every argument is
either a simple argument or a data structure in which all elements are used by the called module.
Data coupling is a desirable goal. If two modules are data coupled, then maintenance is easier,
because a change to one module is less likely to cause a regression fault in the other. [2]
Examples:
Examples include display time of arrival (flight number), compute product (first number, second
number, result), and determine job with highest priority (job queue). [2]

STAMP COUPLING:
Two modules are stamp coupled if a data structure is passes as an argument, but the called module
operates on only some of the individual components of that data structure. [2]
Examples:
Examples include calculate withholding (employee record) and check altitude (pointer to position
record). [2]

CONTROL COUPLING:
Two modules are controlled coupled if one passes an element of control to the other module.; that is,
one module explicitly controls the logic of the other.
If module q passes information back to module p and p decides what action to take as a consequence
of receiving that information, then q is passing data. But if q not only passes back information but
also informs module p as what action p must take, then control coupling is present.
Disadvantage:
The major difficulty that arises s a consequence of control coupling is that the two modules are
independent; module q, the called module, has to be aware of the internal structure and logic of
module p. As a result, the possibility of reuse is reduced. [2]
Examples:
Control is passed when a function code is passed to a module with logical cohesion. Another
example of control coupling is when a control switch is passed as an argument. [2]

COMMON COUPLING:
Two modules are common coupled if both have access to the same global data. [2]
Disadvantages:
This form of coupling is undesirable for a number of reasons.

6
  It contradicts the spirit of structured programming in that the resulting code is virtually
unreadable.
 Modules can have side effects that affect their readability.
 If a maintenance change is made in one module to the declaration of a global variable, then
every module that can access tat global variable as to be changed. Furthermore, all changes
must be consistent.
 A common-coupled module is difficult to reuse because the identical list of global variables
has to be supplied each time the module is reused.
 As a consequence of common coupling, a module may be exposed to more data than it needs.
This defeats any attempts to control data access and ultimately may lead to computer crime.[2
Examples:
An example is shown in the following figure. Instead of communicating with one another by passing
arguments, modules cca and ccb can access and change the value of global variable. [2]

cca ccb

Global variable

Fig 6: Common coupling [2]

CONTENT COUPLING:
Two modules are content coupled if one directly references the contents of the other. [2]
Disadvantages:
Suppose that module p and module q are content coupled. One of the many dangers is that almost
any change to q, even recompiling q with a new compiler or assembler, requires a change to p.
furthermore, it is impossible to reuse module p in some new product without reusing module q as
well. When two modules are content coupled, they are inextricably interlinked. [2]
Examples:
 Module p modifies a statement of module q.
 Module p refers to local data of module q in terms of some numerical displacement within q.
 Module p branches to a local label of module q.

***************************

References:
1. Software engineering; A practitioner’s approach, sixth edition, by Roger S. Pressman
2. Object-oriented and classical software engineering, fifth edition, by Stephen R. Schach