2/10/2015

Software Design

Review of previous
lectures
Introduction to software
engineering
Life cycle models
Requirements Analysis and
Specification:
y Requirements gathering and
analysis
y Requirements specification

Items Designed During

Design Phase

Organization of this
Lecture
Brief review of previous lectures
Introduction to software design
Goodness of a design
Functional Independence
Cohesion and Coupling
Function-oriented design vs. Objectoriented design
Summary

Introduction
Design phase transforms SRS
document:
y into a form easily implementable in
programming
g
g language.
g g
some p
SRS Document

Design Activities

Design Documents

Module Structure

module structure,
control relationship among the modules
y call relationship or invocation relationship

interface among different modules,

y data items exchanged among different

modules,

data structures of individual modules,

algorithms for individual modules.

2/10/2015

Introduction
A module consists of:

y several functions
y associated data structures.
D1 ..
D2 ..
D3 ..
F1 ..
F2 ..
F3 ..
F4 ..
F5 ..

Data
Functions

Introduction
Design activities are usually classified
into two stages:
y preliminary (or high-level) design
y detailed design.
g

Introduction
Good software designs:
y seldom arrived through a single
step procedure:
y but
b t th
through
h a series
i off steps
t
and
d
iterations, called the design
activities.

High-level design
Identify:

y modules
y control relationships among modules
y interfaces among modules.

Meaning and scope of the two stages:

y vary considerably from one methodology to
another.

High-level design
The outcome of high-level design:
y program structure (or software
architecture).

d2

d1

d3

d1

d4

High-level Design
Several notations are available to
represent high-level design:
y Usually a tree-like diagram called
structure chart is used.
y Other notations:
xJackson diagram or WarnierOrr diagram can also be used.

2/10/2015

Detailed design
For each module, design:
y data structure
y algorithms
O
Outcome
off detailed
d il d design:
d i
y module specification.

Good and bad designs

There is no unique way to
design a system.
Even using the same design
methodology:

y different engineers can arrive at

very different design solutions.

We need to distinguish between

good and bad designs.

What Is Good Software

Design?
Understandability of a design is
a major issue:

y determines goodness of design:

y a design
d i that
h is
i easy to
understand:
xalso easy to maintain and
change.

A fundamental question:
How to distinguish between good
and bad designs?
y Unless we know what a good
software design is:
xwe can not possibly design one.

What Is Good Software

Design?
Should implement all functionalities of
the system correctly.
Should be easily understandable.
Should be efficient
y Resource, time and cost optimization issues

Should be easily amenable to change,

y i.e. easily maintainable.

What Is Good Software

Design?
Unless a design is easy to understand,
y tremendous effort needed to maintain it
y We already know that about 60% effort
i spentt in
is
i maintenance.
i t

If the software is not easy to

understand:

y maintenance effort would increase many

times.

2/10/2015

Understandability
Use consistent and meaningful names
y for various design components,

Design solution should consist of:

y a cleanly decomposed set of modules

(modularity),
(modularity)

Different modules should be neatly

arranged in a hierarchy:
y in a neat tree-like diagram.

Modularity

Modularity
Modularity is a fundamental
attributes of any good design.
y Decomposition of a problem cleanly
into modules:
y Modules are almost independent of
each other
y divide and conquer principle.

Example of Cleanly and Noncleanly Decomposed Modules

If modules are independent:

y modules can be understood
separately,
x reduces the complexity greatly.

y To understand
d
d why
h this
h is so,
x remember that it is very difficult to break
a bunch of sticks but very easy to break
the sticks individually.

Modularity
In technical terms, modules should
display:
y high cohesion
y low coupling.
coupling

We will shortly discuss:

y cohesion and coupling.

Modularity
Neat arrangement of
modules in a hierarchy
means:
ylow fan-out
yabstraction

2/10/2015

Cohesion and Coupling

Cohesion is a measure of:

y functional strength of a module.

y A cohesive module performs a single
task or function.

C
Coupling
li between
b t
two
t
modules:
d l
y a measure of the degree of
interdependence or interaction
between the two modules.

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

