UNIT III : Software Design

Software Design
 Software design is an iterative process during which the
software requirements specified in SRS are analyzed and
converted into description of the internal structure and
organization of the system.

 The document thus produced is called the software

design specification document and serves as the basis for
construction of the software.

 Design Process for software system has two levels:

1.Software Architectural Design or High Level Design :
In this system is decomposed and organized into high level
components or modules and the interfaces between these
components are also described.
2.Software Implementation or Detailed Design : In it,
each component is described in sufficient detail so that it can
be easily coded by the programmers.
 Goal of Design Process
 The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.

 The design must be a readable, understandable guide

for those who generate code and for those who test and
subsequently support the software.

 The design should provide a complete picture of the

software, addressing the data, functional, and
behavioral domains from an implementation perspective.
Characteristics of good design
1. A design should exhibit an architecture that is been created using
recognizable architectural styles or patterns.

2. A design should be modular; that is, the software should be

logically partitioned into elements or subsystems

3. A design should contain distinct representations of data,

architecture, interfaces, and components.

4. A design should lead to data structures that are appropriate for

the classes to be implemented and are drawn from recognizable
data patterns.

5. A design should lead to components that exhibit independent

functional characteristics
Characteristics of good design
6. A design should lead to interfaces that reduce the
complexity of connections between components and
with the external environment.

7. A design should be derived using a repeatable

method that is driven by information obtained during
software requirements analysis.

8. A design should be represented using a notation that

effectively communicates its meaning.
 Design Framework
 Design Framework starts with the initial
requirements and ends up with the final
design
 Data is gathered on user requirements
and analyzed accordingly.
 Design is refined in every cycle and finally
it is documented to produce software
design document.
 Design Framework
Initial
Requirements

Gather Data on User

Requirement

Analyze the Requirements

Data
Validate the Design Obtain Answers to
against Requirements
Requirements Questions

Conceive of a High – level

Design

Refine and Document the

Design

Complete
Design
 Design Principles
1. The design process should not suffer from ‘tunnel vision” -
Designer should consider alternative approaches.

2. The design should be traceable to the analysis model - a single

element of the design model often traces to multiple requirements,
it is necessary to have a means for tracking how requirements
have been satisfied by the design model.

3. The design should not reinvent the wheel - use already exists
design pattern because time is short and resource are limited.

4. The design should “minimize the intellectual distance” between

the software and the problem as it exists in the real world. –
design should be self-explanatory
 Design Principles
5. The design should exhibit uniformity and integration – before
design work begins rules of styles and format should be defined for a
design team.

6. The design should be structured to accommodate change

7. The design should be structured to degrade gently, even when

unusual data, events, or operating conditions are encountered.

8. Design is not coding, coding is not design.

9. The design should be assessed for quality as it is being created, not

after the fact

10. The design should be reviewed to minimize conceptual (semantic)

errors.
Architectural Design
 The initial design process of identifying the subsystems
and establishing a framework for subsystem control and
communication is called architectural design.
 It represents the structure of data and program
components that are required to build a computer
based system.
 It considers the architectural style that the system will
take, the structure and properties of the components
that constitute the system, and the interrelationships
that occur among all architectural components of a
system.
Architectural Design
 Alternate architectural styles of designing a system are:

1. Data Centric Architecture : involves the use of central database

operations of inserting, updating it in the form of a table.
2. Data Flow Architecture : It is applied when input data takes the
form of output after passing through various phases of
transformations.
3. Object – Oriented Architecture : moves around the classes and
objects of the system
4. Layered Architecture : Defines a number of layers and each layer
performs tasks.
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.
 Properties of modular system are :
1. Each function has a single well defined purpose.
2. Each function manipulates no more than one major data structure.
3. Functions share global data selectively.
4. Functions that manipulate instances of abstract data types are
encapsulated with the data structure being manipulated.
Low Level Design
 Advantages of modular system are :
1. Easier to understand and explain.
2. Easier to document.
3. Programming individual modules is easier.
4. Testing and debugging individual modules is easier.
5. Bugs are easier to isolate and understand, and they can
be fixed without fear of introducing problems outside the
module.
Low Level Design
 Modularity
 Software is divided into separately named and
addressable components, called modules, which are
integrated to satisfy problem requirement.

 Modularity is the single attribute of software that allows a

program to be intellectually manageable

 It leads to a “divide and conquer” strategy. – it is easier

to solve a complex problem when you break into a
manageable pieces.
Low Level Design
 Modularity
 Modules created during program modularization are:
1. Process Support Modules : In it all the functions and
data items that are required to support a particular
business process are grouped together.
2. Data Abstraction : These are abstract types that are
created by associating data with processing
components.
3. Functional Modules : In it all the function that carried
out similar or closely related tasks is grouped together.
4. Hardware Modules : In it all the functions, which
controls on particular hardware are grouped together.
Flow Chart v/s Structure Chart
Flow chart is a convenient technique to represent the
flow of control in a program. A structure chart differs
from a flow chart in three principal ways:
1.It is usually difficult to identify the different
modules of the software from its flow chart
representation.
2.Data interchange among different modules is
not represented in a flow chart.
3.Sequential ordering of tasks inherent in a flow
chart is suppressed in a structure chart.
Pseudocode
•Itis a combination of algorithm written in
simple language and programming language
statements.

•Pseudo-code notation can be used in both the

preliminary and detailed design phases.

•UsingPseudo-code, the designer describes system

characteristics structured by keywords such as IF –
THEN – ELSE, While – Do and End.
Pseudocode Example
Find smallest number among three variables

1.Read values of a, b and c

2.If (a<b)
{
if (a<c)
print “ a is smallest “
Else
print “ c is smallest “
}
Else if(b<c)
print “ b is smallest “
Else
print “ c is smallest “
Pseudocode Advantages
1. Converting a pseudocode to a programming
language is much easier as compared to converting to
flowchart or decision table.

2. As compared to flowchart, it is easier to modify the

pseudocode of program logic whenever program
modifications are necessary.

3. Writing of pseudocode involves much less time and

effort than equivalent flowchart.

4. Pseudocode is easier to write than writing a

program in a programming language because it has
only a few rules to follow.
Pseudocode Disadvantages
1. In case of Pseudocode, a graphic representation of
program logic is not available as in flowcharts.

2. No standard rules to follow in using Pseudocode.

Different programmers use their own style of writing
pseudocode hence communication problems occur due to
lack of standardization.

3. For a beginner, it is more difficult to follow the logic or

write the Pseudocode, as compared to flowcharting.
Function Oriented Design
 It is an approach to software design where the design is
decomposed into a set of interacting units where each
unit has a clearly defined function.
 It is the result of focusing attention to the function of the
program.
 In it, the design can be represented graphically or
mathematically by the following:
1. Data flow diagrams
2. Data Dictionaries
3. Structure Charts
4. Pseudocode
Difference
Sr.no. Functional – oriented Object - oriented
1 Basic abstractions are real world Basic abstractions are the data
functions, such as sort, merge, abstractions where the real world
track, display etc. entities are customer, students,
employee etc.
2 State information is available in a State information exists in the form
centralized shared data store. of data distributed among several
objects of the system
3 Functions are grouped together Functions are grouped together on
by which a higher level function is the basis of the data they operate
obtained on
4 Orients on functions Orients on objects
5 Functions, get some data, Objects is data with methods of
process it and then return result, processing it.
or do some actions