UNIT-3

SOFTWARE
DESIGN
 Contents
• Software Design
• Why Design is important ?
• Objectives of Design
• Design Framework
• Types of Software Design
• Characterstics of Good design
• Design Process or levels of Design
• Software Design Approaches
• Strategies of Design
 Software Design (SD)

Software design is more creative than analysis because it deals with

development of actual system.

Design of a system is considered as blue print for the solution of

system

Software design is Problem solving activity which tells how software

systems works
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’
3

Software design document (SDD)

 Why Design is important ?

The purpose of design is to produce a solution to a problem given in

SRS document .
A well designed system is easy to implement , understandable and
reliable and allows for smooth evolution.
Without well-design system, we taking a risk of building an unstable
system.
• One that will fail when small changes are made.
• One that will be difficult to maintain.

4
 Objectives of Design

• Software design deals with transforming the customer requirements are

described as SRS document into the form that is implementable using
programming language.
So design fills the gap between specifications and coding , taking the
specification, deciding how the program will be organized and the
methods it will use , in sufficient detail as to be directly codeable.
Design need to be :
• Correct and complete
• Understandabe
• Maintainable
• Implement all explicit and implicit contained in analysis model
Design Framework

6
 Contd.. Design framework

It starts with initial requirements and ends up with the final design.
Here , the data is gathered on user requirements and analysed accordingly.
A high level design is prepared after answering questions of requirements .
Moreover , a design is validated against requirements on regular basis .
Design is refined in every cycle and finally it is documented to produce
software design document(SDD)
 Types of Software Design
Conceptual Design and Technical Design

8
 Types of Software Design
Conceptual design answers to the following questions

 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? 9

 Types of 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
0
 Characterstics of Good design

A good design is the key to successful product.

Few desirable characteristics that every good software design must
possess are:

1. Correct and complete

2. Understandability
3. Efficiency
4. Maintainability

1
1
 Contd..

• Correctness : The design of a system is correct if a system built precisely

according to the design satisfies the requirements of that system
• Completeness: Completeness requires that all the different components of
the design should be verified i.e all the relevant data structure, modules,
external interfaces and module connection are specified.
• Understanding :
In order to make it understandable :
----Use consistent approach and meaningful names for various design
components.
----Design solution should contain cleanly decomposed set of
modules(modularity)
 Contd..

• Modularity is a fundamental attributes of any good design

• Modularity : Decomposition of problem into modules.
• It refers to the extent to which a software may be divided into smaller
modules. Software modularity indicates that the number of application
modules are capable of serving a specified business domain.
• Modularity is successful because developers use prewritten code, which
saves resources. Overall, modularity provides greater software
development manageability.

Module is a software component with deals with level of abstraction.

• Modules should display :
High cohesion
Low coupling
 Properties of modular system

- Each module is a well defined subsystem that is potentially

useful in other applications.
- Each module has a single, well defined purpose.
- Modules can be separately compiled and stored in a library.
- Modules can use other modules
- Modules should be simpler from the outside than from the
inside.
 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
5
There are five criteria that enables us to evaluate a design method
with respect to its ability to define an effective modular system

--Modular decomposability: A design method provides a systematic

mechanism for decomposing the problem into sub problems. This reduces
the complexity of the problem and the modularity can be achieved.
--Modular composability : A design method enables existing design
components to be assembled into a new system.
--Modular understandability: A module can be understood as standalone unit.
It will be easier to build and easier to change.
--Modular continuity: Small changes to system requirements result in changes
to individual modules, rather than system wide changes.
-- Modular protection: An abnormal condition occurs within a module and its
effects are constrained within the module.
 MODULE
COUPLING

Coupling is the measure of “the degree of

interdependence between modules".
It measures how closely two modules are connected or strength
of relationship

We aim
--- to minimize coupling – to make modules as independent as
possible.
---To maximize cohesion

​Low coupling can be achieve by:

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

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

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

: 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 two modules is said to be data coupled if their

dependency is based on the fact they communicate by only passing of data.
Data coupling occurs when module passes non global variable to another
module.

Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.
--Internal structure contains data not used
--Bundling - grouping of unrelated data into an artificial structure

22
 Control coupling
Module A and B are said to be control coupled if they communicate
by passing of control information. Two modules are called control-coupled if
one of them decides the function of the other module or changes its flow of
execution
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 back to all the modules which access
that data to evaluate the effect of changes.
Eg: When multiple modules have read and write access to some global data 23

It might face ripple effect

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.
Content Coupling is the highest type of coupling which occurs when one of the
module relies on the other module’s internal working. It means a change in the
second module will lead to the changes in the dependent module.

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.
It measures the relationship strength between the pieces of
functionality(elements) within a given module
– 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

➢ A module is said to be functionally cohesive if all elements contribute

to the execution of one and only one problem-related task
➢ Focused
➢ No elements doing unrelated activities

31
 Sequential Cohesion

➢ In module element A outputs some data which forms the

input to B element . 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,

Example of Communicational Cohesion

Eg 1: module determine customer details

use customer account no----

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

end module
Eg 2: The set of instruction defined on an array or stack
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.
Elements are related only by sequence, otherwise the activities are unrelated
Similar to sequential cohesion, except for the fact that elements are unrelated

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

Elements(functions) are involved in activities that are related in time

Commonly found in initialisation and termination modules

Eg : module initialise
set counter to 0
open student file
initialise array

35
 Logical Cohesion
➢ Logical cohesion occurs in modules that contain instructions that
appear to be related because they fall into the same category.
➢ Elements contribute to activities of the same general category (type) i.e
functions that are logically related to each other, all placed in the same
module
➢ For example, a report module, display module or I/O module
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module

➢ Example 2: 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.
➢ Elements contribute to activities with no meaningful 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
 Advantages of high cohesion

• High cohesion leads to the increased module reusability

because the developers of the application will easily find the
component they look for in the cohesive set of operations
offered by the module.
• The system maintainability will be increased due to logical
changes in the domain effecting fewer modules.
• The module complexity also reduces, when there is a high
cohesion in the programming.
 Relationship between Cohesion & Coupling

If the software is not properly modularized, 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

42
 Design Process or levels of Design

• Design process is a sequence of steps carried through which requirements

are translated into system or software model.
The software design process can be decomposed into two levels of design :
1. HLL(high level Design):
At this level the focus is on deciding which modules are needed for the system ,
the specifications are interconnected. This is also called as top level design
or system design or High level design

2. LLD(Low level Design):

At this level , the internal design of the modules or how the specification of the
modules can be satisfied is decided. This deign level is called detailed design
or logic design.
 Contd……..LLD or detailed level design

It defines logical structure of each module

For each module we focus on:
• Data structure
• Algorithms
Thus the outcome of this level is module
specification.
 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

4
5
 Types of HLD
1. Interface Design 2. Architecture design

1.Interface design
• User interface is responsible for all interactions with the user .
• Almost every software product has a user interface.
• Many user judge software from its user interface. Thus user interface design is : A
practical and important problem
If it is difficult to use interface
It leads to higher levels of user errors
It leads to user dissatisfaction
A significant portion of the total development effort spent in developing the user
interface thus it is important to carefully study related to user interface design
concepts

• Interface design deals with specification of interaction between a system and its
environment. During interface design, internal design are completely ignored in
terms of relationship between system and environment
• It represents the flow of information and specific type of behaviour
.
 Contd…..user interface design
It includes:
----- Precise description of the events or messages that system must
produce.
----- Specification of the data and the formats of the data, coming into and
going out of the system
----- Specification of the ordering and timing relationship between incoming
events or messages and outgoing events or outputs
 What a good interface is :

1. High speed of learning

---- A good interface should be simple to learn.
---- Most users put off by complex syntax and semantics of the command
issue procedures
---- A good interface should not require users to memorize commands
---- Consistency also affect the speed of learning- once the user learns about
the command , should be able to use similar commands
---- Users can learn about an interface faster , if it is based on : day to real
life examples
---- Use concepts with which users are already familiar
 Contd.

2. Speed of use :
Speed of use is determined by :
• The time and effort necessary to initiate and execute different commands
• The time and user effort necessary to execute different commands should
be minimal
Example of bad user interface :
Users required to type in highly commands
• Command issue involves moving the mouse to widely different areas of
the screen
• Can slow down the operating speed of users
 Contd..

