2 object diagrams, sometimes
referred to as instance diagrams, are useful for
exploring “real world” examples of objects and the
relationships between them. Although
UML class diagrams
are very good at describing this very information some
people find them too abstract – a UML object diagram can
be a good option for explaining complex relationships
For example, the object diagram of
Figure 1 explores the concepts
that a student can attend a seminar, be wait listed for
a seminar, or can be a teaching assistant within a
seminar. The diagram explores an example where John
Smith and Sally Jones are both students in
CSC 100a whereas Sarah McGrath is the
teaching assistant for it. Sarah is also the
teaching assistant in CSC 100b, Scott Ambler
is an enrolled student, and Ed Maloney is wait
listed. The diagram also shows that the two seminars
are both sections of the Introduction to Computer
Science course. This diagram makes the three
relationships between students and seminars, as well as
the relationship between seminars and courses, much more
Figure 1. Object diagram.
The notation used on UML object
diagrams is very simple - they show objects and the
connections between them. When you depict an object you
need to include enough information so that it is a
recognizable instance. As a result I will use one of
two formats: a single box named instance such as
Sarah McGrath: Student or a double box instance
listing one or more identifying attribute values in the
format attribute = value such as name = “Intro
to Computer Science”. Connections between objects
are shown as lines with roles, such as Teaching
Assistant, optionally indicated.
As you can see UML object diagrams
are effectively notational subsets of
diagrams, although object diagrams are used to explore
structure whereas communication diagrams explore
behavior. It is common for object diagrams to evolve
into communication diagrams simply by adding messages to
I will typically draw object
diagrams on white boards in order to explore the
relationships between objects. Once we’ve explored said
relationships we’ll use whatever we’ve learned to update
our class models or source code as appropriate then
erase the diagram (e.g.
Discard Temporary Models). Remember, the value
is often in the act of modeling and not in the model
itself. I have seen object diagrams retained as part of
the description of a complex business rule but this is
pretty rare in my experience.
This artifact description is excerpted from Chapter 8 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
The notation used in these
diagrams, particularly the hand
drawn ones, may not conform
perfectly to the current version
of the UML for one or more of
- The notation may have
evolved from when I
originally developed the
diagrams. The UML
evolves over time, and I may
not have kept the diagrams
up to date.
- I may have gotten it
wrong in the first place.
Although these diagrams were
thoroughly reviewed for the
book, and have been reviewed
by thousands of people
online since then, an error
may have gotten past of us.
We're only human.
- I may have chosen to
apply the notation in
An agile modeler is more
interested in created models
effectively than in
conforming to notation rules
set by a committee.
- It likely doesn't matter
anyway, because the
modeling tool(s) that
you're using likely won't
fully support the current
version of the UML notation
Bottom line is that you're
going to be constrained by
your tools anyway.
If you're really concerned
about the nuances of "official"
UML notation then read the
current version of the