Swami Keshvanand Institute of Technology,

Management & Gramothan, Jaipur

II Year- III Semester: B.Tech. CSE(DS)

Session: 2023-24

Software Engineering

Kailash Soni
Associate Professor(CSE)
1
Software Engineering
Syllabus

2
 Unit-IV

Software Design:
• Introduction,
• Design fundamentals.
Effective modular design:
• Data architectural and procedural design,
• Design documentation.
3
 Contents
• OVERVIEW
• DESIGN PROCESS
• DESIGN CONCEPTS
 Abstraction
 Refinement
 Modularity
 Software Architecture
 Control Hierarchy
 Structural Partitioning
 Data Structure
 Software Procedure
 Information Hiding
 Overview
The main aim of design engineering is to generate a
model which shows resolution, delight and service to
customer.

• Software design is an iterative process through which

requirements are translated into the blueprint for building
the software.

• Design is highly creative stage in software development

where the designer plans how the system or program
should meet the customer’s needs and how to make
system effective and efficient.
 Software Design

• Design is the creative process of applying various

techniques and principals for the purpose by which
requirements are translating into a “blueprint” for
constructing a device, a process or a system in
sufficient detail to permit its realization.

Design Process
SRS Software Design
(create holistic view
(Problem Domain) (Solution Domain)
of software)
Software Design Process
(Problem Solving Activity )
• Software designing is more creative than analysis.

Feasibility study (initial requirements)

Requirement Analysis and Specification

Validate the Obtain the
design with Solution
customer Domain
High Level Design

Refine and Document the design

 Design Process
Any design problems must be tackled in three
stages…

• Study and understand the problem.

• Identify gross features of at least one possible
solution.
• Describe each abstraction used in the solution.

Informal Informal Finished

Formal Design
Design Outline Design Design
Fig:- Design Process
 Design Process
Software designers do not arrive at a finished design
immediately.
• They develop design iteratively through number of different
versions.
• The starting point is informal design which is refined by
adding information to make it consistent and complete.
Activities necessary for architectural designing.....
• System Structuring (Decomposition of main system into many
subsystem)
• Control Modeling (To identify control relationships among parts
of system:-entity)
• Modular Decomposition (Decomposing the system into
modules)
Software Design Process
Problem Domain(Requirements)

SRS
More Requirements

Design process
involve:-
Diversification
and convergence

Module Testing

Design Models

Software Development Process

 DESIGN CONCEPTS
A set of fundamental software design concepts has evolved over
the past four decades. Each provides the software designer
with a foundation from which more sophisticated design
methods can be applied.

As part of the software design we should consider quality factors.

• Functionality :- feature set and program capabilities
• Usability:- human factors (aesthetics, consistency, documentation)
• Supportability:- maintainability (extensibility, adaptability,
serviceability), testability, compatibility, configurability.
• Reliability – frequency and severity of failure
• Performance – processing speed, response time, throughput,
efficiency
 Software Design Specification
Modules
The flow of information during software design is
Software requirements, manifested by the data,
functional, behavioral models, feed the design
task.

Using one of a number of design methods the design

task produces a data design, an architectural
design, an interface design, and a component
design.
SOFTWARE DESIGN MODELS

Fig:- Translating the Analysis Process into Software Process

 Design Specification Modules
• Data Design:-
It transforms the information domain model into the data structures that will be
required to implement the software.

The entity relationship diagram and the detailed data content depicted in the
data dictionary provide the basis for the data design activity.

• Architectural Design:-
It defines the relationship between major structural elements of the software,
the “design patterns” that can be used to achieve the requirements that have
been defined for the system.

The architectural design representation—the framework of a computer-based

system—can be derived from the system specification, the analysis model,
and the interaction of subsystems defined within the analysis model.
 Design Specification Modules
• Interface Design:-
It describes how the software communicates within itself, with systems
that interoperate with it, and with humans who use it. Data and
control flow diagrams provide much of the information required for
interface design.

• Component-level Design :-
It transforms structural elements of the software architecture into a
procedural description of software components. Information
obtained from the PSPEC, CSPEC, and STD serve as the basis for
component design.
The importance of software design can be stated with a single word
“quality”.
Software Design Process have two part of design:-
• Conceptual Design (Customer)
• Technical Design (System Designers)

