UNIT 3: SOFTWARE DESIGN

3.1 Software Design Process

What is Software Design?

“Software Design is the process of defining the architecture, components, interfaces, dara and other characteristics
of a system or component to satisfy specified requirements.” OR
"Software design is the process of defining the software methods, functions, objects, and the overall structure and
interaction of the code to satisfy specified requirements." OR
"It is the process of defining a structured solution that meets all of the technical and operational requirements while
optimizing common quality attributes such as performance, security, and maintainability."

Why design is important?

A good design is the key to a successful product. The importance of software design is given below:-

a. Foundation for Development

b. Improves Code Quality
c. Reduces Complexity
d. Facilitates Communication
e. Enables Early Detection of Problems
f. Supports Scalability and Flexibility
g. Improves Project Planning and Estimation
h. Boosts Reusability
i. Enhances Maintainability
j. Essential for Quality Assurance

Objectives of Software Design

 Create a blueprint for the software system.

 Ensure that the system is efficient, reliable, maintainable, and scalable, and correct.
 Minimize complexity while maximizing efficiency.
 Follows principles like modularity, abstraction, and separation of concerns.

Key Principles of Good Software Design

Principle Description
Abstraction Hides unnecessary details and shows only relevant data.
Modularity Divides software into small, manageable parts (modules).
Cohesion Ensures each module performs a single well-defined function.
Coupling Measures dependency between modules (should be minimized).
Encapsulation Data hiding mechanism to protect integrity.
Separation of Concerns Each component should focus on a single functionality.

Good Design Vs Bad Design

Characteristics Good Design Bad Design

Change Change is one part of the system does not always require a change One change requires changes to many
in another part of the system. part of the system.
Logic Every piece of logic has one and only one home. Logic has to be duplicated.
Cost Small High
Nature Simple Complex
Extension System can be extended with changes in only one place. System cannot be extended easily.
Design Framework

• In this process (phase) designer plans “ How’ a s/w system should be produced as per customer requirements.
• SRS tell us “What” a system does. Design Process tell us “How” a s/w system work.
• Designing of a s/w system means determining how requirements are realized and result in a s/w design document
(SDD).
• Framework of design is given below:

What is Software Architecture?

Software architecture is the blueprint of the software system, defining components, relationships, and
constraints. It provides a structured solution to meet technical and business expectations.

Phases of Software Design

1. Architectural Design
o Defines the overall system structure.
o Specifies major components and their relationships.
o High-level structure of a software system.
o Defines software components, data flow, and interactions.
o Examples: Layered Architecture, Client-Server, Microservices.
2. High-Level Design (HLD)
o Specifies modules, their interfaces, and interconnections.
o Also called system design or top-level design.
3. Detailed Design (Low-Level Design – LLD)
o Specifies the logic of each module.
o Includes algorithms, data structures, and function definitions.
o Deals with detailed design of software modules.
o Modularization: Breaking software into smaller independent modules.
o Design Structure Charts: Represent hierarchy and module relationships.
o Pseudo Code & Flowcharts: Represent logic before coding.
4. Coupling and Cohesion
o Cohesion: How strongly related the functions within a module are.
o Coupling: Degree of dependency between modules.
o Aim for high cohesion and low coupling for better maintainability.

3.2 Architectural Design

Definition:

Architectural Design is the high-level structuring of a software system, which defines:

 The overall organization of the system

 The main components (modules, services, subsystems)
 The relationships and interactions among those components
 Key design decisions related to performance, security, scalability, and maintainability

"Architectural design is the process of defining a collection of hardware and software components and their
interfaces to establish the framework for the development of a computer system."

Architectural design methods have a look into various alternates architectural style of designing a system.

Data Centric Architecture :- This approach involves the use of a central database operations of inserting,
updating it in the form of a table.

Data Flow architecture: - It is central round the pipe and filter mechanism. This architecture is applied
when input takes the form of output after passing through various phases of transformations. These
transformations can be via manipulations or various computations done on the data.

Object Oriented Architecture:- In this the software design moves around the classes and object of the
system. The class encapsulates the data and methods.

