Software Design principles

Coupling and Cohesion

 Programmer’s Approach to
Software Engineering
• Skip requirements engineering and design phases;

• start writing code

• Design is a waste of time

• We need to show something to the customer real quick

• We are judged by the amount of LOC/month

• We expect or know that the schedule is too tight

• The longer you postpone coding, the sooner you’ll be
finished

• Design is a trial-and-error process

• The process is not the same as the outcome of that process

• There is an interaction between requirements engineering,

architecting, and design
 Design principles
• Modularity
• coupling and cohesion
• Information hiding
 Modules
• What is a module?
– lexically contiguous sequence of program
statements, bounded by boundary elements,
with aggregate identifier
• Examples
– procedures & functions in classical PLs
– objects & methods within objects in OO PLs
 Good vs. Bad Modules
• Modules in themselves are not “good”
• Must design them to have good properties
i) CPU using 3 chips (modules) ii) CPU using 3 chips (modules)

Chip 1 Chip 2

Chip 1 Chip 2

AND gates OR gates

Registers
ALU
ALU

Chip 3

Shifter
SHIFTER NOT gates
Chip 3

What is the problem here?

 Good vs. Bad Modules

• Two designs functionally equivalent, but the 2nd is

– hard to understand
– hard to locate faults
– difficult to extend or enhance
– cannot be reused in another product. Implication?
– -> expensive to perform maintenance
• Good modules must be like the 1st design
– maximal relationships within modules (cohesion)
– minimal relationships between modules (coupling)
– this is the main contribution of structured design
Characteristics of Good Design
• Component independence
– High cohesion
– Low coupling
• Exception identification and handling
• Fault prevention and fault tolerance
Coupling: Degree of dependence
among components

No dependencies Loosely coupled-some dependencies

High coupling makes modifying

parts of the system difficult, e.g.,
Highly coupled-many dependencies modifying a component affects all
the components to which the
component is connected.
Range of Coupling

High Coupling
Content

Common

Control

Loose
Stamp

Data

Uncoupled
Low
 Content coupling
• Definition: One component references
contents of another
• Example:
– Component directly modifies another’s data
– Component refers to local data of another
component in terms of numerical
displacement
– Component modifies another’s code, e.g.,
jumps into the middle of a routine
Example of Content Coupling-1

Part of program handles lookup for customer.

When customer not found, component adds
customer by directly modifying the contents of
the data structure containing customer data.
Example of Content Coupling-2
Part of program handles lookup for customer.
When customer not found, component adds
customer by directly modifying the contents of
the data structure containing customer data.

Improvement:
When customer not found, component calls the
AddCustomer() method that is responsible for
maintaining customer data.
 Common Coupling
• Definition: Two components share data
– Global data structures
– Common blocks
• Usually a poor design choice because
– Lack of clear responsibility for the data
– Reduces readability
– Difficult to determine all the components that
affect a data element (reduces maintainability)
– Difficult to reuse components
– Reduces ability to control data accesses
 Example-1
Process control component maintains current data
about state of operation. Gets data from multiple
sources. Supplies data to multiple sinks.

Each source process writes directly to global data

store. Each sink process reads directly from global
data store.
 Example-2
Process control component maintains current data
about state of operation. Gets data from multiple
sources. Supplies data to multiple sinks.

Each source process writes directly to global

data store. Each sink process reads directly from
global data store.
Improvement
Data manager component is responsible for
data in data store. Processes send data to and
request data from data manager.
 Control Coupling
• Definition: Component passes control
parameters to coupled components.
• May be either good or bad, depending on
situation.
– Bad when component must be aware of
internal structure and logic of another module
– Good if parameters allow factoring and reuse
of functionality
 Stamp Coupling
• Definition: Component passes a data structure
to another component that does not have
access to the entire structure.
• Requires second component to know how to
manipulate the data structure (e.g., needs to
know about implementation)
• May be necessary due to efficiency factors: this
is a choice made by insightful designer, not lazy
programmer.
 Example-1

Customer billing system

The print routine of the customer billing
accepts a customer data structure as an
argument, parses it, and prints the name,
address, and billing information.
 Example-2
Customer Billing System
The print routine of the customer billing accepts a
customer data structure as an argument, parses it,
and prints the name, address, and billing
information.

Improvement
The print routine takes the customer name,
address, and billing information as an argument.
 Data Coupling
• Definition: Two components are data coupled
if there are homogeneous data items.
• Every argument is simple argument or data
structure in which all elements are used
• Good, if it can be achieved.
• Easy to write contracts for this and modify
component independently.
 Key Idea in Object-Oriented
Programming
• Object-oriented designs tend to have low
coupling.
 Cohesion
• Definition: The degree to which all elements of a
component are directed towards a single task
and all elements directed towards that task are
contained in a single component.
• Internal glue with which component is
constructed
• All elements of component are directed toward
and essential for performing the same task
• High is good
Range of Cohesion

High Cohesion
Functional
Informational

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
 Coincidental Cohesion
• Definition: Parts of the component are only
related by their location in source code
• Elements needed to achieve some
functionality are scattered throughout the
system.
• Accidental
• Worst form
 Logical Cohesion
• Definition: Elements of component are
related logically and not functionally.
• Several logically related elements are in
the same component and one of the
elements is selected by the client
component.
 Example-1
• A component reads inputs from tape, disk,
and network. All the code for these
functions are in the same component.
• Operations are related, but the functions are
significantly different.
 Example-2
• A component reads inputs from tape, disk,
and network. All the code for these functions
are in the same component. Operations are
related, but the functions are significantly
different.
Improvement
• A device component has a read operation that
is overridden by sub-class components. The
tape sub-class reads from tape. The disk sub-
class reads from disk. The network sub-class
reads from the network.
 Temporal Cohesion
• Definition: Elements of a component are
related by timing.
• Difficult to change because you may have
to look at numerous components when a
change in a data structure is made.
• Increases chances of regression fault
• Component unlikely to be reusable.
 Example-2
• A system initialization routine: this routine
contains all of the code for initializing all of
the parts of the system. Lots of different
activities occur, all at init time.

Improvement
• A system initialization routine sends an
initialization message to each component.
• Each component initializes itself at
component instantiation time.
 Procedural Cohesion
• Definition: Elements of a component are
related only to ensure a particular order of
execution.
• Actions are still weakly connected and
unlikely to be reusable
 Communicational Cohesion
• Definition: Module performs a series of
actions related by a sequence of steps to
be followed by the product and all actions
are performed on the same data
 Example
• Update record in data • database.Update
base and send it to (record).
the printer. • record.Print().
 Sequential Cohesion
• The output of one component is the input to
another.
• Occurs naturally in functional programming
languages
• Good situation
 Informational Cohesion
• Definition: Module performs a number of
actions, each with its own entry point, with
independent code for each action, all
performed on the same data.
• Different from logical cohesion
– Each piece of code has single entry and single exit
– In logical cohesion, actions of module intertwined
• ADT and object-oriented paradigm promote
 Functional Cohesion
• Definition: Every essential element to a
single computation is contained in the
component.
• Every element in the component is
essential to the computation.
• Ideal situation.
 Examples of Cohesion-1

Function A Function A Time t0

Function Function
B C logic Function A’ Time t0 + X
Function Function
D E Function A’’
Time t0 + 2X
Coincidental Logical Temporal
Parts unrelated Similar functions Related by time

Function A

Function B

Function C

Procedural
Related by order of functions
 Examples of Cohesion-2
Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to another

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions