This document discusses the Think Pair Share activity and principles of cohesion and coupling in software design. It provides definitions and examples of different types of coupling (data, stamp, control, etc.) and levels of cohesion (functional, sequential, communicational, etc.). The key goals are to minimize coupling between modules to reduce dependencies, and maximize cohesion so elements within a module are strongly related and focused on a single task. High cohesion and low coupling lead to components that are more independent, flexible, and maintainable.

1. Think Pair ShareThink Pair Share
ActivityActivity
Course Instructor
Preeti Mishra

2. Cohesion and CouplingCohesion and Coupling

3. About TPS
• For a given topic “The class needs to” :
1. Think/ explore/find
2. Pair up with similar topic people and discuss
your ideas
3. Share the conclusions in class
• This exercise is worth 10 points and will
be accordingly counted in your term
work!!

4. So lets Begin…So lets Begin…

5. Some Design Goals
• Extension
– facilitate adding features
• Change
– facilitate changing requirements
• Simplicity
– make easy to understand
– make easy to implement
• Efficiency
– attain high speed: execution and/or compilation
– attain low size: runtime and/or code base

6. Coupling
• The degree of interdependence between two
modules”
• We aim to minimise coupling - to make modules as
independent as possible
Low coupling can be achieve by:​
– eliminating unnecessary relationships
– reducing the number of necessary relationships
– easeing the ‘tightness’ of necessary relationships

7. Definition of Coupling
• The fewer the connection, the less chance there is for
the ripple effect.
– Ideally, changing one component should not require a
change in another.
– Should not have to understand details of one component
in order to change another (c.f.principle of locality).

8. Coupling Principles
• Create narrow connections
• Create direct Connections
• Create local connections
• Create obvious connections
• Create flexible connections

9. Narrow (vs. Broad) Connections
• The breadth of connections is number of connections that
link two components.
– A connection that passes 15 pieces of information from one
component to another is broader than a connection in which
only two are passed.
– The greater the number of parameters in a method call the
broader the connection

10. Direct vs. Indirect Connections
• A direct connection is one in which the interface between
two components can be understood without having to refer
to other pieces of information.
– A method definition including pre- and postconditions has a more
direct interface than one that does not.

11. Local vs. Remote Connections
• Local Connection
– All information required to understand the connection is
present in the connection itself.
• Remote Connection
– Coupled through global data.
– May be hundreds of lines removed from a call
point.
– May be remote in time.

12. Flexible Connections
• Systems evolve over time.
– information being passed changes.
– May want to switch to a different logical or
physical devices

13. Types of Coupling
1. Data coupling (Most Required)
2. Stamp coupling
3. Control coupling
4. Hybrid coupling
5. Common coupling
6. Content coupling (Least Required)

14. Normal Coupling
• Two components, A and B, are normally coupled if
– A calls B
– B returns to A
– All information passed between them is by parameters in the
call (or a return).
• Types of Normal Coupling
– Data Coupling
– Stamp Coupling
– Control Coupling

15. Data Coupling
• Keep interfaces as narrow as possible.
• Avoid tramp data:
– Data passed from component to component that
is unwanted and meaningless to most.

16. Stamp coupling
• A composite data is passed between modules
• Internal structure contains data not used
• Bundling - grouping of unrelated data into an artificial
structure

17. Stamp coupling warnings
Do not pass aggregate structures containing many fields when
only one or two are needed by callee.
– You do not want to couple caller to the structure of the aggregate.
– Creates dependencies between otherwise unrelated components.
• Do not bundle unrelated data.

18. Control coupling
• A module controls the logic of another module
through the parameter
• Controlling module needs to know how the other
module works - not flexible

19. Common coupling
Use of global data as communication between modules Common (Global)
Coupling
• Two components are common coupled if they refer to the same global
data area.
• This is an undesirable form of coupling.
• Defect in one component using common global data can affect others.
• Introduces remoteness (with respect to time).
Dangers of:
ripple effect
inflexibility
difficult to understand the use of data

20. Content coupling
Two components exhibit content coupling if
one refers to the internals of the other in any way.
• This form of coupling is unacceptable. It forces you to
understand the semantics implemented in another
component

21. • Hybrid coupling
• A subset of data used as control
• Example: account numbers 00001 to 99999
​
• If 90000 - 90999, send mail to area code of last 3 digit
(000 - 999)

22. Determine Coupling Type
• Ask:
– Can programmers work independently? To what degree?
– What may change that may cause changes to multiple
components?
• A pair of components may be coupled in more than one
way:
– Their coupling is determined by their worst type that they
exhibit.

23. “Good” vs. “bad” coupling
• Modules that are loosely coupled (or uncoupled)
are better than those that are tightly coupled
• Why? Because of the objective of modules to help
with human limitations
• The more tightly coupled are two modules, the
harder it is to think about them separately, and
thus the benefits become more limited

24. Effects of Object Technology on
Coupling
• Object Technology adds additional relationships that often
result in increased coupling.
• Proper application of design principles can reduce the
complexity often found in procedural programs.
– E.g. effective use of access control can eliminate common coupling.

25. Cohesion
• “The measure of the strength of functional
relatedness of elements within a module”
• Elements: instructions, groups of instructions,
data definition, call of another module
​
• We aim for strongly cohesive modules
• Everything in module should be related to one
another - focus on the task
• Strong cohesion will reduce relations between
modules - minimise coupling

26. Seven levels of cohesion
1. • Coincidental (Worst Maintainability)
2. • Logical
3. • Temporal
4. • Procedural
5. • Communicational
6. • Sequential
7. • Functional (Best Maintainability)
Type of cohesion no. Assigned to roll no.
1 12,39
2 15,38
3 17,37
4 21,36,40
5 2434,
6 26,31
7 27,30

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

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

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

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

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

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

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

35. “Good” vs. “bad” cohesion
• Bergland talks about different levels of cohesion
– Best: functional, where the elements collectively provide
a specific behavior or related behaviors
– Worst: coincidental, where the elements are collected
for no reason at all
• Many other levels in between
• Cohesion is not measurable quantitatively

36. Cohesion and Coupling
1
2 3 4
5 6High cohesion Low couplingBridge
component
component
 

37. Cohesion and Coupling
1
2 3 4
5 6High cohesion Low coupling
High coupling
Bridge
component
component
component



Steel
truss