Layered Architecture:- At least this defines a number of layers and each layer performs tasks. The outer
most layer handles the functionality of the user interface and the inner most layer mainly handles interaction
with the hardware.

Objectives of Architectural Design:-

 The objective is to develop a model of software architecture, which gives a overall organization of
program module in software product.
 Software architecture encompasses two aspects of structure of the data and hierarchical structure of the
software components.

Problem
s D

Fig: Problems, Solutions, and Architecture

 This design defines organization of program components. It does not provide the details of each
components and its implementation.
 The objective is to control relationship between modules. One module may control another module or
may be controlled by another module.
 These characteristics are defined by fan–in and fan-out of a particular module. The organization of
module can be represented through a tree- like structure.
 The number of level of component in the structure is called depth and number of component across the
horizontal section is called width.
 The number of components which controls a said component is called fan-in, i.e the number of incoming
edges to a component.
 The number of component that are controlled by the module is called fan-out, i.e the number of outgoing
edges.

Purpose of Architectural Design:

 To bridge the gap between requirements specification and detailed design.

 To provide a blueprint for system construction.
 To ensure the system’s structure supports both current and future needs.

Common Software Architecture Styles

Architecture Style Description

Organizes software into layers (e.g., Presentation, Business Logic, Data). Used in enterprise
Layered Architecture
applications.
Splits system into client-side (user interface) and server-side (processing and storage).
Client-Server Architecture
Example: Web applications.
Microservices Architecture Breaks application into small, independent services that communicate via APIs.
Separates application logic into Model (data), View (UI), and Controller (process logic). Used
Model-View-Controller (MVC)
in web frameworks.
Breaks down processing into separate, independent steps that pass data through a pipeline.
Pipe-and-Filter Architecture
Used in compilers.

Key Elements in Architectural Design:

1. Software components (e.g., modules, services, databases)

2. Connectors (how components interact – APIs, messages, protocols)
3. Configuration (layout or structure of components)
4. Design decisions related to non-functional requirements (e.g., security, reliability)

Why is it important?

 Sets the foundation for the entire software project

 Helps ensure the software is scalable, maintainable, and robust
 Guides technical choices and helps manage complexity
 Aids in risk management by identifying critical system components early

Issues in Architectural Design

 Gross Decomposition of the system into major components.

 Allocation of functional responsibilities to components.
 Component interfaces.
 Communication and interaction between components.

3.3. Low-Level Design (LLD) in Software Engineering

Low-Level Design (LLD) focuses on detailed module-level design of a software system. It defines how
each component will be implemented, including functionality, data structures, and interactions
between modules.

Modularization

What is Modularization?

 Breaking down a large system into independent, manageable modules.

  Each module is a self-contained unit with well-defined functionality.

Advantages of Modularization

✔ Easier maintenance – Bugs and changes affect only specific modules.

✔ Reusability – Modules can be reused across projects.
✔ Improved readability – Each module focuses on a specific task.
✔ Parallel development – Multiple developers can work on different modules.

Design Structure Charts

What is a Design Structure Chart?

 A hierarchical diagram showing the relationship between modules.

 Represents top-down decomposition of a system.

Example of a Design Structure Chart

Order Processing System

|
-----------------
| |
Order Entry Payment Processing
|
-------------
| |
Validation Database Update

✔ Arrows show data flow between modules.

✔ Higher-level modules depend on lower-level ones.

Pseudo Code

What is Pseudo Code?

 A high-level description of an algorithm.

 Uses simple, structured English (no strict syntax).
 Helps in translating logic into code.

Example: Pseudo Code for Finding the Maximum of Two Numbers

BEGIN
INPUT A, B
IF A > B THEN
PRINT "A is greater"
ELSE
PRINT "B is greater"
ENDIF
END

✔ Helps programmers understand logic before actual coding.

✔ Makes debugging easier before implementation.
Flow Charts

What is a Flow Chart?

 A graphical representation of an algorithm.

 Uses symbols to represent different operations.

Basic Symbols in Flowcharts

Symbol Meaning

(Oval) Start/End

(Rectangle) Process (Assignment, Calculation)

(Parallelogram) Input/Output

(Diamond) Decision (IF Condition)

(Arrow) Flow of Control

