What is Cohesion in UML?

Cohesion in the context of **Unified Modeling Language (UML)** and software design refers to how closely related and focused the responsibilities of a single module, class, or component are. In simpler terms, it measures the degree to which the elements within a module (e.g., a class or component) belong together and contribute to the module’s purpose.
Purpose of Cohesion in UML

1. Enhance Maintainability: High cohesion simplifies maintenance because each class or module focuses on a specific, well-defined responsibility.
2. Improve Reusability: Modules with a single, focused purpose are more likely to be reusable in other contexts.
3. Increase Readability and Understandability: When a class or component has a clear responsibility, it becomes easier to understand and use.
4. Facilitate Testing: Highly cohesive classes are easier to test in isolation, as they perform a specific set of related functions.
5. Encourage Better Design Practices: Focusing on cohesion helps developers adhere to design principles such as the Single Responsibility Principle (SRP).

Function of Cohesion in UML In UML, cohesion is not explicitly depicted as a diagram element but is an underlying principle that guides how the model is structured. It can influence and be observed in:

• Class Diagrams: Each class should have attributes and methods that work together to perform a single function or represent a single concept.
• Sequence and Collaboration Diagrams: These diagrams should reflect cohesive interactions between objects, where objects perform well-defined roles.
• Component Diagrams: Components should encapsulate closely related functionalities, showing high cohesion.

Example

• A highly cohesive class: A Book class that contains attributes like title, author, and ISBN, and methods like getTitle(), getAuthor(), and getISBN(). All these attributes and methods are directly related to the concept of a "book."
• A low cohesion class: A Miscellaneous class that manages book details, handles user input, and processes payments. This mixes unrelated responsibilities, making the class difficult to maintain and understand.

Indicators of Cohesion

1. High Cohesion:
   • Methods and attributes within the module/class are strongly related to each other.
   • The class performs a single well-defined task.
2. Low Cohesion:
   • The module/class contains unrelated responsibilities.
   • It tries to do too much, often violating SRP.

By ensuring high cohesion in your UML diagrams and design, you contribute to a robust, scalable, and maintainable software system.

1. How big should an object be? How much information and behavior should be included in an object?
2. Should I combine two small objects into one?
3. Should I split a big object into smaller objects?

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.

1. Single Purpose: As an illustration, imagine you have the job description “programmer.” When all your duties relate to programming, you are very productive. But what happens when you are assigned other, less-related duties, like serving on a standards committee? What happens to your productivity? Objects are much the same. When objects have to handle multiple responsibilities, they become less flexible, incur the overhead of juggling unrelated tasks, and work less efficiently.
2. Flexibility: Organizations that require maximum flexibility and responsiveness tend to have the highest cohesion. Consider the military. Each person has a specific rank and job. Teams can be assembled at a moment’s notice. Members can be swapped in and out without disrupting the operation. Objects are much the same. High cohesion, a single purpose for each object, supports the rapid assembly of objects to create new components and applications. The cohesion principle applies equally to all levels of modeling abstraction, from objects to components to applications to subsystems to systems.

Conclusion So, with these things in mind, the answers to the questions listed at the beginning of this lesson are:

1. How much information should be included in an object? Answer: Only the information needed to support the object's single purpose.
2. When should you split an object? Answer: When the object is responsible for more than one purpose.
3. When should you merge multiple objects? Answer: When objects become fragmented and cannot fulfill a purpose without constantly asking for help from another object.

Click the Quiz link below to take a short multiple-choice quiz on cohesion.
Analysis Cohesion - Quiz