UNIT-3

Software Design

More creative than

analysis
Problem solving activity

The goal of the design process is to product a model or

representation of a system, which can be used later to
build that system.
‘HOW’

Software design document (SDD)

2
 Why design is important?

A good design is the key to successful product. Few

desirable characteristics that every good software
design must possess are:

1. Correctness
2. Understandability
3. Efficiency
4. Maintainability

Without well-design system, we risk building an

unstable system.
• One that will fail when small changes are made.
• One that will be difficult to maintain. 3
 Good design vs Bad Design
Characteristics Good design Bad design
Change Change in one part of One change
the system does not requires changes to
always require a many parts of the
change in another part system.
of the system.
Cost Small High
Nature Simple Complex
Extension System can be System cannot be
extended with changes extended easily.
in only one place

4
 Objectives of Design

It deals with transforming the customer

requirements as described in the SRS document
into a form that is implementable using a
programming language. The design needs to be :

 Correct and Complete

 Understandable

 At the right level

 Maintainable 5
Software Design

6
Design Framework

7
Software Design

8
 Software Design
Conceptual Design and Technical Design

9
 Software Design
Conceptual design answers :

 Where will the data come from?

 What will happen to the data in the system?

 How will the system look to users?

 What choices will be offered to users ?

 What is the timing of events?

 How will the reports and screens look like? 1

0
 Software Design

Technical design describes :-

 Hardware configuration
Software needs
Communication Interfaces
 I/O of the system
 SoftwareArchitecture
 NetworkArchitecture

Any other thing that translates the requirements into a solution to

the customer’s problem.

1
1
 HLD and LLD

High Level Design Low Level Design

Also known as macro level/ Also known as micro level/
system design detailed design
Overall architecture of the Detailed description of the each
application and every module
participants are design team, participants are only design team
review team and client
input criteria is Software input criteria is HLD, which are
Requirement Specification(SRS) reviewed and authorized
Output criteria is database design, Output criteria is Program
functional design and review specification and unit test plan
record

1
2
 LOW LEVEL DESIGN

MODULARIZATION

A system is considered modular, if it consists of discrete

components so that each component can be implemented
separately and a change to one component has minimal
impact on other components.

1
3
 Advantages of Modular Systems
• Modular systems are easier to understand and explain
because their parts are functionally independent.

• Modular systems are easier to document because each part

can be documented as an independent unit.

• Programming individual modules is easier because the

programmer can focus on just one small, simple problem rather
than a large complex problem.

• Testing and debugging individual modules is easier

because they can be dealt with in isolation from the rest of the
program.
1
• Bugs are easier to isolate and understand and they can
4 be
 DESIGN MODEL
After analyzing and specifying all the requirements, the
process of software design begins. Each of the elements of
analysis model is used to create the design model. The
elements of design model are:-

1. Data Design (ER Diagram + Data Dictionary)

2. Architectural Design (DFD)

3. Interface Design (DFD + Control flow diagrams)

4. Component-level Design (Process + Control specification)

1
5
 SOFTWARE DESIGN
Software design is a creative process, just like designing anything else

To see a wrong design, we can check with the requirements in the
analysis model

To see a bad design, we need to assess the design model and analyze the
components, whether the performance can be improved by changing the
modules or the interfaces

In analyzing the software Design, many factors are used, out of which
two important factors are –
 Coupling
 Cohesion

16
 COUPLING
Coupling is the measure of “the degree of
interdependence between modules".

We aim to minimize coupling – to make modules as

independent as possible.

​Low coupling can be achieve by:

eliminating unnecessary relationships
reducing the number of necessary relationships
17
 COUPLING

Uncoupled modules have no interconnections at all,

they are completely independent.

(Uncoupled : no dependencies)
(a)
18
 Loosely coupled: Highly coupled:
some dependencies many dependencies
(B) (C)
Fig. : Module coupling

19
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 record
address, ID
course
Retrieve Retrieve
student record student record
Poor design: Tight Coupling Good design: Loose Coupling

Fig. : Example of coupling

20
 Data coupling Best (Most required)
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst (Least required)

Fig : The types of module coupling

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

ways in which they can be coupled.
21
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 Other than
communicating only data, modules are
independent. through data. the
two
Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.

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

External coupling
A form of a coupling in which a module has a dependency to other
module, external to the software being developed or to a particular
type of hardware. This is basically related to the communication to
external tools and devices such as the operating system, shared
libraries or the hardware .
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 back23

