✅ What is Coupling?

Coupling means:

"How much one module depends on another."

 Low (loose) coupling is good → modules work more independently.

 High (tight) coupling is bad → modules are too dependent and harder to
change/test.

📉 Types of Coupling (from Best to Worst):

Coupling Type Meaning Quality

Only essential data is passed between modules using

1. Data Coupling ✅ Best
parameters.

2. Stamp Coupling Entire data structures passed; receiver may not use all data. ✅ Good

3. Control One module passes control flags to dictate behavior of ⚠

Coupling another. Moderate

4. External Modules depend on external systems (files, protocols,

⚠ Risky
Coupling devices).

5. Common
Global variables shared by multiple modules. ❌ Bad
Coupling

6. Content One module directly accesses or modifies another's internal

❌ Worst
Coupling logic/data.

🧠 Trick to Remember (Best → Worst):

🔤 Mnemonic:

"Dumb Students Can Even Cook Cakes"

Word Coupling Type

Dumb Data Coupling ✅

Students Stamp Coupling ✅

Can Control Coupling ⚠

Even External Coupling ⚠

Word Coupling Type

Cook Common Coupling ❌

Cakes Content Coupling ❌

🔍 Simple Example Summary:

1. Data Coupling:
✅ calculateSum(int a, int b) – only needed data is passed.

2. Stamp Coupling:
✅ process(Student s) – entire object passed, but only name is used.

3. Control Coupling:
⚠ doTask(int mode) – module behavior depends on passed flag.

4. External Coupling:
⚠ Two modules use the same file or communication protocol.

5. Common Coupling:
❌ Multiple modules change a global variable int x.

6. Content Coupling:
❌ Module A accesses Module B’s internal variable or code directly.

📌 Summary

Coupling Type Dependency Level Maintainability

Data Very Low ✅ High

Stamp Low ✅ Good

Control Moderate ⚠ Average

External Moderate-High ⚠ Risky

Common High ❌ Low

Content Very High ❌ Worst

✅ What is Cohesion?
Cohesion means how focused and related the tasks of a module are.

 High Cohesion = Good → Module does one job well.

 Low Cohesion = Bad → Module does many unrelated jobs.

🎯 Goal: Keep cohesion high in software design.

📉 Types of Cohesion (Best to Worst)

Type Meaning Quality

All parts of the module work together to perform

1. Functional Cohesion ✅ Best
one single function.

✅ Very
2. Sequential Cohesion Output of one task is the input to the next.
Good

3. Communicational Tasks operate on the same data or use the same

⚠ Good
Cohesion input.

Tasks follow a specific sequence but may not be

4. Procedural Cohesion ⚠ Okay
related in purpose.

Tasks that occur at the same time (e.g., all start-up

5. Temporal Cohesion ❌ Weak
routines).

Similar category of tasks, but selection is made

6. Logical Cohesion ❌ Poor
through control flow (if/switch).

7. Coincidental Cohesion Tasks are unrelated and randomly grouped. ❌ Worst

🧠 Trick to Remember (Best → Worst):

🔤 Mnemonic:

"Funny Students Cook Perfect Tasty Light Curry"

Word Cohesion Type

Funny Functional Cohesion ✅ Best

Students Sequential Cohesion ✅

Cook Communicational Cohesion ⚠

Word Cohesion Type

Perfect Procedural Cohesion ⚠

Tasty Temporal Cohesion ❌

Light Logical Cohesion ❌

Curry Coincidental Cohesion ❌ Worst

✅ Function-Oriented Design (FOD)

🔹 Definition:

Function-Oriented Design is a design strategy that focuses on functions or procedures that

transform inputs into outputs. The system is broken down into a hierarchy of functional
modules.

✅ 1. Function-Oriented Design (FOD)

1. Focuses on Functions – The system is designed around what functions it performs.

2. DFD-Based Modeling – Uses Data Flow Diagrams to model how data moves through
the system.

3. Top-Down Decomposition – Breaks the main function into sub-functions and

modules.

4. Global Data Access – Functions often share and access global data.

5. Structured Programming – Uses structure charts and pseudocode for system logic.

6. Low Reusability – Functions are tightly coupled with global data, making reuse
difficult.

7. Example Use Case – Suitable for systems like billing, compilers, or simple
management tools.

✅ 2. Object-Oriented Design (OOD)

1. Focuses on Objects – The system is built using objects that encapsulate data and
behavior.

2. Real-World Mapping – Models real-world entities (like Student, Account, etc.).

 3. Encapsulation – Data is private and accessed via methods only.

4. Supports Inheritance & Polymorphism – Enables code reuse and flexibility.

5. High Modularity – Classes are independent, making the system easy to manage and
extend.

6. Better Maintainability – Easier to update without affecting other parts.

7. Example Use Case – Best for apps like banking systems, games, e-commerce
platforms.