Advantages of Functional
Independence
A functionally independent module:
y can be easily taken out and reused in
a different program.
x each module does some well-defined and
precise function
x the interfaces of a module with other
modules is simple and minimal.

Cohesion and Coupling

A module having high cohesion
and low coupling:
y functionally independent of other
modules:
xA functionally independent module
has minimal interaction with other
modules.

Advantages of Functional
Independence
Functional independence reduces
error propagation.
y degree of interaction between
modules is low.
y an error existing in one module does
not directly affect other modules.

Reuse of modules is possible.

Functional Independence
Unfortunately, there are no ways:
y to quantitatively measure the
degree of cohesion and coupling:
y classification of different kinds of
cohesion and coupling:
x will give us some idea regarding the
degree of cohesiveness of a module.

2/10/2015

Classification of
Cohesiveness
Classification is often subjective:
y yet gives us some idea about
cohesiveness of a module.

By examining the type of cohesion

exhibited by a module:

y we can roughly tell whether it displays

high cohesion or low cohesion.

Coincidental cohesion
The module performs a set of tasks:
y which relate to each other very
loosely, if at all.
x the module contains a random collection
of functions.
x functions have been put in the module
out of pure coincidence without any
thought or design.

Temporal cohesion
The module contains tasks that are
related by the fact:

y all the tasks must be executed in the same

time span.

Example:

y The set of functions responsible for

x initialization,
x start-up, shut-down of some process, etc.

Classification of
Cohesiveness
functional
sequential
communicational
procedural

Degree of
cohesion

temporal
logical
coincidental

Logical cohesion
All elements of the module perform
similar operations:
y e.g. error handling, data input, data
output, etc.

A example
An
l off logical
l i l cohesion:
h i

y a set of print functions to generate an

output report arranged into a single
module.

Procedural cohesion
The set of functions of the
module:
y all part of a procedure (algorithm)
y certain sequence of steps have to
be carried out in a certain order
for achieving an objective,
x e.g. the algorithm for decoding a
message.

2/10/2015

Communicational
cohesion
All functions of the module:
y reference or update the same data
structure,

Example:

Sequential cohesion
Elements of a module form
different parts of a sequence,

y output from one element of the

sequence is input to the next.
y Example:

sort

y the set of functions defined on an

array or a stack.

search
display

Functional cohesion
Different elements of a module
cooperate:

y to achieve a single function,

y e.g. managing an employee's payroll.

When a module displays

functional cohesion,

y we can describe the function

using a single sentence.

Coupling
There are no ways to precisely determine
coupling between two modules:

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

Coupling
Coupling indicates:
y how closely two modules interact
or how interdependent they are.
y The
Th degree
d
off coupling
li between
b t
two modules depends on their
interface complexity.

Classes of coupling
data
stamp
control
common

Degree of
coupling

content

2/10/2015

Data coupling
Two modules are data coupled,
y if they communicate via a
parameter:

x an elementary data item,

g an integer,
g , a float,, a character,,
xe.g
etc.

y The data item should be problem

related:
xnot used for control purpose.

Control coupling
Data from one module is used
to direct

y order of instruction execution in

another.

Example of control coupling:

y a flag set in one module and
tested in another module.

Content coupling
Content coupling exists between
two modules:

y if they share code,

y e.g, branching from one module into
another module.

The degree of coupling increases

y from data coupling to content
coupling.

Stamp coupling
Two modules are stamp
coupled,
y if they communicate via a
composite data item
xsuch as a record in PASCAL

xor a structure in C.

Common Coupling
Two modules are common
coupled,

yif they share some global data

data.

Neat Hierarchy
Control hierarchy represents:
y organization of modules.
y control hierarchy is also called
program structure.

Most common notation:

y a tree-like diagram called structure
chart.

2/10/2015

Neat Arrangement of
modules

Characteristics of Module
Structure
Depth:

Essentially means:

y number of levels of control

ylow fan-out
yabstraction

Width:

