Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture # 23
(Modularity – II - Cohesion)

2. Cohesion and Coupling
– Concept of functional independence is a direct
outgrowth from concepts of
• Modularity
• Information hiding and
• Functional Abstraction [ for Object Orientation other concepts
like Encapsulation, data Abstraction, Inheritance,
Polymorphism and others are also included]
– Cohesion is a measure of the „single mindedness‟ of
the lines of code written within a given component in
meeting the purpose of that component.
• It is classic measurement of the quality of relationship
between a component and the lines of codes within the
component.

3. – Coupling is a measure of the number and
strength and number of connections between
components.
• It depicts the dependence of one software element
upon another or the degree thereof.
– Strongly Cohesive and Loosely Coupled, i.e.
independent components / modules is the
goal of good software design
– In Object Orientation, the Class Cohesion
refers to „single-mindedness‟ of a set of
operations (and attributes) in meeting the
purpose of the class
– Class Coupling is a measure of the number
and strength of connections between classes

4. Cohesion
– Cohesion is the concept that tries to address the
relationship between elements within the same
module, i.e. how closely are the elements of a module
related to each other
– Cohesion indicates to the designer „the need for the
elements to be together as a single module‟
– Multiple levels of Cohesion can exist within the same
module i.e. different elements of a module can have
different levels of Cohesion, BUT the lowest or
weakest of these levels will be taken as the cohesion
of the module
• Cohesion and Coupling are closely related,
usually higher Cohesion results in lower
Coupling (and Vice Versa)

5. Cohesion
– Stronger Cohesion is desired
– All elements are if performing same dedicated
function, then they have stronger cohesion.
– Strongly cohesive modules are easy to
understand, maintain and can be developed
and replaced independently
– Cohesion is of 7 types, namely

6. Types of Cohesion
1. Coincidental Cohesion (Weakest – avoided)
2. Logical Cohesion
3. Temporal Cohesion
4. Procedural Cohesion
5. Communicational Cohesion
6. Informational Cohesion
7. Functional Cohesion (Best - recommended)

7. Coincidental Cohesion
• The most un-desirable form of the cohesion, it is
the one with minimum strength
• If a module performs multiple, completely
unrelated tasks/actions, then its elements have
Coincidental Cohesion
– Usually consequent to stringent program size
conditions – Eg ONE A4 size printed page limit
• Smaller sized modules are put together
• Large sized module squeezed or chopped-off to meet the
size limit
• Cut-n-paste from well designed and tested program modules

8. Coincidental Cohesion .
• Why Bad?
• Such modules are problematic to maintain
• Poor understanding/comprehension
“From the view point of trying to understand a product,
modularization with coincidental cohesion is worse then no
modularization at all”
[Shneiderman and Mayers 1975]
• Modules are not Reusable
• Remedy!
– Separate modules for each action

9. Logical Cohesion
• If the series of related tasks/actions are put
together, then Module has Logical Cohesion, Eg
• All input and output statements are put together, say in one input
you want to read a complete record, then this info about which
record is to be read has to be known to the module, thus long
parameter list – inflated interface increases coupling
• Modules performing editing of insertions, deletions and
Modification in a Master file of all records
• All parts of the component perform similar tasks eg
all edits, all reports, error messaging
• Problems
• Long list of parameters (Eg I/O of different devices would need
their Logical Unit Numbers) but few used – Interface Handling
“A module with logical cohesion in an early version of OS/VS2
performed 13 different actions, its interface contained 21 pieces of
data”
[Mayers 1978b]

11. Logical Cohesion
• Problems (Contd)
• Interface is difficult to understand and so is the
module itself
• The code for different actions is intertwined,
leading to maintenance problems
• Addition of a new I/O device to the system would
require a change in number of blocks of the
module
• Reuse of such a module is not possible

12. Temporal Cohesion
• A module having a series of actions
related in time, or all tasks to be executed
at the same time Eg
• Initialization of Matrices (all matrices to be
processed are defined/initialized in one module)
• Opening and closing of all windows/devices,
whereas these are used elsewhere
• Problems
• An action is distributed to multiple modules, for
example, matrices are initialized here but used and
I/O-ed elsewhere
• Maintenance – prone to Regression fault indicating
other modules also need editing/correction

13. Procedural Cohesion
• A module performing series of actions related by
sequence of steps to be followed by the product, is
called having Procedural Cohesion
• All parts of a module are executed according to a pre-
determined sequence, e.g. flow chart, or perform tasks
which are part of same procedure e.g. message
decoding tasks
– Other exmples
• Read Part Number from Db
• Update repair record (of read Part Number) on Maintenance file
– It is better than Temporal Cohesion
– Though actions are procedurally related to one another but these
are weakly interconnected
• Such modules cannot be re-used

14. Communicational Cohesion
• A module has Communicational cohesion if it
performs a series of action related by the
sequence of steps to be followed by the product
and if all these actions are performed on the
same date
– Eg
• Update a record in Db, and Write it in Audit Trail
• Calculate New Trajectory and Send it to the printer
• All processes that communicate with each other
are grouped as a module e.g. read and use data