3. Speed of recall
Once the users learn how to use an interface , their speed of recall about using
the interface should be maximized
• The speed of recall is improved if the interface is based on : metaphors
• Intitutive command names
• Symbolic command issue procedure
 Contd.. User interface

Types of User interface design:

• Menu based Design

• Command based design
 2. Architecture Design

Architecture design or system design is the specification of the major

components of a system their responsibilties , properties, interfaces and
relationships and interaction between them.
• It represents the overall structure of the system is choosen but the internal
details of major components are ignored.
It includes:

-Decomposition of the system into major.

-Allocation of functional responsibilities to components.
-Component interfaces.
-Communication and interaction between components.
-Components properties, reliability properties
 Contd..
The goal of architecture design is to establish the overall structure
of software system.
It considers two aspects
--Structure of data
---Hierarchical structure of the software components.
 Contd..
• The objective of architecture design is also to control relationship between
modules.
• One module may control another module or may be controlled by another
module , these characterstics are defined by : fan in and fan out of
particular module
• The number of level of component in the structure is called depth and
number of components across the horizontal section is called width.
 Contd..

• Fan in- how many modules directly invoke a given

module (number of incoming edges to a component)
• Fan out- It measures number of modules controlled
by given module(Number of out going edges)
For a good design fan out should be low as high fan out
leads to low cohesion
 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

5
6
 Software Design approaches
Generic approaches for software designing:

• Top Down Approach

• Bottom up Approach
• Hybrid Approach
 Top-Down Design

• Top-down design takes the whole software system as one entity and
then decomposes it to achieve more than one sub-system or
component based on some characteristics. Each sub-system or
component is then treated as a system and decomposed further. This
process keeps on running until the lowest level of system in the top-
down hierarchy is achieved.

• Top-down design starts with a generalized model of system and

keeps on defining the more specific part of it. When all components
are composed the whole system comes into existence.
• Top-down design is more suitable when the software solution
needs to be designed from scratch and specific details are
unknown.

58
 Bottom-Up Design

• The bottom up design model starts with most specific and basic
components. It proceeds with composing higher level of
components by using basic or lower level components. It keeps
creating higher level components until the desired system is not
evolved as one single component. With each higher level, the
amount of abstraction is increased.

• Bottom-up strategy is more suitable when a system needs to

be created from some existing system, where the basic
primitives can be used in the newer system.
 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.
 Strategies of Design

• In function oriented design strategy , System is

looked upon something , that performs set of
functions.
• This design mechanism divides the whole system into smaller
functions, which provides means of abstraction by concealing the
information and their operation. These functional modules can share
information among themselves by means of information passing and
using information available globally
 Contd..

• Another characteristic of functions is that when a

program calls a function, the function changes the state
of the program, which sometimes is not acceptable by
other modules.
• Function oriented design works well where the system
state does not matter and program/functions work on
input rather than on a state.
 Object Oriented design
Object oriented design works around the entities and their characteristics
instead of functions involved in the software system.
This design strategies focuses on entities and its characteristics. The whole
concept of software solution revolves around the engaged entities.
important concepts of Object Oriented Design as follows :
• Objects - All entities involved in the solution design are known as objects.
For example, person, banks, company and customers are treated as
objects. Every entity has some attributes associated to it and has some
methods to perform on the attributes.
• Classes - A class is a generalized description of an object. An object is an
instance of a class. Class defines all the attributes, which an object can
have and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities
are defined by means of methods or procedures.
 Contd.

• Encapsulation - In OOD, the attributes (data variables) and methods

(operation on the data) are bundled together is called encapsulation.
Encapsulation not only bundles important information of an object together,
but also restricts access of the data and methods from the outside world. This
is called information hiding.
• Inheritance - OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of
OOD is known as inheritance. This makes it easier to define specific class and
to create generalized classes from specific ones.
• Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing tasks
for different types. Depending upon how the function is invoked, respective
portion of the code gets executed.
 Design Notations

• DFDs
• Data dictionaries
• Structural charts
• Pseaducode
 Structure Chart
It is one of the method used for system design.
It partition a system into block boxes. A black box means
that functionality is known to the user without the knowledge of
internal design.
Inputs are given to blackbox and appropriate outputs are
generated by black box.

66
Structure chart notations

67
 Hierarchical format of a structure chart
-
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

69
In this 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.

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

Update file
71
 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.

72