Characteristics of Good Design

• Component independence
– High cohesion
– Low coupling
• Fault prevention and fault tolerance
Question
 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

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
Coincidental Cohesion(cont.)

Module Name: Module-Name:

Random-Operation Managing-Book-Lending

Function: Function:
Issue-book Issue-book
Create-member Return-book
Compute-vendor-credit Query-book
Request-librarian-leave Find-borrower

Example of cohesion
 Logical Cohesion
• Definition: Elements of component are
related logically and not functionally.
All elements of the module perform similar
operations:
e.g. error handling, data input, data output,
etc.
Function A

logic Function A’

Function A’’

Logical
Similar functions
 Temporal Cohesion
• Definition: Elements of a component are
related by timing.
• The module contains tasks that are related
by the fact that all the tasks must be
executed in the same time span.
Time t0

Time t0 + X

Time t0 + 2X
Temporal
Related by time
 Procedural Cohesion
• Definition: Set of functions of the module
are executed one after the other
If the set of functions of the module all part of a procedure
(algorithm) in which certain sequence of steps have to
be carried out in a certain order for achieving an
objective,
e.g. the algorithm for decoding a message.
For example: Login(), place-order(), check-order(), print-
bill() and logout()
 Communicational Cohesion
Definition: If All functions of the module Refer to
the same data structure,
Example:
the set of functions defined on an array or a
stack.

admitStudent,
enterMarks studentRecords
printGradeSheet ARRAY
 Sequential Cohesion
• The output of one component is the input to
another.
Sort

Search

Display
 Functional Cohesion
• Definition: If the Different elements of a
module cooperate to achieve a single
function.
• Every element in the component is
essential to the computation.
Module-Name:
Managing-Book-Lending

Function:
Issue-book
Return-book
Query-book
Find-borrower
 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
Question
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
Question
 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
 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
 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
Example of control coupling:
a flag set in one module and tested in another
module.
 Stamp Coupling
• Definition: Component passes a data structure
to another component that does not have
access to the entire structure.
if they communicate via a composite
data item:
such as a record in PASCAL
or a structure in C.
 Data Coupling
• Definition: Two components are data
coupled:
• if they communicate by an elementary
data item that is passed as a parameter
between the two, e.g.: an integer, a float,
character etc.
Question
 Neat Hierarchy
Control hierarchy represents organization of
modules. control hierarchy is also called
program structure.
 Characteristics of Module
Structure
Depth:
number of levels of control
Width:
overall span of control.
Fan-out:
a measure of the number of modules
directly controlled by given module.
 Characteristics of
Module Structure

Fan-in:
indicates how many modules
directly invoke a given module.
High fan-in represents code reuse
and is in general encouraged.
Module Structure

Fan out=2

Fan out=1

Fan in=2
Fan out=0
 Goodness of Design

A design having modules:

with high fan-out numbers is not a
good design:
a module having high fan-out lacks
cohesion.
 Visibility and Layering
A module A is said to be visible by another
module B,

if A directly or indirectly calls B.

The layering principle requires

modules at a layer can call only the
modules immediately below it.
Bad Design
 Abstraction
The principle of abstraction
requires:
lower-level modules do not invoke
functions of higher level modules.

Also known as layered design.

 High-level Design
High-level design maps functions into
modules {fi} {mj} such that:
1. Each module has high cohesion
2. Coupling among modules is as low
as possible
3. Modules are organized in a neat
hierarchy
 Design Approaches

Two fundamentally different

software design approaches:

Function-oriented design
Object-oriented design
Function-Oriented Design

A system is looked upon as something

that performs a set of functions.
Starting at this high-level view of the
system:
each function is successively refined into
more detailed functions.
Functions are mapped to a module
structure.
Function-Oriented Design

Each subfunction:

split into more detailed subfunctions

and so on.
 Object-Oriented Design
System is viewed as a collection
of objects (i.e. entities).

each object manages its own state

information.
 Object-Oriented Design
Example
Library Automation Software:
each library member is a
separate object with its own
data and functions.

Functions defined for one

object:
cannot directly refer to or change
data of other objects.
 Object-Oriented Design
Objects have their own internal data:
defines their state.
Similar objects constitute a class.
each object is a member of some
class.
Classes may inherit features from
a super class.
Conceptually, objects communicate
by message passing.
Object-Oriented versus Function-
Oriented Design

Unlike function-oriented design,

in OOD the basic abstraction is not
functions such as “sort”, “display”,
“track”, etc.,

but real-world entities such as

“employee”, “picture”, “machine”,
“radar system”, etc.
Object-Oriented versus Function-
Oriented Design

In OOD:
software is not developed by designing
functions such as:
1. update-employee-record,
2. get-employee-address, etc.

but by designing objects such as:

1. employees,
2. departments, etc.