Software Design & Architecture

Lecture - 9

Lecturer: Junaid Arshad

Cohesion
• Cohesion represents the functional strength of modules

• Cohesion is the concept of intra module.

• Cohesion represents the relationship within module

• Increasing in cohesion is good for software.

• Highly cohesive gives the best software.

Types of Cohesion
Functional cohesion
• The strongest and best kind of cohesion, occurring when a routine performs
one and only one operation.

• Examples of highly cohesive routines include sine(), calculating the square

root of a number.

• This evaluation of their cohesion assumes that the routines do what their
names say they do—if they do anything else, they are less cohesive and
poorly named

• Several other kinds of cohesion are normally considered to be less than ideal
Sequential cohesion
• It exists when a routine contains operations that must be performed
in a specific order (The output from one part is the input to another
part)

• An example of sequential cohesion is a routine that calculates an

employee’s age and time to retirement, given a birth date. If the
routine calculates the age and then uses that result to calculate the
employee’s time to retirement, it has sequential cohesion.
Communicational cohesion
• It occurs when operations in a routine make use of the same data and
aren’t related in any other way.

• If a routine prints a summary report and then reinitializes the

summary data passed into it, the routine has communicational
cohesion; the two operations are related only by the fact that they
use the same data.

• To give this routine better cohesion, the summary data should be

reinitialized close to where it’s created, which shouldn’t be in the
report-printing routine.
Procedural cohesion
• It occurs when operations in a routine are done in a specified order.

• An example is a routine that gets an employee name, then an

address, and then a phone number. The order of these operations is
important only because it matches the order in which the user is
asked for the data on the input screen. Another routine gets the rest
of the employee data.

• The routine has procedural cohesion because it puts a set of

operations in a specified order and the operations don’t need to be
combined for any other reason.
Temporal cohesion
• It occurs when operations are combined into a routine because they
are all done at the same time. Typical examples would be Startup()

• The Startup() routine, for example, might read a configuration file,

initialize a file, set up a memory manager, and show an initial screen
etc.

• To make it most effective, have the temporally cohesive routine call

other routines to perform specific activities rather than performing
the operations directly itself.
Logical cohesion
• It occurs when several operations are stuffed into the same routine
and one of the operations is selected by a control flag that’s passed
in. They’re all in a big if statement or case statement together.

• One example would be an InputAll() routine that input customer

names, employee time-card information, or inventory data depending
on a flag passed to the routine.

• If the routine’s only function is to dispatch commands and it doesn’t

do any of the processing itself, that’s usually a good design
Coincidental cohesion
• It occurs when the operations in a routine have no noticeable
relationship to each other. The only relationship between the parts is
that they have been grouped together. Other good names are “no
cohesion” or “chaotic cohesion.”

• It’s hard to convert coincidental cohesion to any better kind of

cohesion—you usually need to do a deeper redesign and
reimplementation.
Focus your attention on functional cohesion
for maximum benefit.
Coupling
• Coupling between two modules is a measure of the degree of
interdependence or interaction between the two modules.

• If two modules interchange large amounts of data, then they are

highly interdependent.

• Coupling is the concept of inter module.

Coupling Cont’d

• In coupling, modules are connected to the other modules.

• Increasing in coupling is avoided for software.

• Where as loosely coupling gives the best software.

Types of Coupling
Data coupling
• Two modules are data coupled, if they communicate through a
parameter.

• Data coupling is a type of coupling that measures the degree to which

one module depends on the data of another module.

• In other words, data coupling occurs when modules communicate by

passing data, but they do not rely on each other's internal details.

• It is considered a more desirable form of coupling compared to

content coupling because it promotes modularity and encapsulation.
Example:
• Module A has a function calculate_square that performs a calculation.

• Module B has a function process_data that takes some data and calls
the function from Module A.

• The coupling here is based on the data (the value) that is being
passed between the modules. However, this is an example of data
coupling because Module B doesn't need to know how
calculate_square is implemented in Module A, as long as it receives
the required data.
• So, Data coupling is a form of coupling that encourages
modular and maintainable software design by promoting
independence between modules while allowing them to
communicate through well-defined data interfaces.
Stamp coupling
• Two modules are stamp coupled, if they communicate using a data
item such as a record in PASCAL or a structure in C.

• Stamp coupling is a type of coupling in software engineering that

occurs when components share a composite data structure, and the
component uses only a part, or "stamp," of that data structure.

• In other words, stamp coupling involves modules that communicate

by passing a data structure, but the receiving module is interested in
only a subset or specific field of the data.
Example:
• Module A has a function process_data that takes a dictionary
containing student information.
• Module B has a data structure (student_data) that includes more
information than Module A requires.
• Module B calls the function in Module A, passing the entire data
structure, but Module A only uses the student ID from that data
structure.

Stamp coupling is evident here because Module A and Module B share

a data structure (student_data), but Module A is concerned only with a
specific "stamp" or subset of that data (the student ID).
• While stamp coupling is weaker than content coupling
because the modules are not directly dependent on the
entire content of the shared data structure, it still introduces
a level of interdependence.
Control coupling
• Control coupling exists between two modules, if data from one
module is used to direct the order of instructions execution in
another.

• Control coupling is a form of coupling that occurs when one module

controls the behavior of another by specifying the order in which its
operations should be executed.

• In control coupling, modules communicate by sharing control

information, such as flags or parameters that determine the flow of
execution within the receiving module.
Example:
• Module A has a function perform_task that takes a parameter
(task_type) to determine which task to execute.

• Module B sets the value of task_type and calls the function in Module
A.

• The coupling is based on control because Module B is controlling the

behavior of Module A by specifying the task type. If additional tasks
are added or if the conditions for task execution change, Module B
may need to be updated accordingly.
• Reducing control coupling is often achieved by designing
modules to be more independent and by using techniques
such as encapsulation and information hiding.
Common coupling
• Two modules are common coupled, if they share data through some
global data items.

• Common coupling, also known as global coupling, is a form of

coupling that occurs when two or more modules share a common
piece of data, typically a global variable or a shared resource.

• In common coupling, modules are interconnected through this shared

data, and changes to the shared data can affect multiple modules.
• This type of coupling is generally considered undesirable because it
reduces the modularity of the system and makes it more difficult to
understand, maintain, and evolve.
• Example:
• Module A has a global variable (shared_variable) and a function
(increment_variable) that modifies the value of the shared variable.

• Module B has a function (print_variable) that reads the value of the

shared variable.

• Modules A and B are common coupled because they share the global
variable shared_variable. If changes are made to the way the variable
is used or if additional modules are introduced that interact with this
global variable, it can lead to unintended side effects and make the
system more challenging to maintain.
• To reduce common coupling, software design principles such
as encapsulation and information hiding are often employed.
Instead of sharing global variables, modules should
communicate through well-defined interfaces and use
parameters or return values to exchange data. This promotes
a more modular, maintainable, and scalable software
architecture.
Content coupling
• Content coupling exists between two modules, if they share code, e.g. a
branch from one module into another module.

• Content coupling is a form of coupling in software engineering that occurs

when one module has direct access to the internal implementation details,
such as data structures or algorithms, of another module.

• In content coupling, one module depends on the internal content, or

implementation, of another module.

• Content coupling is generally considered a high level of coupling and is often

undesirable in software design.
• This is because it makes modules tightly interconnected, and changes
to the internal details of one module may require corresponding
changes to the dependent module.

• High content coupling reduces modularity, makes the system less

maintainable, and increases the risk of unintended side effects when
modifications are made.
Example:
• Module A has a function calculate_square that performs a calculation.

• Module B directly calls the function from Module A, relying on its

internal implementation.

• Content coupling is evident here because Module B depends on the

internal content (the specific calculation) of Module A. If Module A
changes its implementation or if a different module is used with a
different calculation, Module B may need to be updated accordingly.
• To improve modularity and reduce content coupling, software design
principles such as encapsulation, abstraction, and information hiding
are applied.

• Instead of directly accessing the internal details of another module,

modules should communicate through well-defined interfaces, using
parameters and return values to exchange information.

• This promotes a more modular, maintainable, and adaptable software

architecture.