UML object diagrams
A class diagram frozen at one instant, with real values instead of types. The cheapest way to find out whether a model you just drew actually works.
6 min readUML 2.5.19 of 15
01What it shows
An object diagram is a snapshot. Where a class diagramsays "a payment has an amount and zero or more refunds", an object diagram says "this payment, right now, is for 49.90 EUR and has one refund of 10.00".
It uses the same shapes as a class diagram with two changes, and those two changes are the entire notation:
- The name band reads
instanceName: ClassNameand is underlined. Either part can be dropped -p1alone, or: Paymentfor an anonymous instance - but the underline never is. It is what makes the box an object rather than a class. - Attributes become slots with concrete values:
currency = EUR, notcurrency: Currency.
02What changes from a class diagram
| Element | Notation | What it means |
|---|---|---|
| Instance | underlined name band | p1: Payment, : Payment, or p1. The underline is mandatory. |
| Slot | name = value | An attribute with an actual value, not a declared type. |
| Link | plain line | One instance of an association. Carries a role name if useful, but never a multiplicity. |
| No operations | omitted | Instances do not have their own operations - the class does. The third compartment simply is not used. |
03Why bother
Object diagrams are the least-drawn UML diagram and one of the most useful per minute spent, because they are a test for a class model.
Take a class diagram somebody is confident about and try to fill in one realistic instance of every box. Three things reliably happen. A multiplicity turns out to be wrong - the 1 that should have been 0..1, discovered the moment you have nothing to put there. A missing relationship appears, because two objects that obviously need to reference each other have no line between them. And an attribute that looked fine as a type turns out to have no sensible value, which usually means it belongs on a different class.
This takes about ten minutes and finds problems that survive months of discussion at the abstract level. It is the same reason writing one test case finds design problems that reading the design does not.
The second use is explanatory. A recursive or self-referential structure - a tree, a graph, a composite - is genuinely hard to understand from a class diagram, where it is one box with a line looping back to itself. Drawn as five concrete objects with links between them, it becomes obvious instantly.
04When to draw one
Reach for it when
- Validating a class diagram you are about to build from
- Explaining a recursive or self-referential structure that a class diagram obscures
- Documenting a specific tricky case - the order with a split payment and two refunds
- Preparing test fixtures: an object diagram is a picture of your seed data
Reach for something else when
- As a substitute for the class diagram - it shows one case, not the rules
- The structure is flat and obvious
- You would need six of them to cover the interesting cases; fix the class model instead
- The question is about behaviour over time - use a sequence diagram
In one line each
- 01An object diagram is one instant of a class diagram, with real values.
- 02Underlined name band is the notation; instanceName and className are both optional, the underline is not.
- 03Slots hold values (currency = EUR), not types.
- 04Links never carry multiplicity - a snapshot shows what is, not what could be.
- 05Its best use is as a ten-minute test of a class model you are about to build.
Related reading