SE-381Software Engineering

BEIT-V

Lecture # 23(Modularity – II - Cohesion)

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.

– 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

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)

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

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)

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

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

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]

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

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

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

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

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

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

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

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.

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”

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.

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

• 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.

ModularityModules’ 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

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

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

– 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.