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