Software Design

(Lecture 4)

Prof. R. Mall
Dept. of CSE, IIT, Kharagpur

1
 Organization of This
Lecture
● Introduction to software design
● Goodness of a design
● Functional Independence
● Cohesion and Coupling
● Function-oriented design vs. Object-
oriented design
● Summary

2
 Introduction
● Design phase transforms SRS
document:
– To a form easily implementable in
some programming language.

SRS Design
Document Design Documents
Activities

3
 Items Designed During
Design Phase
● Module structure,
● Control relationship among the modules
– call relationship or invocation relationship
● Interface among different modules,
– Data items exchanged among different
modules,
● Data structures of individual modules,
● Algorithms for individual modules.

4
Module Structure

5
 Introduction
● A module consists of:
– Several functions
– Associated data structures.

D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..

6
 Introduction
● Good software designs:
– Seldom arrived through a single
step procedure:
– Butthrough a series of steps and
iterations.

7
 Introduction
● Design activities are usually classified
into two stages:
– Preliminary (or high-level) design.
– Detailed design.
● Meaning and scope of the two stages:
– Vary considerably from one methodology
to another.

8
 High-Level Design
● Identify:
– Modules
– Control relationships among modules
– Interfaces among modules.

d1 d2

d3 d1 d4

9
 High-Level Design
● The outcome of high-level
design:
– Program structure (or software
architecture).

10
 High-Level Design
● Several notations are available to
represent high-level design:
– Usually a tree-like diagram called
structure chart is used.
– Other notations:
● Jackson diagram or Warnier-
Orr diagram can also be used.

11
 Detailed Design
● For each module, design:
– Data structure

– Algorithms

● Outcome of detailed design:

– Module specification.

12
 A Classification of Design
Methodologies
● Procedural (aka Function-
oriented)
● Object-oriented
● More recent:
– Aspect-oriented
– Component-based (Client-
Server)
13
Does a Design Technique Lead
to a Unique Solution?
● No:
– Several subjective decisions need
to be made to trade off among
different parameters.
– Even the same designer can come
up with several alternate design
solutions.

14
 Analysis versus Design
● An analysis technique helps elaborate the
customer requirements through careful
thinking:
– And at the same time consciously avoids making
any decisions regarding implementation.
● The design model is obtained from the
analysis model through transformations over
a series of steps:
– Decisions regarding implementation are
consciously made.
15
A Fundamental Question
● How to distinguish between the
superior of two alternate design
solutions?
– Unless we know what a good
software design is:
● We can not possibly design

one.

16
 Good and Bad Designs
● There is no unique way to design a
system.
● Even using the same design
methodology:
– Differentdesigners can arrive at very
different design solutions.
● We need to distinguish between
good and bad designs.
17
 Which of Two is a
Better Design?
● Should implement all functionalities of
the system correctly.
● Should be easily understandable.
● Should be efficient.
● Should be easily amenable to change,
– i.e. easily maintainable.

18
 Which of Two is a
Better Design?
● Understandability of a design is
a major issue:
– Determines goodness of design:
–A design that is easy to
understand:
● Also easy to maintain and
change.

19
 Which of Two is a
Better Design?
● Unless a design is easy to understand,
– Tremendous effort needed to maintain it
– We already know that about 60% effort
is spent in maintenance.
● If the software is not easy to
understand:
– Maintenance effort would increase many
times.

20
 Understandability
● Use consistent and meaningful
names:
– For various design components.
● Should make use of abstraction
and decomposition principles in
ample measure.

21
How are Abstraction and Decomposition
Principles Used in Design?

● Two principal ways:

– Modular Design
– Layered Design

22
 Modularity
● Modularity is a fundamental
attributes of any good design.
– Decomposition of a problem
cleanly into modules:
– Modules are almost independent
of each other
– Divide and conquer principle.
23
 Modularity
● If modules are independent:
– Modulescan be understood
separately,
● Reduces the complexity greatly.
– To understand why this is so,
● Remember that it is very difficult to
break a bunch of sticks but very
easy to break the sticks individually.
24
Layered Design