Example: Flowchart for Checking Even or Odd

Start
|
▼
Input N
|
▼
N % 2 == 0?
/ \
Yes No
| |
▼ ▼
Print Print
"Even" "Odd"
| |
▼ ▼
End End

✔ Graphical approach to debugging and understanding code flow.

✔ Helps in explaining logic visually.

1. Coupling and Cohesion

Aspect Cohesion Coupling

Definition Degree to which a module’s elements work together. Degree of dependency between modules.
Ideal State High cohesion (better design). Low coupling (less dependency).

Cohesion

 Measures how strongly related functions within a module are.

  Types of Cohesion (from worst to best):

Type Description

Coincidental Cohesion Randomly grouped functions.

Logical Cohesion Functions grouped by category.

Temporal Cohesion Functions executed together.

Procedural Cohesion Functions executed in sequence.

Communicational Cohesion Functions sharing the same data.

Functional Cohesion Each function has a single purpose (best type).

✔ High cohesion = Better software design.

Coupling

 Measures dependency between different modules.

 Types of Coupling (from worst to best):

Type Description

Content Coupling One module modifies another’s internal data.

Common Coupling Multiple modules share global variables.

Control Coupling One module controls the behavior of another.

Stamp Coupling Modules share complex data structures.

Data Coupling Modules exchange simple data (best type).

✔ Low coupling = Better modularization and independence.

3.3 Design Strategies

Design strategies define how software is structured and developed to ensure efficiency, scalability, and
maintainability. The four major design strategies are:

Design Strategy Description

Function-Oriented Design Focuses on breaking the system into functions.

 Design Strategy Description

Object-Oriented Design (OOD) Uses classes, objects, and relationships (Encapsulation, Inheritance).

Top-Down Design Starts with high-level modules and breaks them down.

Bottom-Up Design Develops low-level modules first and integrates them.

1. Function-Oriented Design

What is Function-Oriented Design?

 System is decomposed into smaller functions, each performing a specific task.

 Uses a hierarchical approach where functions call other functions.
 Focuses on functions and procedures of a system.
 Uses Data Flow Diagrams (DFDs) to model system functionality.
 Example: Banking software that follows transactions as a sequence of operations.

Key Features:

✔ Main focus on functions/processes.

✔ Data flows between functions.
✔ Uses Data Flow Diagrams (DFDs).
✔ Well-suited for procedural programming languages like C.

Example: Library Management System

 Main function: Manage Library

o Sub-functions: Issue Book, Return Book, Manage Members
o Each sub-function calls further smaller functions.

Advantages:

✔ Simple and easy to design.

✔ Efficient for small projects.
✔ Easy to understand and modify.

Disadvantages:

❌Difficult to scale for large projects.

❌Harder to reuse functions in new systems.
❌Maintenance is complex if requirements change frequently.

2. Object-Oriented Design (OOD)

What is Object-Oriented Design?

 Focuses on objects and classes instead of functions.

  Objects contain both data and behaviors (methods).
 Uses concepts like inheritance, polymorphism, and encapsulation.
 Uses Unified Modeling Language (UML) to represent object relationships.
 Example: A library management system with objects like Book, Student, and Librarian.

Key Features:

✔ Encapsulation – Data and methods are bundled together.

✔ Inheritance – New classes can inherit from existing ones.
✔ Polymorphism – The same function can work in different ways.
✔ Objects communicate via messages.

Example: Library Management System (OOD)

 Classes: Book, Member, Librarian

 Objects: Each instance represents a book or a user.
 Methods: issueBook(), returnBook(), calculateFine().

Advantages:

✔ Highly reusable – Objects can be reused in different applications.

✔ Easy maintenance – Changes in one object do not affect others.
✔ Scalable – Suitable for large and complex systems.

Disadvantages:

❌More complex than function-oriented design.

❌Requires a learning curve for procedural programmers.

UML Diagrams for Software Design

What is UML?

Unified Modeling Language (UML) is a graphical modeling language used for designing object-oriented
software.

Types of UML Diagrams

