UML Object Diagram

The UML object diagram shows the instances (objects) of classes at a particular time in the running application or system. They are a snapshot of the object structure at this particular point in time. They are commonly used to describe exactly how the objects are related at this time and what exact valuese they have. Object diagrams are particlularly usfull in describing the state of the application so that understanding and debugging of complicated situations in algorithms and structure.

They can be used as a precursor to a sequence diagram (that also shows objects), showing the state just as the sequence diagram behavior is starting and/or the state when the behavior has executed.

Objects are shown with their type (class), attribute values with real data and possible links to other objects. The attributes and links are connected to the type (class) definition. I.e. the object cannot have links or attributes without the class defining them. The links are used to send messages and thus need to be formed for a sequence diagram to work.

Example

Lets consider a small application consiting of one class. Two objects are created, and a link between them is formed as one recieves the other as a parameter in a method.

In mermaid there is no dedicated diagram type for object diagrams, but the flowchart seems to be working ok (but notationwise not perfect, e.g. a missing line under the object:class name).

Let us consider the situation where one object alice is feeling great and john is not so good. At the moment when the method printFriendStatus is entered the object diagram would look like this:

Reflexive Relation Example

Object diagrams are particularly well suited to show examples of complex structures. Class diagrams can often become too simple or generic to provide the needed understanding.

In this example we use a Diety class that can have either 0 or two parents which are also Dieties. The class diagram would look something like this.

classDiagram

The implementation could look something like this:

While this looks simple enough quite complex structures can arise from this and often benefits from visualziation using object diagrams. Especially when manipulating the stucture in different ways.

Simple situation

Lets just consider a simple situation implemented like this:

The object diagram provides a way to visualize this exact situation and when the objects have been created it should look like this:

More complex

Things can quicly become more complicated:

The above situation can be visualzied using the following object diagram.

Object Names

As can be seen in the above the object names are not consistenly used. From a technical perspective every object has its uniqe identity i.e. the object name. However, this id is often not practical to use, instead it is common to a variable name as this maps more clearly to the actual implementation. The problem with this approach is that several variables can reference the same object. In the example above the variables john (local variable in main) and friend (method parameter) actually referene the same object. Then you need to select the name that makes the most sense in the context of what you want to show, this could even be to use an attribute as the name. For example the object named god_of_thunder could likey be named Tor instead, esp. since we likely do not want several dieties named Tor (though we technically are free to do this).

It is also rather common to have anonymous objects, at least if the actual names are not that important. Though this can make the model harder to understand and connect to an actual scenario. It it advicet to use at least a few onbject names.

Link Names

Link names are commonly not used, but it is an option to increase understanding of how the objects are linked. In the first example the objects are linked using the friend parameter. Links can also have a directio if this is important to show. There can be a tendency to just repeat the names of roles in the class diagram, and if so it makes little sense to add the link name.

However, link names are often needed if you have several link between objects of the same type so that you can know what object is linked using for the different roles. For example consider a Car class that has both an owner and a driver. The class diagram would look like this:

Implemented like this.

In this case it becomes important to use link names to know what the actual different links mean. Compare the two following object diagrams and you see that using link names is needed. In the first one we dont know which of the objects is the owner and which is the driver.

An alternative can be to use object names, but this approach would not work if we have a more complex model.