Software Designing (unit 3)
Module Design
❖ Definition:
Module design is the process of breaking down a software system into smaller, manageable, and
independent units called modules. Each module performs a specific task and can be developed, tested, and
maintained independently.
❖ Importance:
Promotes modularity and reusability
Makes testing and debugging easier
Enhances readability and maintainability
Facilitates team development
❖ Key Principles:
Single Responsibility: Each module should perform one task.
High Cohesion: Internal elements of the module should be closely related.
Low Coupling: Modules should be as independent as possible.
***Cohesion***
❖ Definition:
Cohesion refers to the degree to which the elements inside a module are related to each other. High
cohesion means the module has a single, well-defined purpose.
❖ Types of Cohesion (from lowest to highest):
1. Coincidental Cohesion: Randomly grouped tasks.
2. Logical Cohesion: Similar activities grouped together (e.g., input/output).
3. Temporal Cohesion: Tasks executed at the same time (e.g., initialization).
4. Procedural Cohesion: Tasks executed in a specific order.
5. Communicational Cohesion: Tasks operating on the same data.
6. Sequential Cohesion: Output from one task is input to another.
7. Functional Cohesion: All tasks contribute to a single, well-defined purpose.
❖ Goal:
High Cohesion is desirable for better maintainability and clarity.
, ***Coupling****
❖ Definition:
Coupling refers to the degree of dependency between modules. Low coupling is desirable as it indicates
modules are independent.
❖ Types of Coupling (from highest to lowest dependency):
1. Content Coupling: One module modifies another.
2. Common Coupling: Modules share global data.
3. Control Coupling: One module controls another's logic by passing control flags.
4. Stamp Coupling: Modules share complex data structures.
5. Data Coupling: Modules share only necessary data.
6. No Coupling: No direct interaction between modules.
❖ Goal:
Low Coupling improves modularity and reduces the risk of ripple effects during changes.
Object-Oriented Design Approach (OOD)
❖ Definition:
OOD is a design methodology that uses objects to model real-world entities. Objects encapsulate data and
behaviors.
❖ Key Concepts:
Class & Object: A class is a blueprint; an object is an instance.
Encapsulation: Data hiding using access specifiers.
Inheritance: Reuse of code from parent to child classes.
Polymorphism: Same interface, different behavior.
Abstraction: Hiding complex implementation details.
❖ Advantages:
Easier to model real-world problems.
Encourages reusability and modularity.
Enhances maintainability and scalability.
Function-Oriented Design Approach
❖ Definition:
Function-oriented design focuses on functions and processes rather than data. The system is designed as a
hierarchy of functions, with a main function decomposed into sub-functions.
Module Design
❖ Definition:
Module design is the process of breaking down a software system into smaller, manageable, and
independent units called modules. Each module performs a specific task and can be developed, tested, and
maintained independently.
❖ Importance:
Promotes modularity and reusability
Makes testing and debugging easier
Enhances readability and maintainability
Facilitates team development
❖ Key Principles:
Single Responsibility: Each module should perform one task.
High Cohesion: Internal elements of the module should be closely related.
Low Coupling: Modules should be as independent as possible.
***Cohesion***
❖ Definition:
Cohesion refers to the degree to which the elements inside a module are related to each other. High
cohesion means the module has a single, well-defined purpose.
❖ Types of Cohesion (from lowest to highest):
1. Coincidental Cohesion: Randomly grouped tasks.
2. Logical Cohesion: Similar activities grouped together (e.g., input/output).
3. Temporal Cohesion: Tasks executed at the same time (e.g., initialization).
4. Procedural Cohesion: Tasks executed in a specific order.
5. Communicational Cohesion: Tasks operating on the same data.
6. Sequential Cohesion: Output from one task is input to another.
7. Functional Cohesion: All tasks contribute to a single, well-defined purpose.
❖ Goal:
High Cohesion is desirable for better maintainability and clarity.
, ***Coupling****
❖ Definition:
Coupling refers to the degree of dependency between modules. Low coupling is desirable as it indicates
modules are independent.
❖ Types of Coupling (from highest to lowest dependency):
1. Content Coupling: One module modifies another.
2. Common Coupling: Modules share global data.
3. Control Coupling: One module controls another's logic by passing control flags.
4. Stamp Coupling: Modules share complex data structures.
5. Data Coupling: Modules share only necessary data.
6. No Coupling: No direct interaction between modules.
❖ Goal:
Low Coupling improves modularity and reduces the risk of ripple effects during changes.
Object-Oriented Design Approach (OOD)
❖ Definition:
OOD is a design methodology that uses objects to model real-world entities. Objects encapsulate data and
behaviors.
❖ Key Concepts:
Class & Object: A class is a blueprint; an object is an instance.
Encapsulation: Data hiding using access specifiers.
Inheritance: Reuse of code from parent to child classes.
Polymorphism: Same interface, different behavior.
Abstraction: Hiding complex implementation details.
❖ Advantages:
Easier to model real-world problems.
Encourages reusability and modularity.
Enhances maintainability and scalability.
Function-Oriented Design Approach
❖ Definition:
Function-oriented design focuses on functions and processes rather than data. The system is designed as a
hierarchy of functions, with a main function decomposed into sub-functions.
