Object Diagrams

The idea

What it is

An object diagram is a picture of specific objects in your program at one exact moment. A class diagram tells you what a BankAccount can have (an owner, a balance). An object diagram says “right now there is an account belonging to Alice with a balance of 500.” It fills in the real values.

Think of it like a class photo. The class diagram is the form every student fills in — name, age, grade — the same blank boxes for everyone. The object diagram is the actual photo on photo day: Alice, 14, Grade 9 standing next to Bob, 15, Grade 9. Same form, real people, frozen at one second in time.

The one sentence to remember

A class diagram is the blueprint (what every object could hold); an object diagram is a snapshot of real objects with their actual values at one moment. One blueprint → many possible snapshots.

Mechanics

How it works

A snapshot, not a blueprint

A class diagram is general and timeless: it describes every BankAccount that will ever exist. An object diagram is the opposite — it is specific and frozen in time. It captures the exact objects that are alive at one instant and the exact values they hold. If you paused your program and looked at memory, an object diagram is the picture you'd draw.

Instance notation: name : ClassName

Each real object is drawn as a box, and its title is written as objectName : ClassName. In real UML this whole title is underlined — that underline is the signal that says “this is one real instance, not a class.” The name before the colon is which object it is; the class after the colon is what kind of thing it is.

A class is the blueprint; an object diagram is a snapshot of real instances with actual values at one moment — one class, many objects. The object titles alice : BankAccount and bob : BankAccount are underlined to mark them as real instances; their accent-tinted boxes show values (balance = 500), not the grey blueprint's types (- balance: double).

Slots: the actual values

Inside each object box you list slots. A slot is one attribute with its real value filled in, written attribute = value — for example balance = 500. This is the big difference from a class box: a class box shows the attribute with its type (- balance: double), while an object box shows the attribute with its value (balance = 500). Types describe the shape; values describe this one object right now.

Links: instances of associations

Lines between object boxes are called links. A link is just one real connection between two specific objects. If a class diagram says “a `Customer` is associated with `Account`s,” an object diagram makes that concrete: “`alice` is linked to `account#42`.” So a link is an instance of an association, the same way an object is an instance of a class.

One blueprint, many snapshots

The same class diagram can produce endless object diagrams — one for every combination of real values your program might hold.
Two snapshots taken at different times look different even for the same object: alice's balance might be 500 now and 300 after a withdrawal.
An object diagram is therefore tied to a moment — change the moment and you get a new, valid picture from the same blueprint.

When an object diagram earns its keep

Reach for one when a structure is hard to picture in the abstract — a tree, a linked list, a graph of who-points-to-whom, or a tricky bug where you need to see the exact objects and links that exist at the moment things break. Drawing the real instances often makes the problem obvious.

Don't confuse it with a class diagram

If you see a type after a colon (balance: double) you're reading a class box. If you see a value after an equals sign (balance = 500) and an underlined name : Class title, you're reading an object box. Type = blueprint, value = snapshot.

Interactive prototype

See it. Build it. Break it.

A sandboxed, hands-on simulation — no setup, no install. Play with it as you read.

simulation › Object Diagrams

About this simulation

One small BankAccount class box (the blueprint) sits at the top. Press Snapshot A or Snapshot B to spawn two concrete object boxes below it — alice : BankAccount and bob : BankAccount — each with its own real values like balance = 500. The two buttons produce different values from the same class, so you can see one blueprint make many snapshots. Click the class box, any object box, or any value slot and a single fixed-height panel is rewritten with a plain-English note. Nothing scrolls or grows — only that one panel changes.

Hands-on

Try these yourself

Open the prototype above, predict what happens, then verify.

try 01

Read the blueprint, then take a snapshot

Open the prototype. At the top is the BankAccount class box — the blueprint, showing attributes with types (- balance: double). Now press Snapshot A. Two object boxes appear below: alice and bob, each with real values. Notice their titles are underlined name : BankAccount — that underline means “real instance.”

try 02

