UML Object Diagrams: An Agile Introduction
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.
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 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.