Unit 5: Class Diagrams: Structure II
Learning Objectives
- Distinguish between inheritance, aggregation, and composition and apply them correctly
- Explain cohesion and coupling as measures of design quality
- Identify common design weaknesses in a class model and suggest improvements
Core Input
Read through each tab before moving to the key concepts.
Beyond basic associations, UML class diagrams support three specialised relationship types:
- Inheritance (Generalisation) — drawn as a solid line with a hollow triangle arrowhead pointing to the parent class. Represents an is-a relationship: a Dog is an Animal. The child class inherits all attributes and operations of the parent, and can add its own.
- Aggregation — drawn as a solid line with a hollow diamond at the whole end. Represents a has-a (weak whole-part) relationship where the parts can exist independently of the whole. A Library has Books, but Books can exist without the Library.
- Composition — drawn as a solid line with a filled diamond at the whole end. A strong whole-part relationship where the parts cannot exist without the whole. A House is composed of Rooms — destroy the House and the Rooms cease to exist.
Two fundamental design quality measures apply to class diagrams:
- Cohesion — how focused a class is on a single, well-defined responsibility. A highly cohesive class does one thing and does it well. A class that handles user input, database access, business logic, and report generation has low cohesion — it is doing too much.
- Coupling — the degree to which one class depends on another. Low coupling is desirable: a class that can be changed without forcing changes in many other classes is easier to maintain. High coupling means a change anywhere ripples through the whole system.
The goal in class design is high cohesion and low coupling.
Design smells are patterns in a class model that suggest poor design — warning signs that the model may be hard to maintain, extend, or understand.
- God Class — one enormous class with dozens of attributes, operations, and associations to almost every other class. Violates single responsibility. Breaks cohesion.
- Feature Envy — a class that spends most of its operations accessing data from another class. This suggests the operations belong in the other class.
- Inappropriate Intimacy — two classes that access each other's private data directly, creating tight coupling. They know too much about each other's internals.
- Refused Bequest — a subclass that inherits operations from a parent but overrides most of them to do nothing (or to raise errors). Suggests the inheritance relationship is wrong.
Key Concepts: Advanced Relationship Types
These three relationship types are frequently confused. Work through each item carefully and note the distinctions.
Inheritance expresses an is-a relationship. Class B inherits from class A when every B is a kind of A — B shares all the characteristics of A and adds its own.
Example: Lecturer inherits from Person. A Lecturer is a Person. All attributes and operations of Person (name, email, getDetails()) apply to Lecturer. Lecturer adds its own (department, courseList, assignCourse()).
The is-a test: Before using inheritance, confirm the relationship holds in both directions in plain English. "A Lecturer is a Person" — true. "A Person is a Lecturer" — not necessarily true. If the reverse also holds, it is not an inheritance relationship.
Caution: Inheritance creates tight coupling between parent and child. Overuse of inheritance is a common design mistake. Prefer composition where the is-a relationship is not clearly justified.
Aggregation represents a has-a (weak) whole-part relationship. The whole contains parts, but the parts can exist independently.
Example: A Department aggregates Lecturers. A Lecturer belongs to a Department — but if the Department is dissolved, the Lecturer does not cease to exist. They simply move to another Department.
Notation: A hollow diamond at the whole end of the association line. Multiplicity is added as usual.
Aggregation is the weaker of the two whole-part relationships. In practice, many engineers use plain association for most relationships and reserve the diamond notations for cases where the whole-part relationship is explicit and important.
Composition represents a has-a (strong) whole-part relationship. The parts cannot exist independently of the whole. If the whole is destroyed, the parts are destroyed with it.
Example: An Order is composed of OrderLine items. An OrderLine has no meaning outside of an Order — it refers to a specific item in a specific order. If the Order is deleted, all its OrderLines are deleted too.
Notation: A filled (solid) diamond at the whole end.
Key distinction from aggregation:
Aggregation = parts can survive without the whole.
Composition = parts cannot survive without the whole.
Use these tests:
- Is it an is-a relationship? If yes, consider inheritance. Apply the is-a test in plain English. Be sceptical — inheritance is often overused.
- Is it a has-a relationship? If yes, decide between aggregation and composition.
- Can the part exist without the whole? If yes, use aggregation. If no, use composition.
- Is there no meaningful whole-part relationship? Use a plain association.
In early design stages, it is often fine to model everything as a plain association and refine to aggregation/composition/inheritance once the relationships are better understood.
Key Concepts: Design Quality
Design quality is not about taste — it is about how well a design will survive change. These concepts apply directly to what you can see in a class diagram.
Cohesion measures how tightly a class's responsibilities are focused. A highly cohesive class has a single, clear purpose — all its attributes and operations relate to that purpose.
A useful test: can you write a one-sentence description of what this class does?
- High cohesion: "The Order class manages the data and rules for a single customer order."
- Low cohesion: "The Manager class handles orders, sends emails, generates PDFs, manages users, and logs events."
In a class diagram, low cohesion is visible as a class with many unrelated attributes, or a very large number of operations, or associations to a wide range of other classes.
Coupling measures how much one class depends on others. Every association, parameter type, or return type creates a dependency. High coupling means a change in one class forces changes in many others.
In a class diagram, high coupling is visible as one class with associations radiating out to many others, or classes that access each other's internal attributes directly.
Why low coupling matters: Software changes. Requirements evolve. A class that depends on many others is expensive to modify and easy to break accidentally. Low coupling makes individual classes replaceable and testable in isolation.
A god class is a class that has grown to take on too many responsibilities. It typically has:
- A large number of attributes (often more than 10)
- A large number of operations (often more than 15–20)
- Associations to most other classes in the system
A god class creates a bottleneck: every developer needs to understand it; every change risks breaking something unrelated.
Fix: Apply the Single Responsibility Principle — identify the distinct responsibilities the class is handling and extract each into a new, focused class. The original class may then coordinate these smaller classes, or disappear entirely.
Feature Envy: A class has many operations that mostly use data from another class. This suggests those operations belong in that other class.
Example: A ReportGenerator class that has ten operations, all of which access attributes of Order. Most of those operations should probably be in Order itself.
Inappropriate Intimacy: Two classes access each other's private state directly, bypassing encapsulation. This creates brittle coupling — any change to one class's internals breaks the other.
Refused Bequest: A subclass inherits operations from a parent but overrides them to throw errors or do nothing. This is a sign that inheritance was the wrong relationship — consider replacing it with composition or a completely separate class.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
A Car class contains an Engine class. If the Engine cannot exist without the Car, which relationship is most appropriate?
A class handles user input, database access, business logic, and PDF generation. This is an example of:
Activities
Individual task
Return to the shared class diagram from Unit 4. Review every association and identify at least two relationships that should be modelled as inheritance, aggregation, or composition rather than plain association.
For each one:
- State the relationship type you recommend
- Justify your choice — apply the is-a test or the "can the part exist without the whole?" test
- Update the diagram with the correct notation
Pair task
Review your partner's updated diagram for design quality:
- Is there any class that looks like it might be a god class? How many attributes, operations, and associations does it have?
- Are any classes doing things that seem to belong in another class (feature envy)?
- Do any inheritance relationships fail the is-a test?
Identify at least one design weakness and suggest a specific improvement.
Group task
As a group, select one class from your shared diagram that has been identified as problematic (ideally a god class candidate or a class with unclear responsibilities).
- Draw the before version of the class as it currently stands
- Redesign it — split responsibilities, add new classes if needed, adjust relationships
- Draw the after version and explain the improvement in terms of cohesion and coupling
Review
- Inheritance — is-a relationship. Hollow triangle arrowhead pointing to parent.
- Aggregation — has-a (weak). Parts can exist independently. Hollow diamond at whole end.
- Composition — has-a (strong). Parts cannot exist without the whole. Filled diamond at whole end.
Software is never finished — it is always being changed. A system with high cohesion and low coupling can be changed safely: modifying one class does not force changes elsewhere, and each class is simple enough to understand and test in isolation.
A system with low cohesion and high coupling accumulates technical debt — the cost of changes grows over time until the system becomes too fragile to modify. Good class design keeps that cost low.
Proceed to Unit 6: Sequence Diagrams when ready.