✅ 3. Top-Down Design

1. Starts from General View – Begins with the main system and breaks it down into
sub-modules.

2. Step-by-Step Decomposition – Each component is refined until implementable.

3. High-Level Planning First – Emphasizes overall system structure and logic early on.

4. Promotes Clarity – Provides a clear system overview for management and design
teams.

5. Less Focus on Reuse – Primarily concerned with achieving the overall function.

6. Risk of Missing Details – May overlook low-level challenges until later stages.

7. Example Use Case – Useful for reporting tools, admin panels, flow-based systems.

✅ 4. Bottom-Up Design

1. Starts from Low-Level Modules – Develops small, reusable components first.

2. Builds Upwards – Integrates smaller modules to form higher-level components.

3. Encourages Reusability – Promotes the creation of utility and helper modules.

4. Early Testing Possible – Low-level modules can be tested individually.

5. No Initial Big Picture – System overview is not clear until later stages.

6. Works Well with OOD – Complements object-oriented systems.

7. Example Use Case – Used in library development, API-based systems, toolkits.

✅ Principles of Software Design
Software design principles are guidelines to help developers create systems that are robust,
maintainable, scalable, and understandable. These principles ensure the software’s long-
term quality.

🔷 1. Modularity

 Break the system into smaller, manageable, independent modules.

 Each module should perform a single, well-defined task.

🔷 2. Abstraction

 Hides unnecessary details from the user.

 Focuses on what an object does rather than how it does it.

🔷 3. Encapsulation

 Combines data and methods into a single unit (class).

 Restricts direct access to internal data and enforces controlled access.

🔷 4. Separation of Concerns (SoC)

 Divide the system into distinct sections, each addressing a separate concern.

 Promotes parallel development and reduces complexity.

🔷 5. High Cohesion

 Each module should focus on a single task or responsibility.

 Makes the module easier to maintain and test.

🔷 6. Low Coupling

 Modules should have minimal dependencies on each other.

 Increases flexibility and reduces impact of changes.

🔷 7. DRY (Don’t Repeat Yourself)

 Avoid duplicating code or logic.

 Encourages reuse via functions, classes, or services.

🔷 8. Open/Closed Principle

 Software entities (classes, modules) should be open for extension but closed for
modification.
  Enhances maintainability.

✅ Characteristics of Good Software Design

A good software design has the following features:

🔹 1. Correctness

 Accurately implements the specified requirements and functionalities.

🔹 2. Understandability

 Easy to read and comprehend by other developers or teams.

 Includes meaningful names, modular structure, and clear logic.

🔹 3. Reusability

 Components or modules can be reused in other software or systems with little to no

modification.

🔹 4. Efficiency

 Optimizes the use of system resources like memory, processing time, and bandwidth.

🔹 5. Maintainability

 Easy to update, fix bugs, or extend functionalities without affecting the entire system.

🔹 6. Scalability

 Capable of handling increased load or data without significant design changes.

🔹 7. Flexibility

 Can adapt to changes in requirements with minimal restructuring.

🔹 8. Robustness

 Handles unexpected inputs or conditions gracefully without crashing.

✅ Software Design Framework

A Software Design Framework defines the structure for transforming software requirements
into a design model that can be implemented in code.

📌 Diagram: Software Design Framework

+------------------------------------------------------+

| Software Design Framework |

+----------------+-------------------+-----------------+

| Data Design | Architectural | Interface |

| | Design | Design |

+----------------+-------------------+-----------------+

| Component-Level Design (Detailed) |

+------------------------------------------------------+

| Deployment Design (for physical systems) |

+------------------------------------------------------+You can draw this as a layered box diagram in

exams, showing relationships between components.

✅ Elements of Design Model

The design model contains several elements that collectively define the system's structure
and behavior.

🔹 1. Data Design

 Focuses on how data is stored, organized, and accessed.

 Includes data structures, database schema, and file formats.

 Ensures consistency, integrity, and security.

🔹 2. Architectural Design

 Defines the overall structure of the system.

 Specifies main components, their relationships, and data flow.

 Example architectures: Layered, Client-Server, Microservices, etc.

🔹 3. Interface Design

 Describes how system components interact with each other and with users.

 Includes UI design, API specifications, and communication protocols.

 Aims for intuitive and efficient interaction.

🔹 4. Component-Level Design

 Focuses on the internal design of software components or modules.

  Details algorithms, methods, and control structures.

 Ensures cohesion, encapsulation, and reusability.

🔹 5. Deployment Design

 Describes how software will run on the target hardware environment.

 Includes hardware mapping, network configuration, and resource allocation.

 Important for distributed systems and performance optimization.

✅ Bonus Tip: Mnemonic for Elements

D-A-I-C-D → "Data Always Integrates Clean Deployment"