UML Object Diagrams: An Agile Introduction

UML 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 between classes.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 explicit.

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 UML communication 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 the diagram.

Remaining Agile

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.

Source

This artifact description is excerpted from Chapter 8 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese

Disclaimer

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 reasons:

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 “non-standard” ways. An agile modeler is more interested in created models which communicate 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 perfectly anyway. 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 UML specification.