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
s How
What
i
Conceptual g Technical
design n design
e
r
s
A two part design System
Customer
process 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
 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 eases
implementation, 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 of
interdependence between 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
student ID,
record ID record
address,
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 only passing of data. Other than
communicating through data, the two modules are
independent.
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 to which the
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 whose instructions
although accomplish different tasks yet have been combined
because there is a specific order 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