Diagram Purpose
Use Case Diagram Shows interactions between users and the system.
Class Diagram Represents object classes, their attributes, and relationships.
Sequence Diagram Shows interactions between objects over time.
Activity Diagram Represents the workflow of a system.
State Diagram Defines different states of an object and transitions between them.

Example: Class Diagram for Library System

 Classes: Book, Member, Librarian

 Attributes: Book ID, Member ID, Name, Issue Date
 Relationships:
 o A Member borrows a Book.
o A Librarian manages Books.

Comparison of Function-Oriented and Object-Oriented Design

Aspect Function-Oriented Design Object-Oriented Design

Focus Functions & data flow Objects & interactions
Design Approach Uses DFDs, processes functions first Uses UML, models real-world entities first
Example Banking system with separate transaction functions Library system with Book, Member, Librarian objects

3. Top-Down Design

What is Top-Down Design?

 Starts with the main system and breaks it into smaller subsystems.
 Each subsystem is further divided into smaller modules.
 Uses stepwise refinement – progressing from general to specific.
 Starts from the high-level system architecture and breaks it down into smaller submodules.
 Example: Breaking down a university management system into modules like Student Management,
Faculty Management, Exam System, Library System, etc.

Key Features:

✔ Main module is defined first and then refined.

✔ Helps in designing complex systems in an organized way.
✔ Uses Design Structure Charts to show module relationships.

Example: Online Shopping System

1. Main module: Online Shopping

o Sub-modules: Product Selection, Payment Processing, Order Tracking
o Further breakdown: Payment Processing → Card Payment, UPI Payment

Advantages:

✔ Provides clear structure and better problem decomposition.

✔ Easier to understand and debug.
✔ Ideal for large projects.

Disadvantages:

❌Requires detailed planning before implementation.

❌Changes in low-level modules may require modifications at multiple levels.

4. Bottom-Up Design

What is Bottom-Up Design?

  Starts with small, reusable components and integrates them into a complete system.
 Opposite of Top-Down Design.
 Individual modules are tested and combined to form the final system.
 Begins with small, reusable components and integrates them into a larger system.
 Example: Designing small functions first (like login verification) and integrating them into a larger
application.

Key Features:

✔ Develops independent modules first.

✔ Emphasizes reusability of components.
✔ Uses low-level abstraction, then integrates into a high-level system.

Example: Online Shopping System (Bottom-Up Approach)

1. Develop individual components first:

o Payment Processing Module
o Order Tracking Module
o Product Database
2. Combine them into subsystems like Shopping Cart and User Management.
3. Finally, integrate them into the complete system.

Advantages:

✔ Facilitates reuse of existing modules.

✔ Easier testing – Individual components are tested first.
✔ Faster development using pre-built libraries.

Disadvantages:

❌Difficult to get an overall system structure early on.

❌Integration of modules may require modifications later.

5. Hybrid Design

 Combines both top-down and bottom-up approaches for maximum efficiency.

Comparison of Design Strategies

Feature Function-Oriented Object-Oriented Top-Down Bottom-Up

Focus Functions & processes Objects & classes System first Components first

Data Handling Shared data Encapsulated data Hierarchical Independent modules

Design Approach Procedural Modular, reusable General → Specific Specific → General

Reusability Low High Moderate High

 Feature Function-Oriented Object-Oriented Top-Down Bottom-Up

Best For Small projects Large complex systems Large projects Modular & reusable designs

3.4 Software Measurement and Metrics

Software measurement and metrics are essential for quantifying software quality, complexity, and
efficiency. They help in estimating effort, cost, and maintenance.

Categories of Software Metrics:

1. Size-Oriented Metrics – Measure software based on lines of code (LOC), function points, etc.
✔ Halstead’s Software Science – Measures program complexity using operators and operands.
✔ Function Point (FP) Based Measures – Estimates size using user inputs, outputs, and transactions.
2. Complexity Metrics – Measure software complexity and maintainability.
3. Quality Metrics – Evaluate defects, reliability, and performance.

1. Size-Oriented Metrics

Size-oriented metrics are based on the size of the software, often measured in Lines of Code (LOC) or
Function Points (FP).

Advantages of Size-Oriented Metrics

✔ Easy to calculate for well-defined programs.

