SOFTWARE DESIGN

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
INTRODUCTION
Design phase transforms SRS document:
To a form easily implementable in some
programming language.

SRS Design
Document Design Documents
Activities
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.
MODULE STRUCTURE
INTRODUCTION
A module consists of:
Several functions
Associated data structures.
D1 ..
D2 .. Data
D3 ..
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
INTRODUCTION
Good software designs:
Seldom arrived through a single step
procedure:
But through a series of steps and
iterations.
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.
HIGH-LEVEL DESIGN
Identify:
Modules
Control relationships among modules
Interfaces among modules.

d1 d2

d3 d1 d4
HIGH-LEVEL DESIGN
The outcome of high-level design:
Program structure (or software
architecture).
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.
DETAILED DESIGN
For each module, design:
Data structure
Algorithms
Outcome of detailed design:
Module specification.
A CLASSIFICATION OF
DESIGN METHODOLOGIES

Procedural (aka Function-oriented)

Object-oriented
More recent:
Aspect-oriented
Component-based (Client-Server)
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.
 ANALYSIS VERSUS
AnDESIGN
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.
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.
GOOD AND BAD DESIGNS
There is no unique way to design a system.
Even using the same design methodology:
Different designers can arrive at very different
design solutions.
We need to distinguish between good and
bad designs.
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.
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.
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.
UNDERSTANDABILITY
Use consistent and meaningful names:
For various design components.
Should make use of abstraction and
decomposition principles in ample
measure.
HOW ARE ABSTRACTION AND
DECOMPOSITION PRINCIPLES USED IN
DESIGN?

Two principal ways:

Modular Design
Layered Design
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.
MODULARITY
If modules are independent:
Modules can 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.
LAYERED DESIGN
LAYERED DESIGN
Neat arrangement of modules in
a hierarchy means:
Low fan-out
Control abstraction
MODULARITY
In technical terms, modules should
display:
High cohesion
Low coupling.
We shall next discuss:
cohesion and coupling.
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.
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.
ADVANTAGES OF FUNCTIONAL
INDEPENDENCE
Better understandability and good
design:
Complexity of design is reduced,
Different modules easily understood in
isolation:
Modules are independent
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.
ADVANTAGES OF FUNCTIONAL
INDEPENDENCE
A functionally independent module:
Can be 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.
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.
CLASSIFICATION OF
COHESIVENESS
Classification is often subjective:
Yet gives 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.
CLASSIFICATION OF
COHESIVENESS
functional
sequential
communicational Degree of
procedural cohesion

temporal
logical
coincidental
COUPLING
CLASSES OF COUPLING
data
stamp
control Degree of
coupling
common
content
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.
LAYERED DESIGN

Essentially means:
Low fan-out
Control abstraction
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.
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 Fan in=0
out=2
Fan Fan in=1
out=1

Fan in=2
LAYERED DESIGN
A design having modules:
With high fan-out numbers is not a
good design:
A module having high fan-out lacks
cohesion.
GOODNESS OF DESIGN
A module that invokes a large
number of other modules:
Likely to implement several different
functions:
Not likely to perform a single
cohesive function.
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.
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
A module is unaware (how to invoke etc.)
of the higher level modules.
Lower-level modules:
Do input/output and other low-level
functions.
Upper-level modules:
Do more managerial functions.
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:
Each module has high cohesion
Coupling among modules is as low as
possible
Modules are organized in a neat hierarchy
HIGH-LEVEL DESIGN

• f1
• f2 d1 d2
• f3
•
• d3 d1 d4
•
• fn
DESIGN APPROACHES
Two fundamentally different software
design approaches:
Function-oriented design
Object-oriented design
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.
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.
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
EXAMPLE
Create-library-member function
consists of the following sub-functions:
Assign-membership-number
Create-member-record
Print-bill
FUNCTION-ORIENTED
DESIGN
Each subfunction:
Split into more detailed subfunctions
and so on.
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
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
OBJECT-ORIENTED
DESIGN
System is viewed as a collection of
objects (i.e. entities).
System state is decentralized among the
objects:
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:
update-employee-record,
get-employee-address, etc.
But by designing objects such as:
employees,
departments, etc.
OBJECT-ORIENTED VERSUS
FUNCTION-ORIENTED DESIGN
Grady Booch sums up this
fundamental difference saying:
“Identify verbs if you are after
procedural design and nouns if you
are after object-oriented design.”
OBJECT-ORIENTED VERSUS
FUNCTION-ORIENTED DESIGN

In OOD:
State information is not shared in a
centralized data.
But is distributed among the
objects of the system.
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:
Data is distributed among different employee
objects of the system.
OBJECT-ORIENTED VERSUS
FUNCTION-ORIENTED DESIGN

Objects communicate by message

passing.
One object may discover the state
information of another object by
interrogating it.
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.
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.
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.
FIRE-ALARM SYSTEM

We need to develop a
computerized fire alarm system
for a large multi-storied building:
There are 80 floors and 1000
rooms in the building.
FIRE-ALARM SYSTEM
Different rooms of the building:
Fitted with smoke detectors and fire
alarms.
The fire alarm system would
monitor:
Status of the smoke detectors.
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.
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.
FIRE-ALARM SYSTEM

After a fire condition has been

successfully handled,
The fire alarm system should let
fire fighting personnel reset the
alarms.
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();
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.
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.
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.
OBJECT-ORIENTED VERSUS
FUNCTION-ORIENTED DESIGN

Though outwardly a system may appear to

have been developed in an object oriented
fashion,
But inside each class there is a small hierarchy
of functions designed in a top-down manner.
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.
SUMMARY
We characterized the features of a good
software design by introducing the
concepts of:
fan-in, fan-out,
cohesion, coupling,
abstraction, etc.
SUMMARY

We classified different types of

cohesion and coupling:
Enables us to approximately
determine the cohesion and
coupling existing in a design.
SUMMARY

Two fundamentally different

approaches to software design:
Function-oriented approach
Object-oriented approach
SUMMARY

We looked at the essential

philosophy behind these two
approaches
These two approaches are not
competing but complementary
approaches.