Lesson 4 |
Cohesion |
Objective |
Define cohesion in the context of UML and software design. |
What is Cohesion in UML?
Cohesion in Unified Modeling Language (UML) and software design describes how closely related the responsibilities of a single class, component, or subsystem are.
It measures the degree to which internal parts work together to achieve a clear, single purpose. High cohesion contributes to maintainability, readability, and reusability, while low cohesion signals design problems and unnecessary complexity.
Why Cohesion Matters
- Maintainability – A cohesive class is easier to update or debug since it has one well-defined role.
- Reusability – Focused classes or components can often be reused in different systems.
- Readability – Developers understand and adopt cohesive code more quickly.
- Testability – Single-purpose classes are easier to isolate and test.
- Design Discipline – Encourages adherence to the Single Responsibility Principle (SRP).
Cohesion in UML Models
Although UML diagrams don’t show cohesion directly, the principle shapes how models are designed:
- Class Diagrams – Attributes and methods should all relate to one concept.
- Sequence Diagrams – Interactions should show objects collaborating in well-defined roles.
- Component Diagrams – Components should group only closely related functionality.
Examples
- High Cohesion: A
Book
class with attributes (title
, author
, ISBN
) and methods (getTitle()
, getAuthor()
, getISBN()
)—all focused on the concept of a book.
- Low Cohesion: A
Miscellaneous
class that stores book details, handles input, and processes payments. Mixing responsibilities makes the design confusing and hard to maintain.
Indicators of Cohesion
- High Cohesion:
- Methods and attributes strongly reinforce each other.
- The class fulfills a single, clear responsibility.
- Low Cohesion:
- Responsibilities are scattered and unrelated.
- The class violates SRP by attempting to “do everything.”
Practical Design Questions
- How much information and behavior should be grouped in one object?
- When is it better to split a large object into smaller, more cohesive ones?
- When should two small objects be merged to avoid fragmentation?
Real-World Analogy
Imagine a programmer whose only duty is writing code—they are highly productive. If that same programmer must also serve on unrelated committees and manage payroll, their productivity drops.
Objects are the same: focus increases efficiency, while mixed duties reduce flexibility and clarity.
Organizations like the military provide another analogy. Each individual has a clear role, and cohesive teams can be assembled quickly.
In software, high cohesion allows objects and components to be recombined flexibly to build new systems.
Conclusion
The key to effective cohesion is balance:
- Information Scope – Include only what supports the object’s single purpose.
- Splitting – Divide objects if they handle more than one responsibility.
- Merging – Combine objects if they are fragmented and cannot function independently.
OO Analysis Cohesion - Quiz

