Software Engineering (3rd ed.), By K.

K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 1
 Software Design
❖ More creative than analysis

❖ Problem solving activity

WHAT IS DESIGN

‘HOW’

Software design document (SDD)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 2
 Software Design
Initial requirements

Gather data on user requirements

Analyze requirements data

Validate the design Obtain answers to

against the requirement
requirements questions

Conceive of a high level design

Refine & document the design

Completed design
Fig. 1 : Design framework
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 3
 Software Design

design

Satisfy

Customer Developers
(Implementers)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 4
 Software Design
Conceptual Design and Technical Design
D
e
What How
s
Conceptual Technical
design i design
g

A two part
e design System
Customer
process
r Builders
Fig. 2 : A two part design process
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 5
s
 Software Design

Conceptual design answers :

✓ Where will the data come from ?
✓ What will happen to data in the system?
✓ How will the system look to users?
✓ What choices will be offered to users?
✓ What is the timings of events?
✓ How will the reports & screens look like?

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 6
 Software Design
Technical design describes :
❖ Hardware configuration
❖ Software needs
❖ Communication interfaces
❖ I/O of the system
❖ Software architecture
❖ Network architecture
❖ Any other thing that translates the requirements in to a
solution to the customer’s problem.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 7
 Software Design

The design needs to be

➢ Correct & complete
➢ Understandable
➢ At the right level
➢ Maintainable

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 8
 Software Design

Informal More
design Informal formal Finished
outline design design
design

Fig. 3 : The transformation of an informal design to a detailed

design.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 9
 Software Design
MODULARITY
There are many definitions of the term module. Range is from :

i. Fortran subroutine
ii. Ada package
iii. Procedures & functions of PASCAL & C
iv. C++ / Java classes
v. Java packages
vi. Work assignment for an individual programmer
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
 Software Design

All these definitions are correct. A modular

system consist of well defined manageable
units with well defined interfaces among
the units.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 11
 Software Design
Properties :
i. Well defined subsystem
ii. Well defined purpose
iii. Can be separately compiled and stored in a
library.
iv. Module can use other modules
v. Module should be easier to use than to
build
vi. Simpler from outside than from the inside.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 12
 Software Design

Modularity is the single attribute of software that

allows a program to be intellectually manageable.
It enhances design clarity, which in turn
implementation,
eases debugging, testing,
documenting, and maintenance of software
product.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 13
 Software Design

Fig. 4 : Modularity and software cost

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 14
 Software Design
Module Coupling
Coupling is the measure of the degree
interdependence between of
modules.

(Uncoupled : no dependencies)
(a)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 15
 Software Design

Loosely coupled: Highly coupled:

some dependencies many dependencies
(B) (C)
Fig. 5 : Module coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 16
 Software Design

This can be achieved as:

❑ Controlling the number of parameters passed
amongst modules.
❑ Avoid passing undesired data to
calling module.
❑ Maintain parent / child relationship
between calling & called modules.
❑ Pass data, not the control information.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 17
 Software Design
Consider the example of editing a student record in a
‘student information system’.
Edit student Edit student
record record
Student name,
Student Student
student ID, Student
record record
address, ID
EOF EOF
course
Retrieve Retrieve
student record student record
Poor design: Tight Coupling Good design: Loose Coupling

Fig. 6 : Example of coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 18
 Software Design
Data coupling Best
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst
Fig. 7 : The types of module coupling

Given two procedures A & B, we can identify number of

ways in which they can be coupled.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 19
 Software Design
Data coupling
The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they
communicate by passing of than are
Other
communicating only
through data, modules
independent. data. the
two
Stamp coupling
Stamp coupling occurs between module A and B
when complete data structure is passed from one module to
another.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 20
 Software Design
Control coupling
Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module
and reacted upon by the dependent module.

Common coupling
With common coupling, module A and module B have shared
data. Global data areas are commonly found in programming
languages. Making a change to the common data means tracing
back to all the modules which access that data to evaluate the
effect of changes.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 21
 Software Design

Fig. 8 : Example of common coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 22
 Software Design

Content coupling
Content coupling occurs when module A changes data of
module B or when control is passed from one module to the
middle of another. In Fig. 9, module B branches into D, even
though D is supposed to be under the control of C.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 23
 Software Design

Fig. 9 : Example of content coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 24
 Software Design
Module Cohesion
Cohesion is a measure of the degree which the
to elements of a module are functionally
related.

Module
strength

Fig. 10 : Cohesion=Strength of relations within modules

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 25
 Software Design

Types of cohesion
➢ Functional cohesion
➢ Sequential cohesion

➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion

➢ Coincident cohesion

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 26
 Software Design

Functional Cohesion Best (high)

Sequential Cohesion

Communicational Cohesion

Procedural Cohesion

Temporal Cohesion

Logical Cohesion

Coincidental Cohesion Worst (low)

Fig. 11 : Types of module cohesion

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 27
 Software Design

Functional Cohesion
➢ A and B are part of a single functional task. This is very good
reason for them to be contained in the same procedure.

Sequential Cohesion
➢ Module A outputs some data which forms the input to B. This is
the reason for them to be contained in the same procedure.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 28
 Software Design

Procedural Cohesion
➢Procedural Cohesion occurs in modules
although whose instructions different tasks yet
accomplish
because there is a specifichave
order been combined
in which the tasks are to
be completed.

Temporal Cohesion
➢Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 29
 Software Design

Logical Cohesion
➢ Logical cohesion occurs in modules that contain instructions
that appear to be related because they fall into the same logical
class of functions.

Coincidental Cohesion
➢ Coincidental cohesion exists in modules that contain
instructions that have little or no relationship to one another.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 30
 Software Design
Relationship between Cohesion & Coupling
If the software is not properly modularized, a host of seemingly
trivial enhancement or changes will result into death of the project.
Therefore, a software engineer must design the modules with goal of
high cohesion and low coupling.

Fig. 12 : View of cohesion and coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 31