What How

Software Design
Document(SDD)
Conceptual design of software:
• Written in simple language i.e. customer
understandable language.
• Detail explanation about system characteristics.
• Describes the functionality of the system.
• It is independent of implementation.
• Linked with requirement document.
Technical Design of software:

• Hardware component and design.

• Functionality and hierarchy of software component.
• Software architecture
• Network architecture
• Data structure and flow of data.
• I/O component of the system.
• Shows interface.
 DESIGN PRINCIPLES
• Software design is both a process and a model. Its goal is to satisfy
the requirement of the customer.

• The design process is a sequence of steps that enable the designer

to describe all aspects of the software to be built.

• It is a Creative skill, past experience, a sense of what makes “good”

software, and an overall commitment to quality are critical success
factors for a competent design.

• Basic design principles enable the software engineer to navigate the

design process.

Design consistency and uniformity are crucial when large systems are
to be built. A set of design rules should be established for the
software team before work begins.
 DESIGN PRINCIPLES
Davis suggests a set1 of principles for software design, which
have been adapted and extended in the following list:

• The design process should not suffer from “tunnel

vision.”

• The design should be traceable to the analysis model.

• The design should not reinvent the wheel.

• The design should “minimize the intellectual distance”

between the software and the problem as it exists in
the real world.

• The design should exhibit uniformity and integration.

 DESIGN PRINCIPLES
• The design should be structured to accommodate change.

• The design should be structured to degrade gently, even

when aberrant data, events, or operating conditions are
encountered.

• Design is not coding, coding is not design.

• The design should be assessed for quality as it is being

created, not after the fact.

• The design should be reviewed to minimize conceptual

(semantic) errors.

When these design principals are properly applied, the software

engineer creates a design of good quality of software.
 DESIGN CONCEPT/
FUNDAMENTALS
The set of fundamental software design concepts are
as follows:
• Abstraction
• Refinement
• Modularity
• Software Architecture
• Control Hierarchy
• Structural Partitioning
• Data Structure
• Software Procedure
• Information Hiding
 Software Design
“Effective Modular Design”

24
 Activity During Design Phase
• Modularity
that is, software is divided into separately
• Control relationship among the modules
call relationship or invocation relationship
• Interface among different modules,
data items exchanged among different
modules,
• Data structures of individual modules,
• Algorithms for individual modules.
 Module Structure
• “Module” used often – usually refers to a
method or class.

Module-1

Module-2 Module-3

Module-4 Module-5 Module-6

 Module Structure
A module consists of:-several functions
and associated data structures.
D1…
DATA
D2…
D3…
Dn…

F1…
F2… Functions
F3…
F4…
Fn…
 Good and bad designs
• There is no unique way to design a system.

• Even using the same design methodology

because different engineers can arrive at
very different design solutions.

• We need to distinguish between good and

bad designs.
 Modularity
• Modularity is a fundamental attributes
of any good design.
– Decomposition of a problem cleanly into
modules:
– Modules are almost independent of each
other
– divide and conquer principle.
 Modularity
• If modules are independent:
– modules can be understood separately,
• reduces the complexity greatly.
– To understand why this is so,
• remember that it is very difficult to break a
bunch of sticks but very easy to break the
sticks individually.
Example of Cleanly and Non-cleanly
Decomposed Modules
 Modularity
• In technical terms, modules should
display:
– high cohesion (Inter connection b/w the
elements of software modules)
– low coupling (Degree of interdependence
b/w Software modules)
• We will shortly discuss:
– cohesion and coupling.
 Cohesion and Coupling
• Cohesion is a measure of:
– functional strength of a module.
– A cohesive module performs a single task
or function.
• Coupling between two modules:
– a measure of the degree of
interdependence or interaction between
the two modules.
 Cohesion and Coupling
• A module having high cohesion and
low coupling:
–functionally independent of other
modules:
• A functionally independent module has
minimal interaction with other
modules.
Advantages of Functional Independence

• Better understandability and good