to all the modules which access that data to evaluate the effect of
Fig : Example of common coupling
24
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.

25
 Impact of Coupling on Design

A good design process should aim at reducing coupling.

Reduction of coupling -> reduction of dependence of one

module on another -> increase the independence of module ->
increase the ability to change or maintain the modules.

26
 COHESION
Cohesion measures how a single module is related to a particular
functionality in the system.
– only one module is involved
– ideally, a highly cohesive module should do only one task/
activity/function
– example:

• a sorting module that contains only one sorting function and this
function sorts integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but all sort integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but sort integers and floats.

27
 COHESION

Cohesion is a measure of the degree to which the

elements of a module are functionally related.

Module
strength

Fig : Cohesion=Strength of relations within modules

28
 Types of cohesion

➢ Functional cohesion
➢ Sequential cohesion

➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion

➢ Coincident cohesion

29
Given a procedure that carries out operations A & B, we can
describe various forms of cohesion between A & B.
Functional Cohesion Best (high)

Sequential Cohesion

Communicational Cohesion

Procedural Cohesion

Temporal Cohesion

Logical Cohesion

Coincidental Cohesion Worst (low)

Fig : Types of module cohesion

30
 Functional Cohesion

➢ . This is very good reason for them to be contained in the same

procedure.

➢ All elements contribute to the execution of one and only one

problem-related task

➢ Examples of functional cohesive modules:

• Compute cosine of angle
• Read transaction record
• Assign seat to airline passenger

➢A and B are part of a single functional task

31
 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.
➢ Elements are involved in activities such that output data from one
activity becomes input data to the next
➢ Usually has good coupling and is easily maintained

32
 Communicational Cohesion

➢ A and B both operate on the same input data or contribute

toward the same output data .
 Not flexible, for example, if we need to focus on some activities
and not the others

Example of Communicational Cohesion

- module determine customer details

use customer account no

find customer name
find customer loan balance
return customer name, loan balance

end module
33
 Procedural Cohesion

 Procedural cohesion occurs in modules whose

instructions accomplish different tasks yet have been
combined because there is a specific order in
which the tasks are to be completed.

 Example: an input function receiving a data, a function that

processes the data, and a function that outputs the result of that
computation, all placed in the same module

 Example: report module of an examination system includes

the following –
 calculate student GPA
 print student record
 calculate cumulative GPA
 print cumulative GPA
34
 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.
 functions that are related by time, all placed in the same
module
 example: the alarm system, automatic telephone dialing unit of a
security system both placed in the same module; these two must
be activated at the same time
 moderate level of cohesion

35
 Logical Cohesion

➢ Logical cohesion occurs in modules that contain

instructions that appear to be related because they fall into
the same category.
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module

➢ functions that are logically related to each other, all placed

in the same module
- example: a set of functions that output a given data in various
formats (bar chart, graph, pie-chart, …)
➢ moderate level of cohesion
36
 Coincidental Cohesion

➢ Coincidental cohesion exists in modules that

contain instructions that have little or no relationship to
one another.
➢ functions that are not at all related to each other but are placed
in a single module (happen to be a coincidence)
- example: a function that performs sorting and a printer driver,
both in the same module
➢ functions that are somewhat related but do not have much in
common also fall in this category.
- example: a function that computes an average of a sequence
and a function that sorts a sequence, both being placed in the
same module
 low-level cohesion
37
 Examples of Cohesion

Function A Function A Time t0

Function Function
B C logic Function A’ Time t0 + X
Function Function
D E Function A’’
Time t0 + 2X
Coincidental Logical Temporal
Parts unrelated Similar functions Related by time

Function A

Function B

Function C

Procedural
Related by order of functions
 Examples of Cohesion
Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to another

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions
 Impact of Cohesion on Design

A good design process should try to maximize cohesion

of each module

maximizing cohesion -> maximizing the use of the module

towards particular functionality -> appropriate modularization of
the design

40
 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 : View of cohesion and coupling

41
 Evaluating Coupling and Cohesion

• Coupling can be evaluated using metrics tools.

- metrics will be discussed later.

• Cohesion is generally evaluated manually by experts /

software engineers.
– walk through the design documents and iterate the design
until cohesion is improved to a satisfactory level .

42