y overall span of control.

Fan-out:

y a measure of the number of modules

directly controlled by given module.

Characteristics of Module
Structure

Characteristics of Module
Structure

Fan-in:

Visibility

yindicates how many modules

directly invoke a given module.
yHigh fan-in represents code
reuse and is in general
encouraged.

Module Structure
Fan out=2
Fan out=1
Fan in=1
Fan in=2
Fan out=0

y Module B is visible to module A if A directly

calls B

Control Abstraction
y Modules at higher layer should not be visible
to modules at lower layers

Goodness of Design
A design having modules:
y with high fan-out numbers is not a
good design:
y a module having high fan-out lacks
cohesion.

2/10/2015

Goodness of Design
A module that invokes a large
number of other modules:
y likely to implement several different
functions:
y not likely to perform a single cohesive
function.

Control Relationships
A module that controls another
module:
y said to be superordinate to it.

Conversely,
C
l a module
d l controlled
t ll d
by another module:
y said to be subordinate to it.

Visibility and Layering

Bad Design

A module A is said to be visible by

another module B,
y if A directly or indirectly calls B.
The layering principle requires
y modules at a layer can call only the
modules immediately below it.

Abstraction
Lower-level modules:
y do input/output and other low-level
functions.

Upper-level modules:
y do more managerial functions.

Abstraction
The principle of abstraction
requires:
y lower-level modules do not invoke
functions of higher level modules
modules.
y Also known as layered design.

10

2/10/2015

High-level Design
High-level design maps functions
into modules such that:
y Each module has high cohesion
y Coupling among modules is as low as
possible
y Modules are organized in a neat
hierarchy

Design Approaches
Two fundamentally different
software design approaches:
y Function-oriented design
g
y Object-oriented design

High-level Design
f1
f2
f3

d2

d1

d3

d1

d4

fn

Design Approaches
These two design approaches
are radically different.
y However, are complementary

xrather than competing techniques.

techniques

y Each technique is applicable at

xdifferent stages of the design
process.

Function-Oriented Design

Example

A system is looked upon as something

The function create-new-librarymember:

y that performs a set of functions.

Starting at this high-level view of the

system:
y each function is successively refined into
more detailed functions.
y Functions are mapped to a module
structure.

y ccreates
eates tthe
e record
eco d for
o a new
e
member,
y assigns a unique membership
number
y prints a bill towards the membership

11

2/10/2015

Example

Function-Oriented Design

Create-library-member function
consists of the following subfunctions:

Each subfunction:

y assign-membership-number
y create-member-record
y print-bill

Function-Oriented Design
The system state is centralized:
y accessible to different functions,
y member-records:

x available for reference and updation to

several functions:
create-new-member
delete-member
update-member-record

Object-Oriented Design
Example

Library Automation Software:

yeach library member is a
separate object

xwith its own data and functions.

yFunctions defined for one

object:

xcannot directly refer to or

change data of other objects.

ysplit into more detailed

subfunctions and so on.
on

Object-Oriented Design
System is viewed as a collection
of objects (i.e. entities).
System state is decentralized
among the objects:
y each object manages its own
state information.

Object-Oriented Design
Objects have their own internal
data:
y defines their state.

Similar objects constitute a class.

y each object is a member of some
class.

Classes may inherit features

y from a super class.

Conceptually, objects communicate

by message passing.

12

2/10/2015

Object-Oriented Design
Data Abstraction
Data Structure
Data Type

Object-Oriented versus FunctionOriented Design

In OOD:

y software is not developed by

designing functions such as:
xupdate-employee-record,
update e p oyee eco d,
xget-employee-address, etc.

y but by designing objects such as:

xemployees,
xdepartments, etc.

Object-Oriented versus FunctionOriented Design

In OOD:

ystate information is not shared

in a centralized data.
data
ybut is distributed among the
objects of the system.

Object-Oriented versus FunctionOriented Design

Unlike function-oriented design,

y in OOD the basic abstraction is
not functions such as sort,
display
display , track
track , etc.,
etc
y but real-world entities such as
employee, picture, machine,
radar system, etc.

