UML Object Diagrams

An object diagram is a snapshot: it shows specific objects that exist at one moment, the values in their fields, and the links between them. Where a class diagram says what can exist, an object diagram says what exists right now. Developers, testers and analysts read it to check a class model against a concrete case.

1. What an Object Diagram Shows

Every object diagram is an instance of some class diagram. Each box is one object, written name : Type and underlined. Instead of attribute types, the box lists slots with actual values. Lines between objects are links: one concrete instance of an association declared in the class diagram.

Because the values are real, an object diagram is the quickest way to test whether a class model makes sense. If you cannot draw a believable snapshot of your model, the model is probably wrong. Object diagrams are also a good way to explain a data structure, a test fixture, or the state of memory just before a bug.

2. Notation

Object Diagram Notation Class (the type) Order status: Status total: Money compartments hold types Object (an instance) order42 : Order status = PAID total = 59.90 name : Type, underlined; slots hold actual values Anonymous object : Customer no name, type only a : A placedBy b : B Link = one instance of an association. Plain line, optional role name; no multiplicity.

Four symbols cover almost everything. The object box has its name underlined to distinguish it from a class. You may drop the name and keep only : Type (an anonymous object) when the identity does not matter. Slots show attribute = value; you only list the slots relevant to the point you are making. A link is a plain line; multiplicities are not shown because each link is exactly one connection.

3. Example 1: An Online Shop Order

Online Shop: One Checkout, Frozen in Time alice : Customer id = 1017 email = alice@ex.com order42 : Order status = PAID total = 59.90 pay9 : Payment method = CARD amount = 59.90 li1 : LineItem qty = 2 price = 19.95 li2 : LineItem qty = 1 price = 20.00 mug : Product sku = MUG-01 tee : Product sku = TEE-M placed paidBy

Walkthrough: customer alice placed order42. The order owns two line items, each pointing at a product: two mugs and one T-shirt. Payment pay9 covers the order. Reading the slots lets you check the arithmetic: 2 × 19.95 + 20.00 = 59.90, which matches both the order total and the payment amount. That is exactly the kind of invariant an object diagram makes visible and a class diagram cannot.

4. Example 2: Library Loans

Library Loans: Checking a Tricky Rule bob : Member maxLoans = 2 l1 : Loan due = 2026-10-05 overdue = false l2 : Loan due = 2026-09-20 overdue = true c1 : Copy barcode = 8812 c2 : Copy barcode = 9034 Question the snapshot answers: may bob borrow a third copy? No: maxLoans reached, and l2 is overdue.

Walkthrough: member bob has two loans, each tied to a physical copy. Loan l2 is highlighted because it is overdue. A business rule says a member may not borrow while at the loan limit or while anything is overdue. The snapshot turns that rule into a concrete test case: given this state, a third checkout must fail. Many teams draw such snapshots straight into test fixtures.

5. Pros, Cons, and When to Use

Pros

Cons

When to use

When not to use

6. As Diagrams-as-Code

PlantUML supports objects directly with the object keyword. Paste this into the PlantUML server or an IDE plugin to render the shop example:

@startuml
object "alice : Customer" as alice {
  id = 1017
  email = "alice@ex.com"
}
object "order42 : Order" as order42 {
  status = PAID
  total = 59.90
}
object "li1 : LineItem" as li1 {
  qty = 2
}
object "li2 : LineItem" as li2 {
  qty = 1
}
object "mug : Product" as mug
object "tee : Product" as tee
alice -- order42 : placed
order42 -- li1
order42 -- li2
li1 -- mug
li2 -- tee
@enduml

Mermaid has no object diagram type; the usual workaround is a classDiagram with instance names as class names, which loses the underline convention.