Same blueprint, different snapshot

Press Snapshot B. The same two object boxes reappear but with different values — alice's balance is no longer 500. This is the key lesson: one class diagram can produce many object diagrams. The blueprint never changed; only the moment-in-time values did.

try 03

Click a slot vs the class box

Click a value slot like balance = 500 and read the panel: it's the actual value this object holds right now. Now click the class box at the top and read again: it's the blueprint that says every account can have a balance. Feel the difference — value vs type, instance vs class.

In practice

When to use it — and what trips people up

When to reach for an object diagram

Use one when specific instances tell the story better than the general blueprint: to show an example configuration, to make a tricky data structure (a tree, a graph, a linked list) concrete, to explain a bug by drawing the exact objects and links alive at the failure point, or to test your class diagram by asking “can it actually produce a sensible snapshot?” It is a companion to the class diagram, not a replacement.

A quick sanity check for your design

Sketch one object diagram from your class diagram. If you can't fill in a believable set of values and links, your class diagram is probably wrong — a missing relationship, a bad multiplicity, or an attribute that doesn't belong. The snapshot exposes design holes fast.

What it gives you

Makes an abstract design concrete — real values and links are far easier to grasp than types alone.
Great for explaining tricky structures (trees, graphs, linked lists) or reproducing a bug at the exact moment it happens.
Acts as a test of a class diagram: if you can't draw a believable snapshot, the blueprint has a flaw.
Beginner-friendly — it looks like the program's actual data, so non-experts can read it.

Common mistakes

Captures only one moment — it can't show how the objects got there or what changes next.
Doesn't scale: a snapshot of hundreds of live objects becomes an unreadable wall of boxes.
Easy to mistake for a class diagram if you forget the underline and the value slots.
Quickly goes out of date — the very next operation can make a different, equally valid diagram.

Reference

Code & further reading

A minimal reference implementation and pointers worth bookmarking.

snapshot.ts

// The class is the blueprint; the objects below are one snapshot.
class BankAccount {
  constructor(public owner: string, public balance: number) {}
}

// ---- take a snapshot: create specific instances ----
const alice = new BankAccount("Alice", 500);
const bob = new BankAccount("Bob", 1200);

// Object diagram for THIS moment:
//   alice : BankAccount   { owner = "Alice", balance = 500 }
//   bob   : BankAccount   { owner = "Bob",   balance = 1200 }

alice.balance -= 200; // a later moment = a DIFFERENT object diagram:
//   alice : BankAccount   { owner = "Alice", balance = 300 }

References & further reading

5 sources

Docsuml-diagrams.org
UML Object Diagrams — UML-Diagrams.org reference
The plain-reference for instance specifications, slots, and links, with the underline notation spelled out. Bookmark it as your lookup sheet.
Articlevisual-paradigm.com
What is an Object Diagram? — Visual Paradigm guide
A friendly, example-led walkthrough showing how an object diagram is built from a class diagram step by step.
Book
UML Distilled — Martin Fowler
The classic short book on UML. Fowler covers object diagrams as a quick, practical way to illustrate a class diagram with a concrete example.
Docsmermaid.js.org
Mermaid — Class Diagram syntax
Mermaid renders class structure as plain text in Markdown and GitHub; the same notation is the basis for sketching instances next to your code.
Articlegeeksforgeeks.org
Object Diagrams in UML — GeeksforGeeks
A beginner-level article with worked examples contrasting object diagrams against class diagrams.

Knowledge check

Did it land?

Quick questions, answers revealed on submit. Sign in to save your best score.

question 01 / 05

What does an object diagram show that a class diagram does not?

question 02 / 05

In an object box you see the title written as `alice : BankAccount`, underlined. What does that mean?

question 03 / 05

You're looking at two boxes. Box X has `- balance: double`. Box Y has `balance = 500`. Which is which?

question 04 / 05

How many different object diagrams can a single class diagram produce?

question 05 / 05

When is an object diagram the most useful tool to reach for?

0/5 answered