25
 Layered Design
● Neat arrangement of
modules in a hierarchy
means:
– Low fan-out
– Control abstraction

26
 Modularity
● In technical terms, modules
should display:
– High cohesion
– Low coupling.
● We shall next discuss:
– cohesion and coupling.

27
 Cohesion and Coupling
● Cohesion is a measure of:
– functional strength of a module.
– A cohesive module performs a
single task or function.
● Coupling between two modules:
–A measure of the degree of the
interdependence or interaction
between the two modules.

28
 Cohesion and Coupling
● A module having high cohesion
and low coupling:
– functionally
independent of
other modules:
● A functionally independent
module has minimal interaction
with other modules.

29
 Advantages of Functional
Independence
● Better understandability and
good design:
● Complexity of design is reduced,
● Different modules easily
understood in isolation:
– Modules are independent

30
 Advantages of Functional
Independence
● Functional independence reduces
error propagation.
– Degree of interaction between modules
is low.
– An error existing in one module does
not directly affect other modules.
● Reuse of modules is possible.

31
 Advantages of Functional
Independence
● A functionally independent
module:
– Canbe easily taken out and
reused in a different program.
● Each module does some well-defined
and precise function
● The interfaces of a module with
other modules is simple and minimal.
32
 Functional Independence
● Unfortunately, there are no ways:
– To quantitatively measure the
degree of cohesion and coupling.
– Classification
of different kinds of
cohesion and coupling:
● Can give us some idea regarding
the degree of cohesiveness of a
module.
33
 Classification of
Cohesiveness
● Classification is often subjective:
– Yetgives us some idea about
cohesiveness of a module.
● By examining the type of
cohesion exhibited by a module:
– We can roughly tell whether it
displays high cohesion or low
cohesion.
34
Classification of
Cohesiveness
functional
sequential
communicational Degree of
procedural cohesion

temporal
logical
coincidental

35
 Coincidental Cohesion
● The module performs a set of
tasks:
– Which relate to each other very
loosely, if at all.
● The module contains a random collection
of functions.
● Functions have been put in the module
out of pure coincidence without any
thought or design.
36
 Example
1. Print next line
2. Add 7 to 5th argument
3. Convert 4th argument to float

37
 Logical Cohesion
● All elements of the module perform similar
operations:
– e.g. error handling, data input, data output, etc.
● 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.

38
 Example
● 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.

39
 Temporal Cohesion
● The module contains tasks that are
related by the fact:
– All the tasks must be executed in the
same time span.
● Elements are related by timing involved
● Elements are grouped by when they are
processed.

40
 Example
● Example:
– The set of functions responsible for
● initialization,
● start-up, shut-down of some
process, etc.
● 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.

41
 Procedural Cohesion
● The set of functions of the
module:
– All part of a procedure (algorithm)
– Certainsequence of steps have to be
carried out in a certain order for
achieving an objective,
● e.g. the algorithm for decoding a
message.
● Elements of a component are related
only to ensure a particular order of 42
 Example
– Write output record
– Read new input record
– Pad input with spaces
– Return new record

43
Communicational Cohesion
● All functions of the module:
– Reference or update the same data structure,
– Functions performed on the same data or to
produce the same data.

44
 Example:

– The set of functions defined on an array or

a stack.
– Update record in data base and send it to
the printer
● Update a record on a database
● Print the record
– Fetch unrelated data at the same time.
● To minimize disk access

45
 Sequential Cohesion
● Elements of a module form
different parts of a sequence,
– Output from one element of the
sequence is input to the next.
– Example:
sort

search

display

46
 Functional Cohesion
● Different elements of a module cooperate:
– To achieve a single function,
– e.g. managing an employee's pay-roll.
– Every element in the component is essential to
the computation.
● When a module displays functional cohesion,
– We can describe the function using a single
sentence.

