What are Cohesion and Coupling?
Cohesion and coupling in software engineering are two important concepts that describe the relationship between the modules or components in a software system.
They are used to assess the quality of the design & to measure how well the system's components interact with each other.
Coupling represents the relationships between modules, and cohesion defines the relationships within them.
Difference between Cohesion and Coupling
In software engineering, cohesion and coupling are two key concepts that describe different aspects of how parts of a software system are related.
Cohesion
Cohesion in software engineering refers to how closely related the responsibilities and functions of a single module. In other words, it measures how well the elements within a module work together to achieve a single purpose. High cohesion means that a module has a clear, focused purpose and its parts are directly related to that purpose. This is desirable because highly cohesive modules are easier to understand, maintain, and test.
Example : Consider a module that handles all the operations related to user authentication, such as logging in, logging out, and managing passwords. If these tasks are all contained within one module, that module has high cohesion.
Coupling
Coupling in software engineering refers to the degree of interdependence between two or more modules in a system. It indicates how much one module relies on the details of another. Low coupling is preferable because it means changes in one module are less likely to impact others, making the system more flexible and easier to maintain.
Example : If a user authentication module is designed in such a way that it can work independently of other modules, such as the user profile or the database, then it has low coupling. This independence means that changes to the authentication module won't necessitate changes to other parts of the system.
Key Differences
1. Focus: Cohesion is about how closely related the elements within a module are. Coupling is about the relationships between different modules and how much they depend on each other.
2. Desirability: High cohesion is desirable because it means a module is focused on a specific task. Low coupling is also desirable because it allows modules to be changed without affecting others.
3. Maintenance: Systems with high cohesion and low coupling are easier to maintain and expand, as changes in one module are less likely to cause issues in others.
What is Cohesion in Software Engineering ?
Cohesion in software engineering is about how closely related the parts of a module are and how well they work together to achieve a specific goal. When a module has high cohesion, it means that all its components are connected and focused on performing one particular task. For example, if a module is responsible for user authentication, everything in that module should be related to logging in, logging out, or managing passwords.
On the other hand, low cohesion occurs when a module contains parts that don't necessarily belong together or serve different purposes. This can make the module confusing and harder to maintain or modify.
Good software design aims for high cohesion because it makes the system easier to understand, maintain, and extend. When modules are highly cohesive, it's clear what each part does, and changes in one module are less likely to affect others.
The concept of cohesion is closely tied to the Single Responsibility Principle (SRP), which suggests that a class or module should have only one responsibility or perform one specific task. This focus not only simplifies development and maintenance but also improves the overall quality of the software system.
What are the different types of Cohesion in Software Engineering?
The types of Cohesion in software engineering are:
1. Functional Cohesion
On of the types of cohesion in software engineering is functional cohesion that occurs when the elements within a module perform a single, well-defined task or a function.
All the elements within the module contribute to achieving the same objective.
This type of cohesion is considered the most desirable & strongest.
Examples - reading transaction records, cosine angle computation, seat assignment to an airline passenger, etc
2. Sequential Cohesion
Sequential cohesion occurs when the elements within a module are arranged in a specific sequence, with the output of one element serves as the input for the next element.
The elements are executed in a step-by-step manner to achieve a particular functionality.
Examples - cross-validated records and formatting of a module, raw records usage, formatting of raw records, cross-validation of fields in raw records, etc.
3. Communicational Cohesion
Communicational cohesion is anohter one of the types of cohesion in software engineering occurs when the elements within a module operate on the same input data or share data through parameters.
The elements within the module work together by passing data to each other.
It is weaker than sequential cohesion.
Example - usage of a customer account number, finding the name of the customer, the loan balance of the customer, etc.
4. Procedural Cohesion
Procedural cohesion occurs when the elements within a module are grouped based on a specific sequence of actions or steps.
This type of cohesion is weaker than the communicational cohesion.
Examples - Read, write, edit of the module, zero padding to the numeric fields, returning records, etc.
5. Temporal Cohesion
Temporal cohesion occurs when the elements within a module are executed at the same time or within the same timeframe.
It is considered weaker than the procedural cohesion.
Examples - Setting the counter to zero, opening the student file, clearing the variables of error messages, initializing the array, etc.
6. Logical Cohesion
Logical cohesion occurs when the elements within a module are logically related, but do not fit into any other cohesion types.
It is not strong as other cohesion types.
Examples - When a component reads inputs from tape, disk, and network, etc.
7. Coincidental Cohesion
Coincidental cohesion occurs when the elements are not related to each other.
Examples - Module for miscellaneous functions, customer record usage, displaying of customer records, calculation of total sales, and reading the transaction record, etc.
What is Coupling?
Coupling in software engineering refers to the degree of interdependence & connection between modules or components within a software system.
Two modules are said to have high coupling if they are closely connected.
In simple words, coupling is not just about modules, but the connection between modules and the degree of interaction or interdependence between the two modules. If two modules contain a good amount of data, then they are highly interdependent.
If the connection between components is strong, we speak about strongly coupled modules; when the connection is weak, we speak about the loosely coupled modules.
What are the different types of Coupling in Software Engineering?
Here are the 6 types of coupling in software engineering:
1. Data Coupling
Data coupling is a type of coupling in software engineering that occurs when modules share data through parameters or arguments.
Each module maintains its own data and does not exactly access or modify the data of other modules.
This type of coupling promotes encapsulation & module interdependence.
2. Stamp Coupling
Stamp coupling is a weaker form of coupling where modules share a composite data structure, but not all the elements are used by each module.
As the data and elements are pre-organized and well-placed beforehand, no junk or unused data is shared or passed between the two coupling modules which improves the efficiency of the modules.
3. Control Coupling
Control coupling is one of the types of coupling in software engineering occurs when one module controls the behavior of another module.
This type of coupling implies that one module has knowledge of internal workings & decisions or another module, that makes the code more difficult to maintain.
4. External Coupling
External coupling measures the degree to which the system relies on external entities to fulfill its functionality or interact with the external environment.
Low external coupling - Changes in the external entities have little impact on internal implementation of the system.
Medium external coupling - Changes in the external entities require some modifications within the system to accomodate new interfaces.
High external coupling - Changes in the external entities have a substantial impact on internal implementation of the system, requiring extensive modifications.
5. Common Coupling
Common coupling occurs when two or more modules in the system share global data.
The modules can access & manipulate the same global variables & the data structures.
6. Content Coupling
Content coupling is another type of coupling in software engineering that occurs when one module directly accesses or modifies the content of another module.
This type of coupling is strong & undesirable since it tightly couples the modules, making them highly independent on each other's implementation.
What is the relationship between Cohesion and Coupling in software engineering?
The relationship between coupling and cohesion in software engineering can be determined by these factors:
Inverse Relationship - When Cohesion is high, Coupling tends to be low. High Cohesion means that the elements within a module are closely related & work together to achieve a defined purpose.
Design Objective - High Cohesion & Low Coupling contribute towards improved maintainability, reusability, & the flexibility of the SAAS system.
Impact on Software Quality - High Cohesion contributes to better understandability, readability, & maintainability of the codebase. Low Coupling reduces the interdependencies between the modules.
Trade-Offs - Developers need to strike a balance based on the specific requirements & the constraints of the system.
What are the metrics for Cohesion & Coupling in software engineering?
These are quantitative measures for assessing the level of cohesion and coupling in software engineering. Here are some of the common metrics:
Cohesion metrics
1. Lack of Cohesion of Methods (LCOM)
Calculated by the number of disjoint sets of methods in the module.
A higher LCOM value indicates lower cohesion.
2. LCOM2
Calculated by the number of disjoint sets of methods - but provides a more refined measure of cohesion compared to LCOM.
3. Tight Class Cohesion (TCC)
Represents the proportion of method pairs that access the same attributes.
A higher TCC value indicates stronger cohesion in software engineering.
Coupling metrics
1. Coupling Between Objects (CBO)
CBO measures the no. of other classes or objects to which a class is coupled.
Higher CBO values suggest increased coupling & reduced reusability.
2. Response For a Class (RFC)
RFC measures the no. of methods in a class that can be executed in response to a message received by an object of that class.
Higher RFC values indicate higher complexity.
3. Depth of Inheritance Tree (DIT)
DIT measures the no. of levels in the inheritance hierarchy for a class.
Higher DIT values suggest a deeper inheritance tree & increased coupling.
