• For a given topic “The class needs to” :
1. Think/ explore/find
2. Pair up with similar topic people and discuss
3. Share the conclusions in class
• This exercise is worth 10 points and will
be accordingly counted in your term
Some Design Goals
– facilitate adding features
– facilitate changing requirements
– make easy to understand
– make easy to implement
– attain high speed: execution and/or compilation
– attain low size: runtime and/or code base
• The degree of interdependence between two
• 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
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).
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
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.
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
– May be remote in time.
• Systems evolve over time.
– information being passed changes.
– May want to switch to a different logical or
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)
• 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
• Keep interfaces as narrow as possible.
• Avoid tramp data:
– Data passed from component to component that
is unwanted and meaningless to most.
• A composite data is passed between modules
• Internal structure contains data not used
• Bundling - grouping of unrelated data into an artificial
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.
• A module controls the logic of another module
through the parameter
• Controlling module needs to know how the other
module works - not flexible
Use of global data as communication between modules Common (Global)
• Two components are common coupled if they refer to the same global
• This is an undesirable form of coupling.
• Defect in one component using common global data can affect others.
• Introduces remoteness (with respect to time).
difficult to understand the use of data
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
• 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)
Determine Coupling Type
– Can programmers work independently? To what degree?
– What may change that may cause changes to multiple
• A pair of components may be coupled in more than one
– Their coupling is determined by their worst type that they
“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
Effects of Object Technology on
• 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.
• “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
• All elements contribute to the execution of one and only one
• 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
• 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
• Elements contribute to activities that use the same input or
• 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
• 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
• Elements are involved in activities that are
related in time
• Commonly found in initialisation and termination
• 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
• Elements contribute to activities of the same
general category (type)
• For example, a report module, display module or
• Usually have control coupling, since one of the
activities will be selected
• 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
“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