47
Examples of Cohesion
Function A Function A Time t0
Function Function
B C logic Function A’ Time t0 + X
Function Function Time t0 + 2X
D E Function A’’

Coincidental Logical Temporal

Parts unrelated Similar functions Related by time

Function A

Function B

Function C
Procedural
Related by order of functions
48
Examples of Cohesion (Cont.)
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
49
 Determining Cohesiveness
● Write down a sentence to describe
the function of the module
– If the sentence is compound,
● It has a sequential or communicational
cohesion.
– Ifit has words like “first”, “next”,
“after”, “then”, etc.
● It has sequential or temporal cohesion.
– If it has words like initialize,
● It probably has temporal cohesion. 50
Exercise: Cohesion for Each Module?

 Compute average daily temperatures at various sites

 Initialize sums and open files
 Create new temperature record
 Store temperature record
 Close files and print average temperatures
 Read in site, time, and temperature
 Store record for specific site Functional
Sequential
 Edit site, time, or temperature field Communicational
Procedural
Temporal
Logical
Coincidental

51
5/8/2018 52
 Coupling
● Coupling indicates:
– How closely two modules
interact or how interdependent
they are.
– The degree of coupling
between two modules depends
on their interface complexity.
53
 Coupling
● There are no ways to precisely
determine coupling between two
modules:
– Classification of different types of
coupling will help us to approximately
estimate the degree of coupling between
two modules.
● Five types of coupling can exist
between any two modules.
54
Classes of coupling
data
stamp
control Degree of
coupling
common
content

55
Coupling
 The degree of dependence such as the amount
of interactions among components

No dependencies Loosely coupled Highly coupled

some dependencies many dependencies

56
Type of Coupling

High Coupling
Content Avoid
Common

External
Control
Loose
Stamp

Data Try to achieve

Low Uncoupled

57
 Content
Common
External

Content Coupling Control

Stamp
Data
Uncoupled

 Def: One component modifies another.

 Example:
 Component directly modifies another’s data
 Component modifies another’s code, e.g., jumps
(goto) into the middle of a routine
 Question
 Language features allowing this?

58
Example
Part of a 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?

59
 Content
Common

Common Coupling External

Control
Stamp
Data
Uncoupled

 Def: More than one component share data

such as global data structures
 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

60
Example
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?

61
 Content
Common
External

External Coupling Control

Stamp
Data
Uncoupled

 Def: Two components share something

externally imposed, e.g.,
 External file
 Device interface
 Protocol
 Data format

 Improvement?

62
 Content
Common
External

Control Coupling Control

Stamp
Data
Uncoupled

 Def: Component passes control parameters to coupled

components.
 May be either good or bad, depending on situation.
 Bad if parameters indicate completely different behavior
 Good if parameters allow factoring and reuse of functionality

 Good example: sort that takes a comparison function as

an argument.
 The sort function is clearly defined: return a list in sorted order,
where sorted is determined by a parameter.

63
 Content
Common
External

Stamp Coupling Control

Stamp
Data
Uncoupled

 Def: 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).
 The second has access to more information that it needs.
 May be necessary due to efficiency factors: this is a
choice made by insightful designer, not lazy programmer.

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

Improvement?

65
Improvement --- OO Solution
 Use an interface to limit access from clients

Customer

get name
get address
get billing info
?
get other info
…

void print (Customer c) { … }

66
 Content
Common
External

Data Coupling Control

Stamp
Data
Uncoupled

 Def: Component passes data (not data

structures) to another component.
 Every argument is simple argument or data
structure in which all elements are used
 Good, if it can be achieved.
 Example: Customer billing system
 The print routine takes the customer name, address,
and billing information as arguments.

CS 4311 67
 Content
Content
Common
Common
External
Control

Uncoupled Control
Stamp
Stamp
Data
Data
Uncoupled
Uncoupled

 Completely uncoupled components are not

systems.
 Systems are made of interacting components.

68
Exercise: Define Coupling between Pairs of Modules

Content P List of Parts

Common
External
Status Flag
Control
Stamp
Data Q R
Uncoupled

