MODULE 4

SOFTWARE DESIGN
TABLE OF
CONTENT
01 Software Design 06 IEEE Recommended practice
for software design

02 Types of software design 07 Steps to Analyze and Design

Object Oriented System

03 Modularity 08 Capability Maturity Model

(CMM)

04 Software Design Strategies 09 Software Reliability

05 Function oriented design 10 Software Quality

SOFTWARE DESIGN
Software design is a problem-solving activity
which bridge the gap between specifications and
coding.
It is more creative than analysis as it produces a
solution to a problem given in SRS document.
Good design is always system dependent and
what is good for one system may be bad for
another.
 TYPES OF DESIGN
Design is really a two-part, iterative process.
First, we produce conceptual design that tells the
customer what the system will do in a simple
language avoiding technical terms and
implementation details.
It contains information about
source of input data
data transformations in the system
appearance of system to users and user
choices
timing of various events
screen and report format
Once the customer approves the conceptual design,
we translate it into technical design that allows system
builders to understand the actual hardware and
software needed to solve customer's problem. It
describes
Hardware configuration
Software needs
Communication interfaces
I/O of the system
Software architecture
Network architecture
Any other thing that translates the requirements in
to a solution to the customer's problem
OBJECTIVES AND IMPORTANCE OF DESIGN
01 Correctness 04 Flexibility
Software design should be correct as per Able to modify on changing needs.
requirement.

05 Consistency
02 Completeness
The design should have all components like There should not be any inconsistency in the
data structures, modules, and external design
interfaces, etc.

03 Efficiency 06 Maintainability
Resources should be used efficiently by the The design should be so simple so that it can
program be easily maintainable by other designers
 TYPES OF 01 Interface Design

SOFTWARE Interface design is the specification of the interaction

DESIGN between a system and its environment.

this phase proceeds at a high level of abstraction with

respect to the inner workings of the system i.e, during

interface design, the internal of the systems are

01 Interface Design
completely ignored and the system is treated as a black

box.
02 Architectural Design
Attention is focussed on the dialogue between the

target system and the users, devices, and other systems

03 Detailed Design
with which it interacts
 TYPES OF 02 Architectural Design

SOFTWARE Architectural design is the specification of the major

DESIGN components of a system, their responsibilities,

properties, interfaces, and the relationships and

interactions between them.

In architectural design, the overall structure of the

01 Interface Design
system is chosen, but the internal details of major

components are ignored

02 Architectural Design

03 Detailed Design
 TYPES OF 03 Detailed Design

SOFTWARE Design is the specification of the internal elements of all

DESIGN major system components, their properties,

relationships, processing, and often their algorithms and

the data structures.

The detailed design may include:  Decomposition of

01 Interface Design major system components into program units.

Allocation of functional responsibilities to units. 

02 Architectural Design
User interfaces  Data and control interaction between

units
03 Detailed Design
MODULARITY
A module is defined as the unique and addressable components of the software
which can be solved and modified independently without disturbing (or affecting in
very small amount) other modules of the software.
Thus every software design should follow modularity.
The process of breaking down software into multiple independent modules where
each module is developed separately is called Modularization
Effective modular design can be achieved if the partitioned modules are separately
solvable, modifiable as well as compliable.
INDEPENDENCE OF MODULES OF A SOFTWARE SYSTEM CAN BE MEASURED USING
2 CRITERIA: COHESION, AND COUPLING
 Coupling Cohesion

Coupling is a measure of strength in relationship Cohesion is a measure of strength in relationship

between various modules within a software. It is between various functions within a module. It is of 7

of 6 types which are listed below in the order of types which are listed below in the order of high to low
low to high coupling:
cohesion: 

1. Functional cohesion 
1. Data Coupling 2. Sequential cohesion 
2. Stamp Coupling
3. Communicational cohesion 
3. Control Coupling
4. Procedural cohesion 
4. External Coupling
5. Temporal cohesion 
5. Common Coupling
6. Logical cohesion
6. Content Coupling
7. Co-incidental cohesion
 COUPLING
Data Coupling Stamp Coupling Control Coupling
In stamp coupling, the complete
Data coupling occurs when one module passes control
data structure is passed from
modules communicate solely data (like flags or parameters)
one module to another module.
by passing data or parameters, to another module,
The data structures can include
maintaining independence determining how the second
arrays, objects, or other
from each other module should execute its
composite types that bundle
Modules do not affect each multiple pieces of information functions
other's internal workings, together. For instance, Module A might
allowing for easier Consider a scenario where a send a command to Module B
maintenance and module passes an entire user indicating whether to proceed
modifications. profile object to another module with a task or terminate the
Data is exchanged through that only needs the user's name. operation based on certain
parameters in function calls or This exemplifies stamp coupling, conditions
global variables as the receiving module does not
utilize all the information
provided.
 COUPLING