✔ Helps in effort estimation and cost prediction.

Disadvantages of Size-Oriented Metrics

❌Dependent on coding style (e.g., the same function can be implemented in different LOC).
❌Difficult to compare across different languages.

2. Halstead’s Software Science

It is a set of mathematical formulas that measure software complexity based on operators and
operands in the program.

Key Terminologies:

 n1 = Number of distinct operators

 n2 = Number of distinct operands
 N1 = Total occurrences of operators
 N2 = Total occurrences of operands

Halstead Metrics Formulas:

Metric Formula Meaning

 Metric Formula Meaning

Program Vocabulary (n) n = n1 + n2 Number of unique operators & operands

Program Length (N) N = N1 + N2 Total occurrences of operators & operands

Volume (V) V = N * log2(n) Size of the software

Effort (E) E=V/L Required effort to develop software

Difficulty (D) D = (n1/2) * (N2/n2) Complexity of software

Time Required (T) T = E / 18 Estimated time to write the code (in seconds)

Example Calculation:

Assume a program has:

 n1 = 10 (distinct operators)
 n2 = 15 (distinct operands)
 N1 = 50 (total operator occurrences)
 N2 = 60 (total operand occurrences)

Calculations:

 n = 10 + 15 = 25
 N = 50 + 60 = 110
 V = 110 * log2(25) ≈ 110 * 4.64 = 510.4
 Higher volume = More complex software

Advantages of Halstead’s Metrics

✔ Helps in effort estimation.

✔ Used for predicting defects and complexity.

Disadvantages of Halstead’s Metrics

❌Not useful for non-procedural programming languages (e.g., OOP).

❌Assumes that all operators/operands have equal weight, which is not always true.

3. Function Point (FP) Based Measures

What is Function Point Analysis (FPA)?

 A technique to measure software size based on functionality rather than LOC.

 Developed by Allan Albrecht (IBM).
 Useful for estimating effort, cost, and productivity.

Function Point (FP) Calculation Steps

Step 1: Identify Components

  External Inputs (EI) → Inputs from users (e.g., form submission).
 External Outputs (EO) → Output reports, messages, etc.
 External Inquiries (EQ) → Search operations, user queries.
 Internal Logical Files (ILF) → Internal database files.
 External Interface Files (EIF) → Data from external systems.

Step 2: Assign Weights

Each component is assigned weights based on complexity (Low, Average, High).

Component Low Average High

External Inputs (EI) 3 4 6

External Outputs (EO) 4 5 7

External Inquiries (EQ) 3 4 6

Internal Logical Files (ILF) 7 10 15

External Interface Files (EIF) 5 7 10

Step 3: Compute Unadjusted Function Points (UFP)

UFP=(EI×weight)+(EO×weight)+(EQ×weight)+(ILF×weight)+(EIF×weight)UFP = (EI \times weight) +

(EO \times weight) + (EQ \times weight) + (ILF \times weight) + (EIF \times
weight)UFP=(EI×weight)+(EO×weight)+(EQ×weight)+(ILF×weight)+(EIF×weight)

Step 4: Apply Complexity Factor

Adjust UFP based on complexity factors (0 to 5) like:

 Reliability
 Data communication
 Performance requirements
 Processing complexity

Adjusted Function Points:

AFP=UFP×Complexity FactorAFP = UFP \times Complexity\ FactorAFP=UFP×Complexity Factor

Example Calculation:

If a system has:

 EI = 10 (low weight → 3 each)

 EO = 5 (average weight → 5 each)
 ILF = 3 (high weight → 15 each)
 EIF = 2 (low weight → 5 each)

UFP Calculation:

(10×3)+(5×5)+(3×15)+(2×5)=30+25+45+10=110(10 \times 3) + (5 \times 5) + (3 \times 15) + (2 \times 5) =

30 + 25 + 45 + 10 = 110(10×3)+(5×5)+(3×15)+(2×5)=30+25+45+10=110
Assuming complexity factor = 1.1,

AFP=110×1.1=121AFP = 110 \times 1.1 = 121AFP=110×1.1=121

Advantages of Function Point Metrics

✔ Independent of programming language.

