0.2.9 Reading UML Object Diagrams

A UML Object Diagram Is a Snapshot

You have already used the ideas behind object modeling:

A UML object diagram brings those ideas together in a standard visual form.

Think of an object diagram as a snapshot of a system at one moment.

For a soccer system, the snapshot might answer questions such as:

An object diagram does not show every possible player or every possible match. It shows specific object instances that exist in the modeled situation.

Start With the Object Boxes

A UML object is commonly drawn as a rectangle.

A simplified text version might look like this:

Plain text
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
isAvailable = true

In a rendered UML object diagram, the object header is visually distinguished according to UML notation.

The header:

player1 : Player

contains two pieces of information.

Read the header as:

player1 is an instance of Player.

The rows below the header show selected field values for that particular object.

Read One Object Before Reading the Whole Diagram

When a diagram contains several objects, it is tempting to scan the whole picture at once.

A better approach is to read one object completely.

Suppose you see:

Plain text
player1 : Player
-------------------------
name = "Jordan"
position = "Forward"
isAvailable = true

Before looking at any relationships, identify:

Now you know what that one object represents.

Repeat that process for the other objects.

Then Read the Relationships

Imagine the diagram also contains:

Plain text
team1 : Team
-------------------------
name = "Wildcats"

and a line connects player1 to team1.

That line means the two specific objects are related in the modeled situation.

The surrounding context tells you what the relationship means. In this soccer example, the intended meaning is that player1 belongs to team1.

The relationship is not merely decoration. It carries information that would otherwise be missing.

Read the Diagram as a Sentence

Once you understand the boxes and lines, turn the diagram into plain language.

For example, a small object diagram could communicate:

Jordan is represented by player1, which is a Player. Jordan is a forward, is currently available, and is related to the Wildcats team represented by team1.

If you can explain the diagram accurately in ordinary language, you are reading the model rather than simply recognizing its symbols.

Follow Identity Carefully

Object identity matters when several objects have the same type.

A diagram might contain:

Plain text
player1 : Player
player2 : Player
player3 : Player

All three objects are instances of Player.

They are still three separate objects.

Their field values and relationships may differ.

Do not read Player as if it were one particular player. Player tells you the kind of object. The object name before the colon identifies the particular instance.

Values Describe This Snapshot

An object diagram shows selected values at the moment being modeled.

Suppose:

Plain text
player1 : Player
-------------------------
name = "Jordan"
isAvailable = true

Later, Jordan's availability might become false.

The object can still be player1 : Player.

The identity and type remain the same while the object's state changes.

This is why object diagrams are useful for showing a system at a particular moment.

Not Every Field Must Be Shown

A UML object diagram is still an abstraction.

A real player has far more information than the diagram needs.

If the purpose is to model lineup availability, the diagram may show:

It may leave out information that does not support that purpose.

Do not assume a field is missing simply because you know the real-world object has more characteristics.

Judge the diagram according to its purpose.

A Reading Routine

When you open an object diagram, use this order:

  1. Identify each object.
  2. Read each object's type.
  3. Read the field values shown inside each object.
  4. Follow the relationship lines.
  5. Explain the complete snapshot in plain language.
  6. Ask whether every displayed detail supports the stated purpose.

This routine makes larger diagrams easier to understand because you are building meaning from smaller pieces.

From Parcheesi to Soccer

You have already observed specific pieces, players, positions, and relationships in Parcheesi.

The same modeling idea applies to Soccer.

A particular soccer player is an object instance.

A particular team is an object instance.

A particular match is an object instance.

UML gives you a consistent notation for showing those instances and their current relationships without requiring you to describe the entire real-world system.