Order information

Message
Code Sorted List of parts

Message
U Parts order
T

Object containing
List of messages and
List of formatting instructions

69
 Neat Hierarchy
● Control hierarchy represents:
– Organization of modules.
– Control
hierarchy is also called
program structure.
● Most common notation:
–A tree-like diagram called structure
chart.

70
 Layered Design
● Essentially means:
– Low fan-out
– Control abstraction

71
 Characteristics of Module
Hierarchy
● 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.

72
 Characteristics of Module
Structure
● Fan-in:
– Indicates how many modules
directly invoke a given
module.
– Highfan-in represents code
reuse and is in general
encouraged.
73
Module Structure
Fan Fan in=0
out=2
Fan Fan in=1
out=1

Fan in=2

74
 Layered Design
● A design having modules:
– With high fan-out numbers is
not a good design:
–A module having high fan-out
lacks cohesion.

75
 Goodness of Design
● A module that invokes a large
number of other modules:
– Likely
to implement several
different functions:
– Notlikely to perform a single
cohesive function.

76
 Control Relationships
● A module that controls another
module:
– Said to be superordinate to it.
● Conversely, a module controlled by
another module:
– Said to be subordinate to it.

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

78
Bad Design

79
 Abstraction
● A module is unaware (how to invoke
etc.) of the higher level modules.
● Lower-level modules:
– Doinput/output and other low-level
functions.
● Upper-level modules:
– Do more managerial functions.

80
 Abstraction
● The principle of abstraction
requires:
– Lower-levelmodules do not
invoke functions of higher level
modules.
– Also known as layered design.

81
 High-level Design
● High-level design maps functions
into modules {fi} {mj} such
that:
– Each module has high cohesion
– Couplingamong modules is as low
as possible
– Modulesare organized in a neat
hierarchy
82
High-level Design
• f1
• f2
• f3 d1 d2

•
• d3 d1 d4
•
• fn

83
 Design Approaches
● Two fundamentally different
software design approaches:
– Function-oriented design
– Object-oriented design

84
 Design Approaches
● These two design approaches
are radically different.
– However, are complementary
● Rather than competing techniques.
– Each technique is applicable at
● Different stages of the design
process.

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

86
 Example
● The function create-new-library-
member:
– Creates
the record for a new
member,
– Assigns a unique membership number
– Prints a bill towards the membership

87
 Example
● Create-library-member function
consists of the following sub-
functions:
– Assign-membership-number

– Create-member-record

– Print-bill

88
 Function-Oriented Design
● Each subfunction:
– Split
into more detailed
subfunctions and so on.

89
 Function-Oriented Design
● The system state is centralized:
– Accessible
to different functions,
– Member-records:
● Available for reference and updation
to several functions:
– Create-new-member
– Delete-member
– Update-member-record

90
Function-Oriented Design
● Several function-oriented design
approaches have been developed:
– Structured design (Constantine and
Yourdon, 1979)
– Jackson's structured design (Jackson,
1975)
– Warnier-Orr methodology
– Wirth's step-wise refinement
– Hatley and Pirbhai's Methodology
91
Object-Oriented Design
● System is viewed as a collection
of objects (i.e. entities).
● System state is decentralized
among the objects:
– Eachobject manages its own state
information.

92
 Object-Oriented Design
Example
● Library Automation Software:
– Eachlibrary 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.

93
 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.
94
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.

95
Object-Oriented versus Function-
Oriented Design
● In OOD:
– Software is not developed by
designing functions such as:
● update-employee-record,
● get-employee-address, etc.

– But by designing objects such as:

● employees,
● departments, etc.

96
Object-Oriented versus Function-
Oriented Design
● Grady Booch sums up this
fundamental difference
saying:
– “Identifyverbs if you are
after procedural design and
nouns if you are after object-
oriented design.”

97
Object-Oriented versus Function-
Oriented Design

● In OOD:
– Stateinformation is not
shared in a centralized data.
– Butis distributed among the
objects of the system.