✔ Helps in early estimation of project effort.
✔ More reliable than LOC-based metrics.

Disadvantages of Function Point Metrics

❌Subjective evaluation (complexity factors may vary).

❌Requires detailed functional understanding of the system.

Comparison: Halstead vs. Function Point Metrics

Feature Halstead’s Metrics Function Points (FP)

Measurement Basis Operators & Operands Functional Requirements

Language Dependency Yes No

Best For Procedural Code Business Applications

Effort Estimation Mathematical Formulas Complexity-Based

Usability Code-Level Analysis High-Level Planning

3.5 Cyclomatic Complexity and Control Flow Graphs

Introduction to Cyclomatic Complexity

Cyclomatic complexity is a software metric that measures the complexity of a program based on the
number of independent paths in the code. It was developed by Thomas J. McCabe in 1976.

Cyclomatic Complexity (McCabe’s Metric)

✔ Measures software complexity using Control Flow Graphs (CFG).

✔ Formula: V(G) = E - N + 2P

 E = Number of edges in the graph.

 N = Number of nodes in the graph.
 P = Number of connected components.
✔ Higher complexity → Harder maintenance and testing.

Why is Cyclomatic Complexity Important?

 Helps in determining test case coverage.

 Aids in identifying complex code areas.
  Supports software maintainability and quality.

Control Flow Graph (CFG)

A Control Flow Graph (CFG) represents the flow of execution in a program using nodes and edges.

 Nodes → Represent program statements or blocks.

 Edges → Represent control flow (e.g., if-else, loops).

Example Control Flow Graph

Consider the following simple program:

int main() {
int a = 5, b = 10;
if (a < b) {
a = a + 1;
} else {
b = b - 1;
}
return 0;
}

Control Flow Graph (CFG) Representation:

(1) Start
↓
(2) if (a < b)
/ \
/ \
(3) a++ (4) b--
\ /
\ /
(5) End

Cyclomatic Complexity Calculation

Cyclomatic complexity (V(G)) is calculated using the formula:

V(G)=E−N+2PV(G) = E - N + 2PV(G)=E−N+2P

Where:

 E = Number of edges in the control flow graph

 N = Number of nodes
 P = Number of connected components (usually 1 for a single function)

Example Calculation:

For the above CFG:

 E = 5 (edges)
 N = 5 (nodes)
 P=1
V(G)=5−5+2(1)=2V(G) = 5 - 5 + 2(1) = 2V(G)=5−5+2(1)=2

Thus, Cyclomatic Complexity = 2.

Interpretation of Cyclomatic Complexity

Cyclomatic Complexity Code Complexity Level Testing Effort Required

1 – 10 Simple and easy to test Low

11 – 20 Moderately complex Medium

21 – 50 Complex, needs refactoring High

> 50 Highly complex and difficult to maintain Very High

 Higher complexity means more test cases are needed for complete coverage.
 Complexity > 10 indicates the need for refactoring.

Alternative Cyclomatic Complexity Formulae

1 ⃣ Using Predicate Nodes (Decision Points)

V(G)=D+1V(G) = D + 1V(G)=D+1

Where:

 D = Number of decision nodes (e.g., if, while, for).

2 ⃣ Using Regions in Flow Graph

V(G)=Number of RegionsV(G) = Number\ of\ RegionsV(G)=Number of Regions

Regions refer to closed areas within the Control Flow Graph.

Example: Cyclomatic Complexity for a Loop

int main() {
int i = 0;
while (i < 5) {
i++;
}
return 0;
}

Control Flow Graph:

(1) Start
 ↓
(2) while (i < 5)?
/ \
(3) i++ (4) End
\ /
\ /
(2)

Using E - N + 2P formula:

 E = 4
 N = 4
 P = 1

V(G)=4−4+2(1)=2V(G) = 4 - 4 + 2(1) = 2V(G)=4−4+2(1)=2

Complexity = 2 (low complexity).

7. Best Practices for Reducing Cyclomatic Complexity

✔ Use functions to break complex logic.

✔ Reduce nested if-else statements.
✔ Replace deep loops with iterators or recursion.
✔ Use switch-case instead of multiple if-else.
✔ Write clear and modular code.