UNIT-3

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

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.

• Bugs are easier to isolate and understand and they can be fixed without fear
of introducing problems outside the module.
1
4
 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.

​ ow coupling can be achieve by:

L
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, data. the modules are
independent. through 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
 HIGH LEVEL DESIGN
ARCHITECTURAL DESIGN

The HLD, also called architectural design.

Large systems are always decomposed into subsystems that provide some
related set of services. The initial design process of identifying these sub-
systems and establishing a framework for sub-system control and
communication is called architectural design.

Architectural design methods look into various alternate architectural style

of designing a system. These are:

• Data centric architecture

• Data flow architecture
• Object oriented architecture
• Layered architecture
4
3
 ARCHITECTURAL DESIGN
Data centric architecture approach involves the use of a central
database operations of inserting, updating it in the form of a table.
Data flow architecture is applied when input data takes the form of
output after passing through various phases of transformations.
These transformations can be through various computations done on
data.
In Object oriented architecture, the software design moves around
the classes and objects of the system. The class encapsulates the
data and methods.

Layered approach defines the number of layers and each layer

performs tasks. The outermost layer handles the functionality of user
interface and the innermost layer handles interaction with the
hardware.
4
4
 Objective of Architectural Design
• To develop a model of software architecture, this gives overall
organization of program module in the software product.

• To control relationship between modules. One module may

control another module or may be controlled by another
module.

• The organization of module can be represented through a

tree like structure.

•In addition, HLD possess some attributes such as height,

depth, width and module fan-in, fan-out.

4
5
 Attributes
The height or depth of the design hierarchy is the number of
modules along the longest path from the top-level module
down to the lowest module in the hierarchy.

The width of the design hierarchy is the largest number of

modules existing at a given level of the hierarchy.

The no. of components which controls a said component is

called fan-in i.e, the no of incoming edges to a component.

The no. of components that are controlled by a module is

called fan-out i.e, the no of outgoing edges.
 

4
6
 STRATEGY OF DESIGN

A good system design strategy is to organize the program modules in

such a way that are easy to develop and latter to, change.
Structured design techniques help developers to deal with the size
and complexity of programs. Analysts create instructions for the
developers about how code should be written and how pieces of
code should fit together to form a program. It is important for two
reasons:
➢ First, even pre-existing code, if any, needs to be understood,
organized and pieced together.
➢ Second, it is still common for the project team to have to write
some code and produce original programs that support the
application logic of the system.
47
 Bottom-Up Design

These modules are collected together in the form of a

“library”.

Fig : Bottom-up tree structure

48
 Top-Down Design
•A top down design approach starts by
identifying the major modules of the system,
decomposing them into their lower level
modules and iterating until the desired level of
detail is achieved. This is stepwise refinement;
starting from an abstract design, in each step
the design is refined to a more concrete level,
until we reach a level where no more
refinement is needed and the design can be
implemented directly. 49
 Hybrid Design

For top-down approach to be effective, some bottom-up approach

is essential for the following reasons:

➢ To permit common sub modules.

➢ Near the bottom of the hierarchy, where the intuition is simpler,
and the need for bottom-up testing is greater, because there are
more number of modules at low levels than high levels.
➢ In the use of pre-written library modules, in particular, reuse of
modules.

50
 Structure Chart
It partition a system into block boxes. A black box means
that functionality is known to the user without the knowledge of
internal design.

Fig : Hierarchical format of a structure chart 51

Fig. 17 : Structure chart notations

52
A structure chart for “update file” is given in fig.

Fig : Update file

53
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.

Fig: Transaction-centered structure

54
In the above figure the MAIN module controls the system operation its
functions is to:

➢ invoke the INPUT module to read a transaction;

➢ determine the kind of transaction and select one of a number

of transaction modules to process that transaction, and
➢ output the results of the processing by calling
OUTPUT module.

55
 Pseudocode
•Pseudocode notation can be used in both the
preliminary and detailed design phases.
•Using pseudocode, the designer describes
system characteristics using short, concise,
English language phrases that are structured by
key words such as If-Then-Else, While-Do, and
End.

56