98
 Example:
● In an employee pay-roll system, the
following can be global data:
– employee names,
– code numbers,
– basic salaries, etc.
● Whereas, in object oriented design:
– Datais distributed among different
employee objects of the system.

99
Object-Oriented versus Function-
Oriented Design

● Objects communicate by
message passing.
– One object may discover the
state information of another
object by interrogating it.

100
 Object-Oriented versus Function-
Oriented Design
● Of course, somewhere or other the
functions must be implemented:
– The functions are usually associated
with specific real-world entities
(objects)
– Directly
access only part of the
system state information.

101
Object-Oriented versus Function-
Oriented Design
● Function-oriented techniques group
functions together if:
– As a group, they constitute a higher
level function.
● On the other hand, object-oriented
techniques group functions together:
– On the basis of the data they operate
on.

102
Object-Oriented versus Function-
Oriented Design

● To illustrate the differences

between object-oriented and
function-oriented design
approaches,
– let us consider an example ---
– An automated fire-alarm system for
a large building.

103
 Fire-Alarm System
● We need to develop a
computerized fire alarm
system for a large multi-
storied building:
– Thereare 80 floors and 1000
rooms in the building.

104
 Fire-Alarm System
● Different rooms of the
building:
– Fittedwith smoke detectors
and fire alarms.
● The fire alarm system would
monitor:
– Statusof the smoke
detectors.
105
 Fire-Alarm System
● Whenever a fire condition is
reported by any smoke
detector:
– the fire alarm system should:
● Determine the location from which
the fire condition was reported
● Sound the alarms in the neighboring
locations.
106
 Fire-Alarm System
● The fire alarm system
should:
– Flash
an alarm message on the
computer console:
● Fire fighting personnel man the
console round the clock.

107
 Fire-Alarm System

● After a fire condition has

been successfully handled,
– The fire alarm system should
let fire fighting personnel
reset the alarms.

108
 Function-Oriented
Approach:
● /* Global data (system state) accessible by various functions */
BOOL detector_status[1000];
int detector_locs[1000];
BOOL alarm-status[1000]; /* alarm activated when status set */
int alarm_locs[1000]; /* room number where alarm is located */
int neighbor-alarms[1000][10];/*each detector has at most*/
/* 10 neighboring alarm locations */
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();

109
Object-Oriented Approach:
● class detector
● attributes: status, location, neighbors
● operations: create, sense-status, get-
location,
● find-neighbors
● class alarm
● attributes: location, status
● operations: create, ring-alarm,
get_location,
● reset-alarm
● In the object oriented program,
– appropriate number of instances of the class detector
and alarm should be created.

110
Object-Oriented versus Function-
Oriented Design
● In the function-oriented program :
– The system state is centralized
– Several functions accessing these data
are defined.
● In the object oriented program,
– The state information is distributed
among various sensor and alarm
objects.

111
Object-Oriented versus Function-
Oriented Design

● Use OOD to design the

classes:
– Then applies top-down function
oriented techniques
● To design the internal methods
of classes.

112
Object-Oriented versus Function-
Oriented Design

● Though outwardly a system may

appear to have been developed in an
object oriented fashion,
– Butinside each class there is a small
hierarchy of functions designed in a
top-down manner.

113
 Summary
● We started with an overview of:
– Activities undertaken during the
software design phase.
● We identified:
– The information need to be produced at
the end of the design phase:
● So that the design can be easily implemented
using a programming language.

114
 Summary
● We characterized the features
of a good software design by
introducing the concepts of:
– fan-in, fan-out,
– cohesion, coupling,
– abstraction, etc.

115
 Summary
● We classified different types
of cohesion and coupling:
– Enables us to approximately
determine the cohesion and
coupling existing in a design.

116
 Summary
● Two fundamentally different
approaches to software design:
– Function-orientedapproach
– Object-oriented approach

117
 Summary
● We looked at the essential
philosophy behind these two
approaches
– Thesetwo approaches are not
competing but complementary
approaches.

118