v Cohesion:
Most researchers and engineers agree that a good software
design implies clean decomposition of the problem into modules, and the neat
arrangement of these modules in a hierarchy. The primary characteristics of
neat module decomposition are high cohesion and low coupling. Cohesion is a
measure of functional strength of a module. A module having high cohesion and
low coupling is said to be functionally independent of other modules. By the
term functional
Independence, we mean that a cohesive module performs a
single task or function. A functionally independent module has minimal
interaction with other modules.
v Classification of cohesion:
The different classes of cohesion that a module may possess are
depicted in fig 4.1.
Coincidental
|
Logical
|
Temporal
|
Procedural
|
Communicational
|
Sequential
|
Functional
|
Low
High
Fig. 4.1: Classification
of cohesion
1.
Coincidental cohesion:
A module is said to have coincidental
cohesion, if it performs a set of tasks that relate to each other very loosely,
if at all. In this case, the module contains a random collection of functions.
It is likely that the functions have been put in the module out of pure
coincidence without any thought or design. For example, in a transaction processing
system (TPS), the get-input, print-error, and summarize-members functions are
grouped into one module. The grouping does not have any relevance to the
structure of the problem.
2.
Logical cohesion:
A module is said to be logically cohesive, if all elements
of the module perform similar operations, e.g. error handling, data input, data
output, etc. An example of logical cohesion is the case where a set of print
functions generating different output reports are arranged into a single
module.
3.
Temporal cohesion:
When a module contains functions that are related by the
fact that all the functions must be executed in the same time span, the module
is said to exhibit temporal cohesion. The set of functions responsible for
initialization, start-up, shutdown of some process, etc. exhibit temporal
cohesion.
4.
Procedural cohesion:
A module is said to possess procedural cohesion, if the
set of functions of the module are all part of a procedure (algorithm) in which
certain sequence of steps have to be carried out for achieving an objective,
e.g. the algorithm for decoding a message.
5.
Communicational cohesion:
A module is said to have
communicational cohesion, if all functions of the module refer to or update the
same data structure, e.g. the set of functions defined on an array or a stack.
6.
Sequential cohesion:
A module is said to possess
sequential cohesion, if the elements of a module form the parts of sequence,
where the output from one element of the sequence is input to the next. For
example, in a TPS, the get-input, validate-input, sort-input functions are
grouped into one module.
7.
Functional cohesion:
Functional cohesion is said to exist,
if different elements of a module cooperate to achieve a single function. For example,
a module containing all the functions required to manage employees’ pay-roll
exhibits functional cohesion. Suppose a module exhibits functional cohesion and
we are asked to describe what the module does, then we would be able to
describe it using a single sentence.
v Coupling:
Coupling between two modules is a
measure of the degree of interdependence or interaction between the two
modules. A module having high cohesion and low coupling is said to be
functionally independent of other modules. If two modules interchange large
amounts of data, then they are highly interdependent. The degree of coupling
between two modules depends on their interface complexity. The interface
complexity is basically determined by the number of types of parameters that
are interchanged while invoking the functions of the module.
v Classification of Coupling:
Even if there are no techniques to
precisely and quantitatively estimate the coupling between two modules,
classification of the different types of coupling will help to quantitatively
estimate the degree of coupling between two modules. Five types of coupling can
occur between any two modules. This is shown in fig. 4.2.
Data
|
Stamp
|
Control
|
Common
|
Content
|
Low High
Fig. 4.2: Classification
of coupling
1. Data
coupling:
Two modules are data coupled, if they
communicate through a parameter. An example is an elementary data item passed
as a parameter between two modules, e.g. an integer, a float, a character, etc.
This data item should be problem related and not used for the control purpose.
2. Stamp
coupling:
Two modules are stamp coupled, if
they communicate using a composite data item such as a record in PASCAL or a
structure in C.
3. Control
coupling:
Control coupling exists between two
modules, if data from one module is used to direct the order of instructions
execution in another. An example of control coupling is a flag set in one
module and tested in another module.
4. Common
coupling: Two modules are common coupled, if they share data through
some global data items.
5. Content
coupling: Content coupling exists between two modules, if they share
code, e.g. a branch from one module into another module.
