Functional cohesion
All elements contribute to the execution of one and only one problem-related task
Focussed - strong, single-minded purpose
No elements doing unrelated activities
Examples of functional cohesive modules:
Compute cosine of angle
Read transaction record
Assign seat to airline passenger
Sequential cohesion
Elements are involved in activities such that output data from one activity
becomes input data to the next
Usually has good coupling and is easily maintained
Not so readily reusable because activities that will not in general be useful
together
Example of Sequential Cohesion
module format and cross-validate record
use raw record
format raw record
cross-validate fields in raw record
return formatted cross-validated record
Communicational Cohesion
Elements contribute to activities that use the same input or output data
Not flexible, for example, if we need to focus on some activities and not the others
Possible links that cause activities to affect each other
Better to split to functional cohesive ones
Example of Communicational Cohesion
module determine customer details
use customer account no
find customer name
find customer loan balance
return customer name, loan balance
Procedural cohesion
Elements are related only by sequence, otherwise the activities are unrelated
Similar to sequential cohesion, except for the fact that elements are unrelated
Commonly found at the top of hierarchy, such as the main program module
Example of Procedural Cohesion
module write read and edit something
use out record
write out record
read in record
pad numeric fields with zeros
return in record
Temporal cohesion
Elements are involved in activities that are related in time
Commonly found in initialisation and termination modules
Elements are basically unrelated, so the module will be difficult to reuse
Good practice is to initialise as late as possible and terminate as early as possible
Example of Temporal Cohesion
module initialize
set counter to 0
open student file
clear error message variable
initialize array
Logical cohesion
Elements contribute to activities of the same general category (type)
For example, a report module, display module or I/O module
Usually have control coupling, since one of the activities will be selected
Example of Logical Cohesion
module display record
use record-type, record
if record-type is student then
display student record
else if record-type is staff then
display staff record
Coincidental cohesion
Elements contribute to activities with no meaningful relationship to one another
Similar to logical cohesion, except the activities may not even be the same type
Mixture of activities - like ‘rojak’!
Difficult to understand and maintain, with strong possibilities of causing ‘side
effects’ every time the module is modified
Example of Coincidental Cohesion
module miscellaneous functions
use customer record
display customer record
calculate total sales
read transaction record
return transaction record
In object-oriented programming, if the methods that serve a class tend to be similar in many
aspects, then the class is said to have high cohesion. [4] In a highly cohesive system, code
readability and reusability is increased, while complexity is kept manageable.
Cohesion
Cohesion is increased if:
The functionalities embedded in a class, accessed through its methods, have much
in common.
Methods carry out a small number of related activities, by avoiding coarsely
grained or unrelated sets of data.
Related methods are in the same source file or otherwise grouped together; for
example, in separate files but in the same sub-directory/folder.
Advantages of high cohesion (or "strong cohesion") are:
Reduced module complexity (they are simpler, having fewer operations).
Increased system maintainability, because logical changes in the domain affect fewer
modules, and because changes in one module require fewer changes in other
modules.
Increased module reusability, because application developers will find
the component they need more easily among the cohesive set of operations provided
by the module.
While in principle a module can have perfect cohesion by only consisting of a single, atomic
element – having a single function, for example – in practice complex tasks are not expressible
by a single, simple element. Thus a single-element module has an element that either is too
complicated, in order to accomplish a task, or is too narrow, and thus tightly coupled to other
modules. Thus cohesion is balanced with both unit complexity and coupling.
Types of cohesion[edit]
Cohesion is a qualitative measure, meaning that the source code to be measured is examined
using a rubric to determine a classification. Cohesion types, from the worst to the best, are as
follows:
Coincidental cohesion (worst)
Coincidental cohesion is when parts of a module are grouped arbitrarily; the only
relationship between the parts is that they have been grouped together (e.g., a “Utilities”
class). Example:
/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A{
/*
Implementation of r(x) = 5x + 3
There is no particular reason to group functions in this way,
so the module is said to have Coincidental Cohesion.
*/
r(x) = a(x) + b(x)
a(x) = 2x + 1
b(x) = 3x + 2
}
Logical cohesion
Logical cohesion is when parts of a module are grouped because they are logically
categorized to do the same thing even though they are different by nature (e.g., grouping
all mouse and keyboard input handling routines or bundling all models, views, and
controllers in separate folders in an MVC pattern).
Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are processed -
the parts are processed at a particular time in program execution (e.g., a function which
is called after catching an exception which closes open files, creates an error log, and
notifies the user).
Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they always follow
a certain sequence of execution (e.g., a function which checks file permissions and then
opens the file).
Communicational/informational cohesion
Communicational cohesion is when parts of a module are grouped because they operate
on the same data (e.g., a module which operates on the same record of information).
Sequential cohesion
Sequential cohesion is when parts of a module are grouped because the output from one
part is the input to another part like an assembly line (e.g., a function which reads data
from a file and processes the data).
Functional cohesion (best)
Functional cohesion is when parts of a module are grouped because they all contribute to
a single well-defined task of the module (e.g., Lexical analysis of an XML string).
Example:
/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A {
/*
Implementation of arithmetic operations
This module is said to have functional cohesion because
there is an intention to group simple arithmetic operations
on it.
*/
a(x, y) = x + y
b(x, y) = x * y
}
Module B {
/*
Module B: Implements r(x) = 5x + 3
This module can be said to have atomic cohesion. The whole
system (with Modules A and B as parts) can also be said to have
functional
cohesion, because its parts both have specific separate purposes.
*/
r(x) = [Module A].a([Module A].b(5, x), 3)
}
Perfect cohesion (atomic)
Example.
/*
Groups: The function definitions
Parts: The terms on each function
*/
Module A {
/*
Implementation of r(x) = 2x + 1 + 3x + 2
It's said to have perfect cohesion because it cannot be reduced any
more than that.
*/
r(x) = 5x + 3
}
Although cohesion is a ranking type of scale, the ranks do not
indicate a steady progression of improved cohesion. Studies by
various people including Larry Constantine, Edward Yourdon,
and Steve McConnell[5] indicate that the first two types of
cohesion are inferior; communicational and sequential cohesion
are very good; and functional cohesion is superior.
While functional cohesion is considered the most desirable type
of cohesion for a software module, it may not be achievable.
There are cases where communicational cohesion is the
highest level of cohesion that can be attained under the
circumstances
