Unit-2-Notes

📘 Software Design
🧠 1. Software Design
Planning phase before coding
Defines:
Structure
Modules
Data flow
👉 Goal: Maintainable + Scalable + Understandable system
🏗️ 2. Architectural Design

Unit-2-Notes 1
 Definition:
High-level structure of the system
Includes:
Modules (Frontend, Backend, DB)
Communication between modules
Example:

User → Frontend → Backend → Database

👉 Think: “Big Picture”

🔧 3. Low-Level Design (LLD)
Unit-2-Notes 2
 Definition:
Detailed design of each module
Includes:
Functions
Logic
Algorithms
Data structures
👉 Think: “How code works internally”
🧩 4. Modularization
System
├── Login Module
├── Payment Module
└── Dashboard Module

Unit-2-Notes 3
 Definition:
Breaking system into smaller modules
Advantages:
Easy debugging
Reusability
Better organization

🌳 5. Structure Chart

Definition:
Shows module hierarchy
👉 Like a tree:
Unit-2-Notes 4
 Main Module
├── Sub Module A
└── Sub Module B

✍️ 6. Pseudocode
START
INPUT number
IF number > 0
PRINT "Positive"
ELSE
PRINT "Negative"
END

Definition:
Simple English-like logic
👉 Helps before coding
🔄 7. Flowchart

Unit-2-Notes 5
 Definition:
Graphical representation of logic
Symbols:
Oval → Start/End
Rectangle → Process
Diamond → Decision

🔗 8. Coupling vs Cohesion
In software engineering, Coupling and Cohesion are the two "golden rules" used
to measure the quality of a system's design. Think of them as the metrics for how
well your code is organized.

1. Cohesion (The "Internal" Measure)

Cohesion refers to how closely related the responsibilities inside a single module
(or class) are. It asks: "Does every part of this module help do the same job?"
High Cohesion (Good): The module does one specific thing and does it well.
For example, a PaymentProcessor class only handles payments.
Low Cohesion (Bad): The module is a "junk drawer" of unrelated tasks. For
example, a Utility class that handles database connections, prints reports,
and calculates taxes.
Goal: Aim for High Cohesion. It makes your code easier to read, maintain, and
reuse.

2. Coupling (The "External" Measure)

Coupling refers to the degree of dependency between different modules. It
asks: "How much does Module A rely on Module B to function?"

Unit-2-Notes 6
 Loose Coupling (Good): Modules are independent. You can change Module A
without breaking Module B. They usually communicate through simple
interfaces.
Tight Coupling (Bad): Modules are highly dependent. If you change a small
piece of code in one class, five other classes crash.
Goal: Aim for Loose Coupling. It allows you to swap out parts of your system
(like changing a database) without rebuilding the entire app.

Comparison Table
Feature Cohesion Coupling
Definition Relationship within a module. Relationship between modules.
How focused a module's tasks How dependent modules are on each
Focus
are. other.
Ideal State High (Focused). Low/Loose (Independent).
Simpler Like a specialist doctor who Like two neighbors who don't need to
Analogy only does heart surgery. share a kitchen to live.

The Relationship
Usually, if you strive for High Cohesion, you naturally end up with Loose
Coupling. When every module knows exactly what its job is and minds its own
business, they don't need to constantly "poke" into each other's internal logic.

⚙️ 9. Design Strategies
🧠 Function-Oriented Design
Based on functions
Uses DFD
👉 Focus: “What system does”
🧱 Object-Oriented Design (OOD)
Unit-2-Notes 7
 Class: User
- name
- email
+ login()

👉 Concepts:
Class
Object
Inheritance
Encapsulation
👉 Focus: “Real-world modeling”
🔝 Top-Down Approach
System
↓
Modules
↓
Sub-modules

👉 Start big → break down

🔽 Bottom-Up Approach
Functions
↑
Modules
↑
System

👉 Start small → build up