External Coupling Common Coupling Content Coupling
In external coupling, the Common coupling occurs when This type of coupling allows
modules depend on other multiple modules access and one module to directly
modules manipulate the same global data. manipulate the content of
It arises when two or more This means that changes made to another, which can include
modules share dependencies the shared data can affect all accessing private variables or
on external entities, including modules that rely on it. altering the execution flow
When global data is modified,
data formats, protocols, or This is the worst form of
developers must trace back
hardware interfaces coupling and should be
through all modules that access
avoided
this data to evaluate the potential
This type of coupling allows
effects of the change.
one module to directly
This can complicate maintenance
and increase the risk of manipulate the content of
introducing bugs. another, which can include
accessing private variables or
altering the execution flow
 COHESION
Functional cohesion Sequential Cohesion

Functional cohesion occurs when all Data flow refers to the movement of
elements within a module contribute data between different components or
to a single, specific function or task. modules within a system, where the
All components in a functionally output from one element becomes the
cohesive module are closely related input for another
and directly contribute to achieving the Modules operate independently,
focusing on their specific tasks while
same objective, enhancing clarity and
relying on data passed between them,
purpose.
which enhances modularity and
A module that handles user
reusability.
authentication (e.g., login, logout,
Each module performing specific
password management) demonstrates
operations on the data it receives.
functional cohesion as all its functions
are related to user authentication.
 COHESION
Communicational Cohesion Procedural Cohesion

When multiple elements or modules Procedural cohesion groups elements in

share the same input data or work a module because they follow a specific
towards producing a common output, order of execution
they exhibit a form of cohesion that An example is calculating a student's
indicates their interdependence. GPA, printing the student record,
An example of this would be a system calculating the cumulative GPA, and then
printing the cumulative GPA
where one module updates a record in
For activities to be related under
a database while another module sends
procedural cohesion, they must be
that updated record to a printer. Both
connected in a specific sequence
modules rely on the same input data
(the record) and contribute to the same
output (the printed document).
 COHESION
Temporal Cohesion Logical Cohesion

Logical cohesion happens when different

Temporal cohesion occurs when tasks parts of a module are grouped together
within a module are related by the timing because they serve a similar purpose or
of their execution, meaning they must all category, despite performing distinct
be performed within the same time span. functions.
Temporal cohesion occurs when tasks A module that handles various input
within a module are related by the timing of methods (e.g., keyboard input, mouse
their execution, meaning they must all be
input, and file input) demonstrates logical
performed within the same time span.
cohesion. Each function serves a different
Temporal cohesion is commonly found in
purpose but is logically related to the
modules responsible for system startup or
overall task of data input.
shutdown processes, where multiple
actions must occur together to prepare or
terminate system operations.
 COHESION
Coincidental Cohesion A good
Coincidental cohesion occurs when the software
elements within a module are grouped
arbitrarily, with no meaningful relationship
design
between them. The only commonality is requires
their location in the source code.
An example of coincidental cohesion might high
be a module that includes various
unrelated functions such as logging errors,
cohesion
calculating taxes, and generating reports, and low
all bundled together without a clear
purpose. coupling.
STRATEGY OF BOTTOM-UP APPROACH
DESIGN
The bottom-up design starts with the lowest-level
components and subsystems.
There are many strategies or
techniques for performing Higher-level components are created by composing
these lower-level elements.
system design.
They are: This process continues until all components form a
Bottom-up approach complete system.

Top-down approach
As design progresses, the level of abstraction increases.
Hybrid approach

The bottom-up strategy is ideal for creating new

systems based on existing information.
BOTTOM-UP APPROACH
STRATEGY OF TOP-DOWN APPROACH
DESIGN
Each subsystem is further divided into smaller
subsystems
There are many strategies or
techniques for performing Each subsystem is further divided into smaller
subsystems and components.
system design.
They are: This division creates a clear system hierarchy for better
Bottom-up approach management.

Top-down approach
Design starts by defining the entire system, then adds
Hybrid approach definitions for subsystems and components.

Design starts by defining the entire system, then adds

