Understanding Software Module Cohesion Ranking

Cohesion in software engineering is a measure of how strongly related or focused the elements within a module are. A high level of cohesion is desirable because it indicates that a module performs a single, well-defined task. This makes the module easier to understand, test, maintain, and reuse. Conversely, low cohesion means a module performs unrelated or loosely related tasks, making it complex and harder to manage.

The different types of cohesion are ranked from best (most desirable) to worst (least desirable). Let's look at the types provided in the question and their typical ranking:

• Sequential Cohesion (B): Elements are grouped because the output from one element serves as the input for another element. The tasks are related through data flow. This is a very good type of cohesion.
• Communication Cohesion (C): Elements are grouped because they operate on the same input data or produce the same output data. The tasks are related by their use of common data. This is also a good type of cohesion, slightly less strong than sequential.
• Procedural Cohesion (E): Elements are grouped because they are executed in a specific order to achieve a specific goal, often involving control flow. The tasks are weakly related sequentially or temporally.
• Temporal Cohesion (D): Elements are grouped because they are all processed at the same time or at a similar point in time. For example, initialization or shutdown tasks. The tasks are otherwise unrelated.
• Logical Cohesion (A): Elements are grouped into a module because they fall into the same logical category, even if they are functionally different and only one element is executed at a time based on input parameters. For example, a module for "all output routines" regardless of what is being output. This is generally considered poor cohesion.

The standard ranking of these types from best to worst is:

1. Sequential Cohesion (B)
2. Communication Cohesion (C)
3. Procedural Cohesion (E)
4. Temporal Cohesion (D)
5. Logical Cohesion (A)

Therefore, arranging the given types from best to worst results in the order B → C → E → D → A.

This order aligns with the principle that tasks within a module should be as functionally related as possible (Sequential and Communication) rather than being grouped just by time (Temporal) or arbitrary category (Logical).

Here is a summary of the cohesion types mentioned and their position in the hierarchy:

Based on this ranking, the correct arrangement from best to worst cohesion is B → C → E → D → A.

Revision Table: Software Module Cohesion Types

Additional Information: Cohesion and Coupling in Software Design

Cohesion is often discussed alongside Coupling, another important concept in software design. While cohesion measures the strength of relationships *within* a module, coupling measures the strength of relationships *between* modules.

• High Cohesion: Good. A module does one thing well.
• Low Cohesion: Bad. A module does many unrelated things.
• Low Coupling: Good. Modules are independent and changes in one have minimal impact on others.
• High Coupling: Bad. Modules are highly dependent, making changes difficult and error-prone.

Good software design aims for high cohesion and low coupling. Achieving this balance leads to systems that are easier to develop, understand, test, and maintain.

Other types of cohesion not listed in the question include:

• Functional Cohesion: (Considered the best type overall) Elements contribute to a single, well-defined task or function.
• Coincidental Cohesion: (Considered the worst type overall) Elements are grouped arbitrarily with no meaningful relationship between them.

Understanding these types helps in designing modular, maintainable, and robust software systems.