Software engineering metrics can feel like a lot of jargon, but they are really just
different ways to answer one question: "How big and complex is this
project?" Here are the simplified notes on the three major measurement styles.

Unit-2-Notes 8
 1. Size-Oriented Measures: Halstead’s Software
Science
Developed by Maurice Halstead, this method treats code like a collection of
tokens. It doesn't care about "lines of code" as much as it cares about
the vocabulary used.
The Core Concept: Halstead divides code into two categories:
1. Operators: Action items (e.g., + , , if , while , print ).
2. Operands: The data items being acted upon (e.g., variables like x , total ,
or constants like 100 ).
What it measures:
Program Vocabulary (n): The total number of unique operators and
operands.
Program Length (N): The total count of every time an operator or operand
appears.
Volume (V): How much "space" the algorithm takes up in your
head/memory.
Difficulty (D): How prone to errors the code is based on how many
operands are reused.

2. Function Point (FP) Based Measures

While Halstead looks at the code itself, Function Points look at
the functionality provided to the user. It measures "what the system does" rather
than "how many lines it took."
The Core Concept: You count five specific user-facing components:
1. External Inputs: Screens or forms where users enter data.
2. External Outputs: Reports or screens that show calculated data.
3. External Inquiries: Simple lookups (e.g., searching for a customer).
4. Internal Logical Files: Databases or files maintained inside the system.

Unit-2-Notes 9
 5. External Interface Files: Data shared with other systems.
Why use it? It’s great for the early stages of a project because you can
estimate the size of a program before a single line of code is written.

3. Cyclomatic Complexity: Control Flow Graphs

This is a measure of the logical complexity of the code. It tells you how many
"paths" there are through your program.
The Core Concept: If you have many if statements, loops , and switches , your
code is harder to test and maintain.
Control Flow Graph (CFG): This is a visual map of the code.
Nodes: Represent a sequence of code (a statement).
Edges: Represent the flow (the arrows connecting the code).
The Formula (V(G)): The complexity is usually calculated as:
V(G)=E−N+2P
(Where E = edges, N = nodes, and P = connected components, usually 1).
The Rule of Thumb: * 1–10: Low complexity (Easy to test).
11–20: Moderate complexity.
21–50: High complexity (Hard to test, "spaghetti code").
>50: Unstable/Untestable.

Summary Table
Metric Focus Best Used For
Tokens
Halstead Measuring code density and effort.
(Operators/Operands)
Estimating project size during the
Function Points User Requirements
planning phase.
Cyclomatic Deciding how many test cases you
Logic Paths
Complexity need.

Unit-2-Notes 10
 🧪 Software Testing
🎯 1. Testing Objectives
👉 Why we do testing?
Find bugs 🐞
Ensure software works correctly
Improve quality & reliability
Check performance & security

✅ Key Goals:
Correctness ✔️
Completeness ✔️
Reliability ✔️
Performance ✔️

🔍 2. Types of Testing
🧩 2.1 Unit Testing
👉 Testing smallest unit of code (function/class)
Done by: Developer 👨‍💻
Example:

function add(a, b) {
return a + b;
}

👉 Check if output is correct

Unit-2-Notes 11
 ✅ Advantages:
Easy to debug
Fast
Early bug detection

🔗 2.2 Integration Testing

👉 Testing combined modules
Goal: Check interaction between modules

📌 Types:
Top-Down
Bottom-Up

Example:
Frontend ↔ Backend ↔ Database

✅ 2.3 Acceptance Testing

👉 Final testing before delivery
Done by: Client/User 👤

🎯 Purpose:
Check if requirements are met
Ready for deployment

🔁 2.4 Regression Testing

👉 Re-testing after changes/fixes

Unit-2-Notes 12
 🎯 Purpose:
Ensure old features still work

Example:
Bug fixed in login → test login + other modules again

⚙️
👉
3. Testing for Functionality
Checks what system does

📌 Focus:
Inputs → Outputs
Features working or not