design:
• Complexity of design is reduced,
• Different modules easily understood in
isolation:
– modules are independent
Advantages of Functional Independence

• Functional independence reduces error

propagation.
– degree of interaction between modules is
low.
– an error existing in one module does not
directly affect other modules.
• Reuse of modules is possible.
Advantages of Functional Independence

• A functionally independent module:

– can be easily taken out and reused in a
different program.
• each module does some well-defined and
precise function
• the interfaces of a module with other
modules is simple and minimal.
 Functional Independence

• Unfortunately, there are no ways:

– to quantitatively measure the degree
of cohesion and coupling:
– classification of different kinds of
cohesion and coupling:
• will give us some idea regarding the degree
of cohesiveness of a module.
 Classification of Cohesiveness

• Classification is often subjective:

– yet gives us some idea about
cohesiveness of a module.
• By examining the type of cohesion
exhibited by a module:
– we can roughly tell whether it displays
high cohesion or low cohesion.
Classification of Cohesiveness
functional
sequential
communicational Degree of
procedural cohesion

temporal
logical
coincidental
 Coincidental cohesion

• The module performs a set of tasks:

– which relate to each other very loosely, if
at all.
• the module contains a random collection of
functions.
• functions have been put in the module out of
pure coincidence without any thought or
design.
 Logical cohesion
• All elements of the module perform
similar operations:
– e.g. error handling, data input, data
output, etc.
• An example of logical cohesion:
– a set of print functions to generate an
output report arranged into a single
module.
 Temporal cohesion
• The module contains tasks that are related
by the fact:
– all the tasks must be executed in the same time
span.
• Example:
– The set of functions responsible for
• initialization,
• start-up, shut-down of some process, etc.
 Procedural cohesion
• The set of functions of the module:
–all part of a procedure (algorithm)
–certain sequence of steps have to be
carried out in a certain order for
achieving an objective,
• e.g. the algorithm for decoding a message.
 Communicational cohesion

• All functions of the module:

–reference or update the same data
structure,
• Example:
–the set of functions defined on an
array or a stack.
 Sequential cohesion

• Elements of a module form

different parts of a sequence,
–output from one element of the
sequence is input to the next.
– Example:
sort

search

display
 Functional cohesion
• Different elements of a module
cooperate:
–to achieve a single function,
–e.g. managing an employee's pay-
roll.
• When a module displays functional
cohesion,
–we can describe the function using a
single sentence.
 Coupling
• Coupling indicates:
–how closely two modules interact or
how interdependent they are.
–The degree of coupling between two
modules depends on their interface
complexity.
 Coupling
• There are no ways to precisely determine
coupling between two modules:
– classification of different types of coupling will
help us to approximately estimate the degree of
coupling between two modules.
• Five types of coupling can exist between any
two modules.
Classes of coupling

data
stamp
control Degree of
coupling
common
content
 Data coupling
• Two modules are data coupled,
–if they communicate via a parameter:
• an elementary data item,
• e.g an integer, a float, a character, etc.
– The data item should be problem related:
• not used for control purpose.
 Stamp coupling
• Two modules are stamp coupled,
–if they communicate via a composite
data item
• such as a record in PASCAL
• or a structure in C.
 Control coupling
• Data from one module is used to
direct
–order of instruction execution in
another.
• Example of control coupling:
–a flag set in one module and tested in
another module.
 Common Coupling
• Two modules are common
coupled,
–if they share some global data.
 Content coupling
• Content coupling exists between two
modules:
– if they share code,
– e.g, branching from one module into
another module.
• The degree of coupling increases
– from data coupling to content coupling.
Characteristics of Module Structure
• Depth:
– number of levels of control
• Width:
– overall span of control.
• Fan-out:
– a measure of the number of modules
directly controlled by given module.
Characteristics of Module Structure

• Fan-in:
–indicates how many modules
directly invoke a given module.
–High fan-in represents code reuse
and is in general encouraged.
Module Structure
Fan out=2

Fan out=1
Fan in=1

Fan in=2
Fan out=0
Software Design Methods:
Data Architecture &
Procedural Design

59
THANK YOU

60