In the realm of Unified Modeling Language (UML) and software design at large, cohesion is a fundamental principle that speaks to the clarity, purity, and unity of purpose within a software module or component. When we refer to a module's cohesion in object modeling or software engineering, we're addressing the degree to which the responsibilities of that module form a meaningful unit.
Purpose of Cohesion in UML:
- Simplicity and Understandability: A highly cohesive module or class is easier to comprehend. When all the elements of a module are closely related and serve a singular purpose, it reduces the cognitive load on the designer or developer trying to understand or modify that module.
- Maintainability: Cohesive modules are generally more maintainable. Changes within such modules are less likely to produce unintended side effects in unrelated functions or operations, as everything in the module revolves around a central theme or purpose.
- Reusability: When a module has high cohesion, it's more likely that the module can be reused in other contexts or projects without significant changes, because it represents a well-defined and specific piece of functionality.
- Flexibility and Adaptability: Cohesive modules, due to their focused nature, can be more easily refactored or adapted to changing requirements, as compared to modules that have mixed concerns.
Function of Cohesion in UML
In UML, cohesion is often represented implicitly rather than explicitly. The function of cohesion in UML can be understood as follows:
- Class Design: In UML class diagrams, a class should represent a single concept. The attributes and operations of a class should be closely related. If a class is doing too much (i.e., has low cohesion), it might be a sign that it needs to be split into multiple classes.
- Package Cohesion: In UML package diagrams, each package should have a well-defined purpose and contain classes or other packages that are closely related. This ensures that the system's modular structure remains comprehensible and manageable.
- Sequence and Collaboration Diagrams: In UML sequence and collaboration diagrams, cohesive interactions ensure that each object plays a specific role in a scenario. High cohesion at this level implies that each participant in the sequence has a clear and focused responsibility.
- Component and Deployment Diagrams: Components or nodes should have a clear, cohesive role or function. A component or node that has a mixture of unrelated responsibilities may be a sign of poor cohesion.
Cohesion, as a principle, underscores the importance of keeping software modules focused and singular in purpose. In UML, this principle guides the design of classes, packages, interactions, components, and deployment nodes. Adherence to cohesion not only improves the understandability and maintainability of a system but also enhances its structural integrity and resilience against changes.
Cohesion is a measure of the degree to which all the parts of an object support a single purpose. High cohesion means that all the elements in the object support the same purpose. Low cohesion means that different elements support different purposes. Cohesion may be applied to any entity, not just objects which include operations, applications, components, subsystems, and systems.
So, with these things in mind, the answers to the questions listed at the beginning of this lesson are:
- How much information should be included in an object? Answer: Only the information needed to support the object's single purpose.
- When should you split an object? Answer: When the object is responsible for more than one purpose.
- When should you merge multiple objects? Answer: When objects become fragmented and cannot fulfill a purpose without constantly asking for help from another object.