definitions for subsystems and components.
TOP-DOWN APPROACH
STRATEGY OF HYBRID APPROACH
DESIGN
Hybrid design is a combination of both
There are many strategies or the top–down and bottom–up design
techniques for performing strategies.
system design.
In this we can reuse the modules.
They are:
Bottom-up approach
Top-down approach
Hybrid approach
FUNCTION Design Notations
ORIENTED
DESIGN For a functionoriented design, the design can
be represented graphically or mathematically
Function Oriented design is a by the following:
method to software design where
the model is decomposed into a
set of interacting units or modules
where each unit or module has a
clearly defined function.
DATA FLOW DIAGRAM(DFD)
Data-flow diagrams are a useful way of describing a system.
They are generally understandable without specialized training.
DATA DICTIONARIES
A Data dictionary provides a standard language for all relevant information for use
by engineers working in a project.
The data dictionary provides the analyst with a means to determine the definition
of various data structures in terms of their component elements.
STRUCTURED CHARTS
It partitions a system into black boxes.
In a Black box system , its functionality is known to the user without the knowledge
of internal design.
Structured Chart is a graphical representation which shows:
System partitions into modules
Hierarchy of component modules
The relation between processing modules
Interaction between modules
Information passed between modules
SYMBOLS USED IN STRUCTURE CHART
PSEUDO-CODE
Pseudo-code notations can be used in both the preliminary and detailed design
phases.
Using pseudo-code, the designer describes system characteristics using short,
concise, English Language phrases that are structured by keywords such as If-
Then-Else, While-Do, and End.
Start
Initialize variables
Read the variables
Execution
Display
stop
IEEE RECOMMENDED PRACTICE DEFINITIONS :
FOR SOFTWARE DESIGN Few important definitions are given below:
DESCRIPTIONS (SDD)
(IEEE STD 1016-1998) Design entity: An element (Component) of a design
that is structurally and functionally distinct from
other elements and that is separately named and
Scope
referenced.
An SDD is a representation
Design View: A subset of design entity attribute
of a software system that information that is specifically suited to the needs
is used as a medium for of a software project activity.
communicating software Entity attributes: A named property or
design information. characteristics of a design entity. It provides a
This is a recommended statement of fact about the entity.

practice for describing Software design description (SDD): A

software designs representation of a software system created to
facilitate analysis, planning, implementation and
decision making
CONSIDERATIONS This clause provides information to be considered
FOR PRODUCING AN
SDD before producing an SDD.
How the SDD fits into the software life cycle, where it
fits, and why it is used are discussed.
4.1 Software life cycle
4.2 SDD within the life cycle
4.3 Purpose of an SDD
4.1 SOFTWARE LIFE CYCLE DEFINITIONS :
The life cycle approach is an effective
engineering management tool and provides a
model for a context within which to discuss the
The life cycle of a software preparation and use of the SDD.
While it is beyond the scope of this document
system is normally defined
to prescribe a particular standard life cycle, a
as the period of time that typical cycle will be used to define such a
starts when a software context for the SDD.
product is conceived and This cycle is based on IEEE Std 610.12-1990 and
ends when the product is consists of a concept phase, requirements
phase, design phase, implementation phase,
no longer available for use.
test phase, installation and checkout phase,
operation and maintenance phase, and
retirement phase
4.2 SDD WITHIN THE LIFE CYCLE DEFINITIONS :

For both new software systems and existing

systems under maintenance, it is important to
ensure that the design and implementation
used for a software system satisfy the
requirements driving that system.
The minimum documentation required to do
this is defined in IEEE Std 730-1998.
The SDD is one of these required products.
It records the result of the design processes
that are carried out during the design phase
4.3 PURPOSE OF AN SDD DEFINITIONS :

The SDD shows how the software system will

be structured to satisfy the requirements
identified in the SRS.
It is basically the translation of requirements
into a description of the software structure,
software components, interfaces, and data
necessary for the implementation phase.
Hence, SDD becomes the blue print for the
implementation activity.
 Introduction: SDD is a model of the system.
DESIGN Design entities
DESCRIPTION Design entity attributes
INFORMATION Identification: The unique name of the entity.
CONTENT Type: A description of type of entity such as
module, process or data store.
Purpose: A description of why entity exists.
Function: A statement of what the entity
does.
Subordinates: The composition of all entities
composing a particular entity.
Dependencies: Description of relationship
between entities
ORGANIZATION OF
SDD
STEPS TO 1. Define the use case model.
2. During the systems analysis phase, begin
ANALYZE drawing UML diagrams.
3. Continuing in the analysis phase, develop class
AND DESIGN diagrams.
OBJECTED 4. Still in the analysis phase, draw statechart
diagrams.
ORIENTED 5. Begin systems design by modifying the UML
diagrams.
SYSTEM
6. Develop and document the system.
1. DEFINE THE USE CASE MODEL. DEFINITIONS :

