UML: Class & Object Diagrams

Object Diagrams

18 min Lesson 8 of 10

Object Diagrams

A class diagram describes the template — the shape every instance of a class will follow. An object diagram goes one step further: it shows a snapshot of the system at one specific moment in time, with real instances holding real values. Where a class diagram says "every Patient has a name and a date of birth," an object diagram says "right now, there is a patient named Sara Ahmed born on 1990-03-14." Both diagrams use the same visual language, but they answer different questions.

Why Object Diagrams Matter to Analysts

Object diagrams are a powerful validation tool. After you draw a class diagram, you can challenge it by asking: "Can I produce a valid object diagram that represents a real scenario from the requirements?" If you cannot — because a multiplicity is wrong, a mandatory relationship is missing, or an attribute has no sensible value — the class diagram needs fixing. Object diagrams also serve as:

Test cases for the model — verify that the class structure supports every scenario the business described.
Communication with stakeholders — concrete named objects with real values are far easier for non-technical users to validate than abstract classes.
Starting points for test data — developers and testers can use object diagrams directly to write unit tests or seed a database.

Notation: The Underlined Name:Class Box

The rule is simple and absolute: in a UML object diagram every instance box has its name written as objectName : ClassName with the entire label underlined. This underlining is the only visual distinction between a class box and an object box — both are rectangles divided by horizontal lines. The compartments are:

Top compartment — the underlined objectName : ClassName label. The object name may be omitted if it is anonymous, giving : ClassName (still underlined).
Bottom compartment (slot list) — attribute slots, each written as attributeName = value. Only attributes with known or relevant values appear; others may be omitted.
Operations compartment — almost always suppressed in object diagrams; you show state, not behavior.

The underline is mandatory. Without it, the box looks like a class. Every UML tool and every textbook uses the underline to signal "this is an instance." When drawing by hand, underline the full name : Class string; do not underline just the name or just the class.

Left: the Patient class (template). Right: the object sara : Patient — an instance with real values, name underlined.

Links: Relationships Between Objects

In a class diagram, associations connect classes. In an object diagram, the corresponding connections are called links. A link is simply an instance of an association. You draw it as a plain solid line between two object boxes, optionally labelled with the association name or role. No arrowheads or multiplicities appear on the link itself — multiplicity is a class-level constraint, not something you show on individual instances.

A Complete Snapshot: Clinic Booking

Imagine the clinic system at 10:00 AM on a Monday morning. Two patients have booked appointments, one with Dr. Khalid and one still pending confirmation. The following object diagram captures that exact snapshot:

Object diagram snapshot: Monday 10:00 AM at the clinic — two patients, two appointments, one doctor, all with concrete values.

Reading the diagram. Every box with an underlined name : Class label is a specific instance. The lines between boxes are links — instances of associations. Notice that both appt1 and appt2 link to the same drKhalid object: one doctor, two bookings, which is exactly what the class diagram's 1..* multiplicity on the association allows.

Anonymous Objects

Sometimes you do not need to name an object; you just need to show that an instance of a certain class exists. You can write : ClassName (with the colon and class name underlined) to denote an anonymous instance. This is common when showing a collection of objects where individual names add no clarity, for example showing three anonymous : OrderItem objects linked to one order1 : Order object.

When to Use Object Diagrams

Object diagrams are not required on every project. Use them deliberately at these moments:

After completing a class diagram — validate the model by instantiating the most complex scenario from the requirements.
When a stakeholder questions a relationship — a concrete example with real names and values resolves ambiguity faster than abstract notation.
Before writing test data — hand the diagram to the QA team as a seed for their test database.
When multiplicity is in dispute — if the team disagrees whether a student can enrol in zero courses, draw the edge case as an object diagram and let the stakeholders decide.

Object diagrams show one moment — not all moments. A single object diagram cannot prove a class diagram is correct; it can only prove that one specific scenario is representable. You should draw at least two or three snapshots covering different states (e.g., an order before and after payment) to gain meaningful confidence in the class structure.

From Object Diagram Back to the Class Diagram

Object diagrams also help you discover missing classes. While drawing the clinic snapshot above, an analyst might realise that a TimeSlot class is needed to prevent double-booking — that insight came from trying to assign a concrete time value to the appointment. This reverse flow (object diagram reveals a gap, analyst fixes the class diagram) is a normal and healthy part of iterative modeling.

Summary

An object diagram is a named-instance snapshot of the class model at a specific point in time. Every instance box carries an underlined objectName : ClassName label and lists attribute slots with real values. Links (instances of associations) connect objects just as associations connect classes, but without multiplicity markers. Object diagrams validate class diagrams, communicate concrete scenarios to stakeholders, and seed test data. In the next lesson you will translate both diagrams directly into database tables and code structure.