Swami Keshvanand Institute of Technology,

Management & Gramothan, Jaipur

II Year- III Semester: B.Tech. CSE

Session: 2024-25

Software Engineering

Dr. Arpita Sharma

Assistant 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 Software Design

SRS (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)
Requirement
Analysis and SRS
Specification
More Requirements

Integration Design process

and Design involve:-
deployment Diversification
and convergence

Module Testing

Testing Quality
Design Models

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

• Basic design principles enable the software engineer to

navigate the design process.

Design consistency and uniformity are important 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 (Outer view of the system)
• Modularity (Divide system in sub-system or modules)
• Software Architecture (Organize the system modules)
• Design Patterns (Repeating design or patterns)
• Functional Independence (Multiple function should be indep.)
• Information Hiding (Hiding information for unauthorized user)
• Refinement (Remove impurities)
• Refactoring (Reconstruct something)
• Object Oriented Design Concept
Activity During Design Phase
• Modularity
that is, software is divided into separately
• Interface among different modules,
data items exchanged among different
modules,
• Control relationship among the modules
call relationship or invocation relationship
• Data structures of individual modules,
• Algorithms for individual modules.
 Module Structure
• “Module” used often – usually refers to a set
of or 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.
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.
Module Structure
Fan out=2

Fan out=1
Fan in=1

Fan in=2
Fan out=0
Data architectural and
Procedural design

55
 Data Architectural
Different high-level facets of a software design can be
described and documented. These facets are often
called views: “A view represents a partial aspect of a
software architecture that shows specific properties
of a software system. for example, the logical view
(satisfying the functional requirements) vs. the
process view (concurrency issues) vs. the physical
view (distribution issues) vs. the development view
(how the design is broken down into implementation
units with explicit representation of the
dependencies among the units). Various authors use
different terminologies-like behavioral vs. functional
vs. structural vs. data modeling views. In summary, a
software design is a multifaceted artifact produced by
the design process and generally composed of
relatively independent and orthogonal views.
 Data Architectural
Architectural Styles: An architectural style is “a
specialization of element and relation types. An
architectural style can thus be seen as providing the
software’s high-level organization. Various authors have
identified a number of major architectural styles:
General structures (for example, layers, pipes and filters,
blackboard)
Distributed systems (for example, client-server,
three-tiers, broker)
Interactive systems (for example,
Model-View-Controller,
Presentation-Abstraction-Control)
Adaptable systems (for example, microkernel, reflection)
Architectural Design

58
59
60
Procedural design

61
 Procedural Design
Procedural design is an essential part of the
software design process. User interface design
should ensure that interaction between the
human and the machine provides for effective
operation and control of the machine.
For software to achieve its full potential, the user
interface should be designed to match the skills,
experience, and expectations of its anticipated
users.
 Procedural Design
General User Interface Design Principles:-
Learnability: The software should be easy to learn
so that the user can rapidly start working with the
software.
User familiarity: The interface should use terms
and concepts drawn from the experiences of the
people who will use the software.
Consistency: The interface should be consistent so
that comparable operations are activated in the
same way.
 Procedural Design
Minimal surprise: The behavior of software should
not surprise users.
Recoverability: The interface should provide
mechanisms allowing users to recover from errors.
User guidance: The interface should give
meaningful feedback when errors occur and
provide context-related help to users.
User diversity: The interface should provide
appropriate interaction mechanisms for diverse
types of users and for users with different
capabilities
Design Documentation

65
 Design Documentation
• Information presentation may be textual or graphical in
nature. A good design keeps the information
presentation separate from the information itself.
• The MVC (Model-View-Controller) approach is an
effective way to keep information presentation
separating from the information being presented.
• Software Design Software engineers also consider
software response time and feedback in the design of
information presentation. Abstract visualizations can be
used when large amounts of information are to be
presented.
• According to the style of information presentation,
designers can also use color to enhance the interface.
 Design Documentation
There are several important guidelines:
Limit the number of colors used.
Use color change to show the change of software
status.
Use color-coding to support the user’s task.
Use color-coding in a thoughtful and consistent
way.
Use colors to facilitate access for people with color
blindness or color deficiency (e.g., use the change
of color saturation and color brightness, try to
avoid blue and red combinations).
THANK YOU

68