Software Design

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

SRS Document Design Documents

Design Activities
Items Designed During
Design Phase
1. module structure,
2. control relationship among the modules
3. interface among different modules,
data items exchanged among different
modules,
4. data structures of individual modules,
5. algorithms for individual modules.
Module Structure
Introduction
A module consists of:
1. several functions
2. associated data structures.
D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
Introduction
Design activities are usually classified into
two stages:
1. preliminary (or high-level) design
2. detailed design.
High-level design
Identify:
1. modules
2. control relationships among modules
3. interfaces among modules.

d1 d2

d3 d1 d4
High-level design

The outcome of high-level design:

program structure (or software
architecture).
Detailed design
For each module, design:
1. data structure
2. algorithms

Outcome of detailed design:

module specification.
What Is Good Software
Design?

Should implement all functionalities of

the system correctly.
Should be easily understandable.
Should be efficient.
Should be easily able to change,
i.e. easily maintainable.
What Is Good Software
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.
What Is Good Software
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,

Design solution should consist of:

a cleanly decomposed set of modules
(modularity),
Different modules should be neatly
arranged in a hierarchy:
in a neat tree-like diagram.
Modularity
Modularity is a fundamental attributes
of any good design.

Decomposition of a problem cleanly into

modules:
1. Modules are almost independent of
each other
2. 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.
Example of Cleanly and
Non-cleanly Decomposed
Modules
Modularity

In technical terms, modules should

display:
1. high cohesion
2. low coupling.
Modularity
Neat arrangement of modules in a
hierarchy means:

1. low fan-out
Fan-out: a measure of the number of
modules directly controlled by given
module.

2. abstraction
Introduction:

The purpose of Design phase in the Software

Development Life Cycle is to produce a solution to a
problem given in the SRS(Software Requirement
Specification) document. The output of the design
phase is Software Design Document (SDD).

Coupling and Cohesion are two key concepts in

software engineering that are used to measure the
quality of a software system’s design.
Cohesion

Cohesion refers to the degree to which elements

within a module work together to fulfill a single,
well-defined purpose. High cohesion means that
elements are closely related and focused on a
single purpose, while low cohesion means that
elements are loosely related and serve multiple
purposes.
A good software design will have high
cohesion.
Classification of
Cohesiveness
functional HIGH
sequential
communicational Degree of
procedural cohesion

temporal
logical
coincidental
LOW
Coincidental cohesion

The elements are not related(unrelated).

The elements have no conceptual
relationship other than location in
source code. It is accidental and the
worst form of cohesion.
Ex- print next line and reverse the
characters of a string in a single
component.
Logical cohesion
The elements are logically related and not
functionally.
Ex- A component reads inputs from tape,
disk, and network. All the code for these
functions is in the same component.
Operations are related, but the functions are
significantly different.
Temporal cohesion

The elements are related by their timing involved.

A module connected with temporal cohesion all
the tasks must be executed in the same time
span. This cohesion contains the code for
initializing all the parts of the system. Lots of
different activities occur, all at unit time.
Procedural cohesion

Elements of procedural cohesion ensure the

order of execution. Actions are still weakly
connected and unlikely to be reusable.
Ex- calculate student GPA, print student record,
calculate cumulative GPA, print cumulative
GPA.
e.g. the algorithm for decoding a message.
Communicational
cohesion
If All functions of the module Refer to
the same data structure,
Example:
the set of functions defined on an array
or a stack.
Example- update record in the database
and send it to the printer.
Sequential cohesion

If the Elements of a module forms

different parts of a sequence.
Output from one element of the sequence is
input to the next.
i.e., data flow between the parts.
sort
Example: search

display
Functional cohesion

Every essential element for a single

computation is contained in the
component. A functional cohesion
performs the task and functions. It
is an ideal situation.
Coupling
Coupling refers to the degree of
interdependence between software
modules. High coupling means that
modules are closely connected and changes
in one module may affect other modules.
Low coupling means that modules are
independent and changes in one module
have little impact on other modules.
A good software will have low coupling.
Classes of coupling

data
stamp
control Degree of
coupling
common
content
Data coupling
 If the dependency between the modules
is based on the fact that they
communicate by passing only data, then
the modules are said to be data coupled.
 In data coupling, the components are
independent of each other and
communicate through data.
 Module communications don’t contain
tramp data.
 Example-customer billing system.
Stamp coupling
In stamp coupling, the complete data
structure is passed from one
module to another module.
Therefore, it involves tramp data
i.e, Data which is passed via one
function to another, and not
otherwise used by the first.
Control coupling
It exists between two modules.
If Data from one module is used
to direct order of instruction
execution in another.
Example of control coupling:
a flag set in one module and tested
in another module.
Common Coupling

Two modules are common

coupled, if they share some
global data items.
Content coupling
In a content coupling, one module can
modify the data of another module, or
control flow is passed from one module
to the other module.

This is the worst form of coupling and

should be avoided.
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=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.
Summary
We characterized the features of a
good software design by
introducing the concepts of:
fan-in, fan-out,
cohesion, coupling,
abstraction, etc.
Summary

Two fundamentally different

approaches to software design:
function-oriented approach
object-oriented approach