Software Design

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. Object-
oriented design
Ñ Summary
Review of previous
lectures
ÑIntroduction to software
engineering
ÑLife cycle models
ÑRequirements Analysis and
Specification:
y Requirements gathering and
analysis
y Requirements specification
Introduction
ÑDesign phase transforms SRS
document:
y into a form easily implementable in
some programming language.

SRS Document Design Documents

Design Activities
Items Designed During
Design Phase
Ñ 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.
Module Structure
Introduction
ÑA module consists of:
y several functions
y associated data structures.
D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
Introduction
ÑGood software designs:
y seldom arrived through a single
step procedure:
y but through a series of steps and
iterations.
Introduction
Ñ Design activities are usually classified
into two stages:
y preliminary (or high-level) design
y detailed design.
Ñ Meaning and scope of the two stages:
y vary considerably from one methodology to
another.
High-level design
Ñ Identify:
y modules
y control relationships among modules
y interfaces among modules.

d1 d2

d3 d1 d4
High-level design

ÑThe outcome of high-level design:

y program structure (or software
architecture).
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 Warnier-
Orr diagram can also be used.
Detailed design
ÑFor each module, design:
y data structure
y algorithms
ÑOutcome of detailed design:
y module specification.
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.
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?
ÑShould implement all functionalities of
the system correctly.
ÑShould be easily understandable.
ÑShould be efficient(adequately
address resource, time and cost
optimisation techniques).
ÑShould be easily amenable to change,
y i.e. easily maintainable.
What Is Good Software
Design?

ÑUnderstandability of a design is
a major issue:
y determines goodness of design:
y a design that is easy to
understand:
xalso easy to maintain and
change.
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
is spent in maintenance.
ÑIf the software is not easy to
understand:
y maintenance effort would increase many
times.
Understandability
Ñ Use consistent and meaningful names
y for various design components,
Ñ Design solution should consist of:
y a cleanly decomposed set of modules
(modularity),
Ñ Different modules should be neatly
arranged in a hierarchy:
y in a neat tree-like diagram.
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.
Modularity
ÑIf modules are independent:
y modules can be understood
separately,
x reduces the complexity greatly.
y To understand why this is so,
x 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:
y high cohesion
y low coupling.
ÑWe will shortly discuss:
y cohesion and coupling.
Modularity
ÑNeat arrangement of
modules in a hierarchy
means:
ylow fan-out
yabstraction
Cohesion and Coupling

ÑCohesion is a measure of:

y functional strength of a module.
y A cohesive module performs a single
task or function.
ÑCoupling between two modules:
y a measure of the degree of
interdependence or interaction
between the two modules.
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

ÑBetter understandability and good

design:
ÑComplexity of design is reduced,
ÑDifferent modules easily understood
in isolation:
y modules are independent
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.
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.
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.
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.
Classification of
Cohesiveness
functional
sequential
communicational Degree of
procedural cohesion

temporal
logical
coincidental
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.
Logical cohesion
ÑAll elements of the module perform
similar operations:
y e.g. error handling, data input, data
output, etc.
ÑAn example of logical cohesion:
y a set of print functions to generate an
output report arranged into a single
module.
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.
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,
xe.g. the algorithm for decoding a
message.
Communicational
cohesion

ÑAll functions of the module:

y reference or update the same data
structure,
ÑExample:
y the set of functions defined on an
array or a stack.
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

search
display
Functional cohesion

ÑDifferent elements of a module

cooperate:
y to achieve a single function,
y e.g. managing an employee's pay-
roll.
ÑWhen a module displays
functional cohesion,
y we can describe the function
using a single sentence.
Determining Cohesiveness

ÑWrite down a sentence to describe

the function of the module
y If the sentence is compound,
xit has a sequential or communicational
cohesion.
y If it has words like “first”, “next”,
“after”, “then”, etc.
xit has sequential or temporal
cohesion.
y If it has words like initialize,
xit probably has temporal cohesion.
Coupling
ÑCoupling indicates:
y how closely two modules interact
or how interdependent they are.
y The degree of coupling between
two modules depends on their
interface complexity.
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.
Classes of coupling

data
stamp
control Degree of
coupling
common
content
Data coupling
ÑTwo modules are data coupled,
y if they communicate via a
parameter:
x an elementary data item,
xe.g an integer, a float, a character,
etc.
y The data item should be problem
related:
xnot used for control purpose.
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.
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.
Common Coupling