Object-Oriented versus FunctionOriented Design

Grady Booch sums up this

fundamental difference
saying:

yIdentify
Id tif verbs
b if you are after
ft
procedural design and nouns if
you are after object-oriented
design.

Example:
In an employee pay-roll system,
the following can be global data:
y names of the employees,
y their code numbers,
y basic salaries,
salaries etc.
etc

Whereas, in object oriented

systems:

y data is distributed among different

employee objects of the system.

13

2/10/2015

Object-Oriented versus FunctionOriented Design

Objects communicate by
message passing.
y one object may discover the state
information of another object by
interrogating it.

Object-Oriented versus FunctionOriented Design

Function-oriented techniques group

functions together if:
y as a group, they constitute a higher
level function.

On the other hand, object-oriented

j
t h i
techniques
group functions
f
ti
together:

y on the basis of the data they operate

on.

Object-Oriented versus FunctionOriented Design

Of course, somewhere or other the

functions must be implemented:
y the functions are usually associated
with specific real-world entities
(objects)
y directly access only part of the system
state information.

Object-Oriented versus FunctionOriented Design

To illustrate the differences between

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

Fire-Alarm System:

Fire-Alarm System:

We need to develop a
computerized fire alarm system
g multi-storied building:
g
for a large

Different rooms of the building:

y There are 80 floors and 1000 rooms

in the building.

y fitted with smoke detectors and fire

alarms.

The fire alarm system would

monitor:
y status of the smoke detectors.

14

2/10/2015

Fire-Alarm System
Whenever a fire condition is
reported by any smoke detector:
y the fire alarm system should:

xdetermine the location from which

the fire condition was reported
xsound the alarms in the neighboring
locations.

Fire-Alarm System
After a fire condition has been
successfully handled,
y tthe
e fire
ea
alarm
a
syste
system sshould
ou d let
et fire
e
fighting personnel reset the alarms.

Object-Oriented Approach:
class detector

attributes: status, location, neighbors

operations: create, sense-status, get-location,

find-neighbors
class alarm

attributes: location,, status

operations:
i
create, ring-alarm,
i
l
get_location,
l
i

reset-alarm
In the object oriented program,

y appropriate number of instances of the class detector and

alarm should be created.

Fire-Alarm System
The fire alarm system should:
y flash an alarm message on the
computer console:
xfire
fi fighting
fi hti
personnell man the
th
console round the clock.

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
g
[
][ ];//*each detector has at most*//
/* 10 neighboring
i hb i
alarm
l
locations
l
i
*/
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();

Object-Oriented versus FunctionOriented Design

In the function-oriented program :

y the system state is centralized

y several functions accessing these data
are defined.

In the object
j
oriented program,
p g
,

y the state information is distributed

among various sensor and alarm
objects.

15

2/10/2015

Object-Oriented versus FunctionOriented Design

Object-Oriented versus FunctionOriented Design

Use OOD to design the classes:

Though outwardly a system may

appear to have been developed in an
object oriented fashion,

y then applies top-down function

q
oriented techniques
xto design the internal methods of
classes.

Summary
We started with an overview of:
y activities undertaken during the
software design phase.

We identified:

y the information need to be p

produced
at the
h end
d off the
h design
d
phase:
h
x so that the design can be easily
implemented using a programming
language.

y but inside each class there is a small

hierarchy of functions designed in a topdown manner.

Summary
We characterized the features of
a good software design by
introducing the concepts of:
y fan-in,
f i fan-out,
f
t
y cohesion, coupling,
y abstraction, etc.

Summary

Summary

We classified different types of

cohesion and coupling:

Two fundamentally different

approaches to software design:

yenables us to approximately
determine the cohesion and
coupling existing in a design.

y function-oriented
u ct o o e ted app
approach
oac
y object-oriented approach

16

2/10/2015

Summary
We looked at the essential
philosophy behind these two
pp
approaches
y these two approaches are not
competing but complementary
approaches.

17