15. Communicational/Data
Cohesion
• It is better than Procedural Cohesion
because action of the elements (of
module) are closely related
• Communicational Cohesion results usually
due to implementation of Algorithms, as
required different Actions are to be
performed in series on the same data
• Berry 1978 – calls Temporal, Procedural
and Communicational Cohesions as
Flowchart Cohesions

16. Informational Cohesion [Sch04]
• A module has Informational Cohesion if it
performs a number of actions, each with its own
entry point and with independent code for each
action but all performed on the same data
structure
– Though conflicts with Classical Structured Design
principle of single entry and single exit
– Each action has an independent code block, in contrast
to Logical Cohesion, where actions were intertwined
– It is an implementation of an Abstract Data Type, and
brings in all the advantages of use of an ADT
– An Object is instantiation (instance) of an ADT, so an
Object too is a module with Informational Cohesion
– Informational Cohesion is Optimal, the best for OO
Design

18. Functional Cohesion
• A Module that performs exactly one action or
achieves a single goal has a functional cohesion
– Eg
• Compute Square root of a number
• Calculate Sales Commission
– Modules can be re-used as they perform just one
action
– Well-designed, Tested, Quality Modules are
Economical/Technical Asset for a company/org
– Easier Maintenance
– Functional Cohesion leads to fault Isolation – Eg
Erroneous transcripts identify problems in
Exam_Module

19. Functional Cohesion .
• Faults are localized, because every thing relating
to the action is in that module
• Modules are easier to Understand/Comprehend
and so to debug and modify/enhance
• Modules are replaceable by their improved
versions for software and hardware upgradation
– Its functionality can be described with a single
sentence
– In Classical or Structured Design, Functional
Cohesion is the most desirable cohesion
which a module should have.

20. Strength of a Module
• When two or more different levels of cohesion
occur in a module, then assign the lowest of
these levels to the module, while enumerating its
cohesion or strength
– Eg
• In a module there are elements having Coincidental
Cohesion and Procedural Cohesion, then the strength of the
module is that of Coincidental level
• “Weakest link determines the strength of the chain”

21. Application of Coupling & Cohesion
– The Coupling and Cohesion concepts help in deciding
what element is to be put in what module or
component
– How the links, connections, data exchanges or calls
in-between the modules can be minimized i.e. how
coupling can be lowered or weakened
– How inter-relationship or „single mindedness‟ of
elements of modules can be exploited to strengthen
module Cohesion
– Coupling and Cohesion has no explicit mathematical
relationship, but practice reveals that strong Cohesion
leads to weak coupling and vice versa; Further,
Logical Cohesion can lead to Control Coupling etc.

22. What type of Cohesion?
• To judge what type of Cohesion a module
has; [Jal04] suggests
– Write a sentence that describes, fully and
accurately the function or purpose of the module.
The following tests can then be made to judge,
what type of Cohesion it has:
• If it is a compound sentence, and contains a comma,
or has more than one verbs, the module is probably
performing more than one functions and probably has
Sequential or Communicational Cohesion
• If the sentence contains words relating to time, like
„first;, „next‟, „when‟ and „after‟ then module has
Sequential or Temporal Cohesion

23. • If the predicate of the sentence does not contain a
single specific object following the verb (such as
„edit all data‟) the module probably has Logical
Cohesion
• Words like „initialize‟ and „cleanup‟ imply Temporal
Cohesion
• Modules with Functional Cohesion can always be
described with a simple sentence.

25. Modularity
Modules‟ Cost Vurses Size
Larger the module size higher the cost and vice versa, overall cost of
system is dependent on other costs as well, like Module Integration cost

26. References
1. Douglas Bell (2005); Software Engineering for Students; 4th
Edition, Pearson Education, Ch-6, Modularity, pp 67-86
2. Stephen R Schach (2007); Software Engineering, 7th Edition,
Tata McGraw-Hill Publishing Company Limited, New Delhi,
Ch-7 From Modules to Objects, pp 177 - 218
3. Pankaje Jalote (2004); An Integrated Approach to Software
Engineering, 2nd Edition; Narosa Publishing House, New Delhi;
Ch – 5
4. S A Kelkar (2007); Software Engineering – A Concise Study;
Prentice-Hall of India, New Delhi, pp 548-550

27. Functional or Structured Design
– Use Case modeling has helped us in
identifying the Users needs
– Data Flow Diagramming gives the dynamic
view of data, how it will be transformed, and
different processes help in establishing the
basis for different modules
– Entity Relationship Modeling and Attribute
Analysis gives us the static view and enables
us to establish the data structures that could
be used as basis for the software or
Information system being developed

28. – Data Dictionary enables us to define the logic
of different processes or components, it also
helps in formulating the interfaces to these
components
– Coupling and Cohesion enables us to figure
out the placement of different elements and
redefining the boundaries of components or
modules of the „being designed‟ software
system.
– What next …
– Functional or Structured design, to represent
the design of the software.