Example:
Login works? ✔️
Payment works? ✔️
👉 Also called Black Box Testing
🚀
👉
4. Testing for Performance
Checks how system performs under load

📌 Types:
Load Testing → normal users
Stress Testing → extreme load
Speed Testing → response time

Unit-2-Notes 13
 Example:
Website with 1000 users at once

🧪 Software Testing Strategies

🔝 1. Top-Down Testing

👉 Testing starts from top (main module) → goes downward

📌 Process:
Main Module
↓
Sub Modules
↓
Small Components

Unit-2-Notes 14
 🧠 Key Point:
Uses Stubs (fake lower modules)

✅ Advantages:
Early testing of main logic
Good for high-level design

❌ Disadvantages:
Lower modules tested late

🔽
👉
2. Bottom-Up Testing
Testing starts from small modules → goes upward

📌 Process:
Small Modules
↑
Sub Modules
↑
Main Module

🧠 Key Point:
Uses Drivers (simulate main module)

✅ Advantages:
Low-level modules tested early
Easy debugging

❌ Disadvantages:
Main system tested late

Unit-2-Notes 15
 🔧 3. Test Drivers & Test Stubs
🚗 Test Driver
👉 Dummy program that calls module
Driver → Module Under Test

✔ Used in Bottom-Up Testing

🧱 Test Stub
👉 Dummy module that is called by main module
Main Module → Stub

✔ Used in Top-Down Testing

🎯 Easy Trick to Remember:
Driver drives (calls)
Stub stands in place (fake module)

⚪
👉
4. White Box Testing
Testing internal code logic

📌 Focus:
Loops
Conditions
Code paths

Unit-2-Notes 16
 👨‍💻 Done by:
Developers

✅ Example:
Check all if-else paths

⚫ 5. Black Box Testing

👉 Testing without knowing code

📌 Focus:
Input → Output
Functionality

👤 Done by:
Testers / Users

Unit-2-Notes 17
 ✅ Example:
Enter login → check correct output

🧑‍🔬 6. Alpha Testing

👉 Testing inside company

📌 Done by:
Developers + Internal testers

🎯 Purpose:
Find bugs before release

🌍 7. Beta Testing
Unit-2-Notes 18
 👉 Testing by real users in real environment
📌 Done by:
End users

🎯 Purpose:
Get real feedback
Final bug detection

🧪 Static Testing Strategies

🧠 1. What is Static Testing?
👉 Testing without executing code
Done by reading:
Code
Design documents

Unit-2-Notes 19
 Requirements

🎯 Goal:
Find errors early (before execution)
Improve code quality

✅ Examples:
Reviews
Inspections
Walkthroughs

🔍 2. Formal Technical Reviews (FTR)

Unit-2-Notes 20
 👉 Team members review each other's work
📌 Participants:
Author (who wrote code)
Reviewers (team members)
Moderator

🎯 Purpose:
Find defects
Ensure quality
Share knowledge

✅ Key Points:
Structured process
Checklist-based

👣 3. Walkthrough
👉 Author explains code/design step-by-step
📌 Features:
Informal
Knowledge sharing
No strict rules

Unit-2-Notes 21
 🎯 Goal:
Understand logic
Find basic mistakes

🔎 4. Code Inspection
👉 Most formal and structured review
📌 Roles:
Moderator
Reader
Recorder
Author

🎯 Focus:
Detect defects
Follow standards

✅ Key Feature:
Uses checklist
Detailed analysis

📏 5. Compliance with Design & Coding

Standards
👉 Ensure code follows rules & guidelines
📌 Includes:
Unit-2-Notes 22
 Naming conventions
Proper indentation
Code structure
Documentation

🎯 Purpose:
Maintain consistency
Improve readability
Reduce errors

🔄 Comparison
Method Type Formality Purpose
Peer Review Static Medium Find defects
Walkthrough Static Informal Understanding
Code Inspection Static Highly Formal Detailed defect finding

Unit-2-Notes 23