ÑTwo modules are common

coupled,
yif they share some global data.
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.
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.
Neat Arrangement of
modules

ÑEssentially means:
ylow fan-out
yabstraction
Characteristics of Module
Structure
ÑDepth:
y number of levels of control
Ñ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

ÑFan-in:
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
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.
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, a module controlled
by another module:
y said to be subordinate to it.
Visibility and Layering

Ñ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.
Bad Design
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.
y Also known as layered design.
High-level Design

ÑHigh-level design maps functions

into modules {fi} {mj} 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
High-level Design

• f1
• f2
• f3 d1 d2

•
• d3 d1 d4
•
• fn
Design Approaches

ÑTwo fundamentally different

software design approaches:
y Function-oriented design
y Object-oriented design
Design Approaches

ÑThese two design approaches

are radically different.
y However, are complementary
xrather than competing techniques.
y Each technique is applicable at
xdifferent stages of the design
process.
Function-Oriented Design

ÑA system is looked upon as something

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

ÑThe function create-new-library-

member:
y creates the record for a new
member,
y assigns a unique membership
number
y prints a bill towards the membership
Example

ÑCreate-library-member function
consists of the following sub-
functions:
y assign-membership-number
y create-member-record
y print-bill
Function-Oriented Design

ÑEach subfunction:
ysplit into more detailed
subfunctions and so on.
Function-Oriented Design

ÑThe system state is centralized:

y accessible to different functions,
y member-records:
xavailable 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:
y Structured design (Constantine and
Yourdon, 1979)
y Jackson's structured design (Jackson,
1975)
y Warnier-Orr methodology
y Wirth's step-wise refinement
y 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:
y each object manages its own
state information.
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.
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.
Object-Oriented versus Function-
Oriented Design

ÑUnlike function-oriented design,

y in OOD the basic abstraction is
not functions such as “sort”,
“display”, “track”, etc.,
y but real-world entities such as
“employee”, “picture”, “machine”,
“radar system”, etc.
Object-Oriented versus Function-
Oriented Design

ÑIn OOD:
y software is not developed by
designing functions such as:
xupdate-employee-record,
xget-employee-address, etc.
y but by designing objects such as:
xemployees,
xdepartments, etc.
Object-Oriented versus Function-
Oriented Design

ÑGrady Booch sums up this

fundamental difference
saying:
y“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:
ystate information is not shared
in a centralized data.
ybut is distributed among the
objects of the system.
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, etc.
ÑWhereas, in object oriented
systems:
y data is distributed among different
employee objects of the system.
Object-Oriented versus Function-
Oriented Design

ÑObjects communicate by
message passing.
y 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:
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 Function-
Oriented Design

ÑFunction-oriented techniques group

functions together if:
y as a group, they constitute a higher
level function.
ÑOn the other hand, object-oriented
techniques group functions
together:
y 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,
y let us consider an example ---
y 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:
y There are 80 floors and 1000 rooms
in the building.
Fire-Alarm System:

ÑDifferent rooms of the building:

y fitted with smoke detectors and fire
alarms.
ÑThe fire alarm system would
monitor:
y status of the smoke detectors.
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

ÑThe fire alarm system should:

y flash an alarm message on the
computer console:
xfire fighting personnel man the
console round the clock.
Fire-Alarm System

ÑAfter a fire condition has been

successfully handled,
y 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,
y appropriate number of instances of the class detector
and alarm should be created.
Object-Oriented versus Function-
Oriented Design
ÑIn the function-oriented program :
y the system state is centralized
y several functions accessing these data
are defined.
Ñ In the object oriented program,
y the state information is distributed
among various sensor and alarm
objects.
Object-Oriented versus Function-
Oriented Design

ÑUse OOD to design the classes:

y then applies top-down function
oriented techniques
xto 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,
y but inside each class there is a small
hierarchy of functions designed in a top-
down manner.
Summary
ÑWe started with an overview of:
y activities undertaken during the
software design phase.
ÑWe identified:
y the information need to be produced
at the end of the design phase:
x 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:
y fan-in, fan-out,
y cohesion, coupling,
y abstraction, etc.
Summary
ÑWe classified different types of
cohesion and coupling:
yenables us to approximately
determine the cohesion and
coupling existing in a design.
Summary

ÑTwo fundamentally different

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

ÑWe looked at the essential

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