In this phase the analyst identifies the actors

and the major events initiated by the actors.
Symbols used in usecase diagram Often the analyst will start by drawing a
diagram with stick figures representing the
actors and arrows showing how the actors
relate.
This technique combines text and pictures to
provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system
and not ‘how’.
2. DURING THE SYSTEMS DEFINITIONS :
ANALYSIS PHASE, BEGIN
DRAWING UML DIAGRAMS.
In the second phase the analyst will draw Activity
Diagrams, which illustrate all the major activities in
Example the use case.
In addition, the analyst will create one or more
sequence diagrams for each use case, which show
the sequence of activities and their timing. 
Activity diagram is another important diagram in
UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent
the flow from one activity to another activity.
The activity can be described as an operation of the
system.
2. DURING THE SYSTEMS ANALYSIS
DEFINITIONS :
PHASE, BEGIN DRAWING UML (UNIFIED
MODELING LANGUAGE (UML) DIAGRAMS.
In the second phase the analyst will draw Activity
Diagrams, which illustrate all the major activities in
Example the use case.
In addition, the analyst will create one or more
sequence diagrams for each use case, which show
the sequence of activities and their timing. 
Activity diagram is another important diagram in
UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent
the flow from one activity to another activity.
The activity can be described as an operation of the
system.
3. CONTINUING IN THE ANALYSIS PHASE,
DEFINITIONS :
DEVELOP CLASS DIAGRAMS.

Class diagrams are the main building block of any

object-oriented solution.
It shows the classes in a system, attributes, and
operations of each class and the relationship
between each class.
In most modelling tools, a class has three parts.
Name at the top, attributes in the middle and
operations or methods at the bottom.
4. STILL IN THE ANALYSIS PHASE, DRAW
DEFINITIONS :
STATECHART DIAGRAMS.

The state chart diagrams are extremely useful in

modifying class diagrams, so the iterative process of
UML modeling continues.
A state machine diagram is used to model the
dynamic behavior of a class in response to time and
changing external stimuli( eventS that causes system
to changes its state from one to another).
We can say that each and every class has a state but
we don’t model every class using State Machine
diagrams.
6. DEVELOP AND DOCUMENT THE DEFINITIONS :
SYSTEM.
The more complete the information you provide the
development team through documentation and UML
diagrams, the faster the development and the more
solid the final production system.
SOFTWARE Software Reliability means Operational reliability.
It is described as the ability of a system or
RELIABILITY
component to perform its required functions
under static conditions for a specific period.
Software reliability is also defined as the
probability that a software system fulfils
its assigned task .
SOFTWARE Software quality product is defined in term
of its fitness of purpose.
QUALITY
That is, a quality product does precisely
what the users want it to do.
For software products, the fitness of use is
generally explained in terms of satisfaction
of the requirements laid down in the SRS
document.
 McCall software quality model was introduced in
1977.
MC CALL’S This model is incorporated with many attributes,
SOFTWARE QUALITY termed as software factors, which influence software.
The model distinguishes between two levels of
MODEL
quality attributes:
Quality Factors
Quality Criteria
 The software quality factors are organised in three
QUALITY FACTORS
product quality factors are shown below

Product Operation

Product Revision

Product Transition
 Factors which are related to the operation of a
PRODUCT
product are combined and are given below.
OPERATION
Correctness: The extent to which a software

meets its specifications.

Efficiency: The amount of computing

resources and code required by software to

perform a function.

Integrity: The extent to which access to

software or data by the unauthorized

persons can be controlled.

 Reliability: The extent to which a software
PRODUCT
performs its intended functions without
OPERATION
failure.

Usability: The extent of effort required to

learn, operate and understand the functions

of the software.
 The factors which are required for testing &

maintenance are combined and are given

PRODUCT REVISION
below:

Maintainability: The effort required to

locate and fix an error during maintenance

phase.

Flexibility: The effort required to modify an

operational program.

Testability: The effort required to test a

software to ensure that it performs its

intended function
 We may have to transfer a product from one

platform to an other platform or from one

PRODUCT technology to another technology.
TRANSITION The factors related to such a transfer are

combined and given below:

Portability: The effort required to transfer a

program from one platform to another

platform.

Reusability: The extent to which a program

can be reused in other applications.

Interoperability: The effort required to

couple one system with another

 The Capability Maturity Model (CMM) is a tool used
to improve and refine software development
CAPABILITY processes.
MATURITY It provides a structured way for organizations to
assess their current practices and identify areas for
MODEL
improvement.
(CMM) CMM consists of five maturity levels: initial,
repeatable, defined, managed, and optimizing.
By following the CMM, organizations can
systematically improve their software development
processes, leading to higher-quality products and
more efficient project management.
 Optimization of Resources: CMM helps businesses

IMPORTANCE make the best use of all of their resources, including

money, labor, and time. Organizations can improve the

OF CAPABILITY
effectiveness of resource allocation by recognizing and
MATURITY
getting rid of unproductive practices.
MODEL
Comparing and Evaluating: A formal framework for

benchmarking and self-evaluation is offered by CMM.

Businesses can assess their maturity levels, pinpoint

their advantages and disadvantages, and compare

their performance to industry best practices.

 Management of Quality: CMM emphasizes quality
IMPORTANCE management heavily. The framework helps businesses
OF CAPABILITY apply best practices for quality assurance and control,

MATURITY which raises the quality of their goods and services.

MODEL Enhancement of Process: CMM gives businesses a

methodical approach to evaluate and enhance their

operations. It provides a road map for gradually

improving processes, which raises productivity and

usefulness.
IMPORTANCE Increased Output: CMM seeks to boost productivity by
OF CAPABILITY simplifying and optimizing processes. Organizations can

MATURITY increase output and efficiency without compromising

MODEL quality as they go through the CMM levels.

LEVELS OF 1. Initial
CAPABILITY 2. Repeatable
3. Defined
MATURITY
4. Managed
MODEL
5. Optimizing
(CMM)
 At the initial level, processes are disorganized

Unstable environment for software development.

No basis for predicting product quality, time for

completion, etc.

1. INITIAL Limited project management capabilities, such as no

systematic tracking of schedules, budgets, or progress.

We have limited communication and coordination among

team members and stakeholders.

No formal training or orientation for new team members.

Highly dependent on individual skills and knowledge rather

than standardized processes.

 Focuses on establishing basic project management policies.

Experience with earlier projects is used for managing new

similar-natured projects.

Project Planning- It includes defining resources required,

2. REPEATABLE goals, constraints, etc. for the project. It presents a detailed

plan to be followed systematically for the successful

completion of good-quality software.

Configuration Management- The focus is on maintaining

the performance of the software product, including all its

components, for the entire lifecycle.

 Requirements Management- It includes the management

of customer reviews and feedback which result in some

changes in the requirement set. It also consists of

accommodation of those modified requirements.

Subcontract Management- It focuses on the effective

2. REPEATABLE
management of qualified software contractors i.e. it

manages the parts of the software developed by third

parties.

Software Quality Assurance- It guarantees a good quality

software product by following certain rules and quality

standard guidelines while developing.

 At this level, documentation of the standard guidelines and

procedures takes place.

It is a well-defined integrated set of project-specific

software engineering and management processes.

3. DEFINED Peer Reviews: In this method, defects are removed by

using several review methods like walkthroughs,

inspections, buddy checks, etc.

Intergroup Coordination: It consists of planned

interactions between different development teams to

ensure efficient and proper fulfillment of customer needs.

 Organization Process Definition: Its key focus is on the

development and maintenance of standard development

processes.

Organization Process Focus: It includes activities and

3. DEFINED practices that should be followed to improve the process

capabilities of an organization.

Training Programs: It focuses on the enhancement of

knowledge and skills of the team members including the

developers and ensuring an increase in work efficiency.

 At this stage, quantitative quality goals are set for the

organization for software products as well as software

processes.

The measurements made help the organization to predict

the product and process quality within some limits defined

4. MANAGED quantitatively.

Software Quality Management: It includes the

establishment of plans and strategies to develop

quantitative analysis and understanding of the product’s

quality.

Quantitative Management: It focuses on controlling the

project performance quantitatively.

 This is the highest level of process maturity in CMM and

focuses on continuous process improvement in the

organization using quantitative feedback.

The use of new tools, techniques, and evaluation of software

processes is done to prevent the recurrence of known

5. OPTIMIZING defects.

Process Change Management: Its focus is on the

continuous improvement of the organization’s software

processes to improve productivity, quality, and cycle time for

the software product.

 Technology Change Management: It consists of the

identification and use of new technologies to improve

product quality and decrease product development time.

5. OPTIMIZING Defect Prevention It focuses on the identification of causes

of defects and prevents them from recurring in future

projects by improving project-defined processes.