0.2.13 Object References in UML Object Diagrams

Objects Become More Useful When They Are Connected

A soccer model can contain several individual objects:

player1 : Player
team1 : Team
match1 : Match

Those objects tell us what exists in the snapshot.

Relationships tell us how those objects are connected.

For example:

player1 : Player  --------  team1 : Team

The line represents a relationship between those two specific object instances.

In this model, the intended meaning might be:

A Relationship Connects Objects, Not Just Names

Consider this player:

player1 : Player
-------------------------
name = "Jordan"

and this team:

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

The relationship is between player1 and team1.

It is not merely between the text "Jordan" and "Wildcats".

This matters because computerized systems work with specific objects.

The relationship should preserve which particular object is connected to which other object.

References Preserve Identity

Suppose the same team has three players.

A diagram can show:

player1 : Player  --------\
                            \
player2 : Player  ---------- team1 : Team
                            /
player3 : Player  --------/

All three player objects are related to the same team1 object.

The team object does not have to be duplicated for every player.

That is one reason object relationships are useful: several objects can refer to one shared object.

Shared Objects Are Not Copies

Imagine the Wildcats team name changes in the model from:

"Wildcats"

to:

"Northwoods Wildcats"

If several player objects all relate to the same team1 object, the model still contains one team object whose state has changed.

That is different from storing a separate copied team description inside every player.

A relationship can communicate shared identity.

One Object Can Participate in Several Relationships

A team can relate to players and also to a match.

Conceptually:

player1 : Player  --------  team1 : Team  --------  match1 : Match

The same team1 object participates in both relationships.

This lets one diagram represent a network of connected objects.

A Relationship Should Have a Purpose

Real-world objects can be connected in many ways.

A player may be connected to:

  • a team;
  • a coach;
  • a match;
  • a school;
  • a family member;
  • a favorite professional club.

A particular diagram should include only relationships that help explain the modeled purpose.

For a lineup snapshot, team membership and match context may matter.

A player's favorite professional club probably does not.

The same abstraction decisions you used for fields also apply to relationships.

Follow the Lines Deliberately

When reading a larger UML object diagram:

  1. Start with one object.
  2. Follow each line leaving that object.
  3. Identify the object at the other end.
  4. Explain the connection in plain language.
  5. Continue outward only as far as the current purpose requires.

This prevents you from treating the diagram as a collection of disconnected boxes.

Relationship Lines Do Not Replace Field Values

Fields and relationships answer different questions.

A field such as:

jerseyNumber = 7

describes a value belonging to the player.

A relationship such as:

player1 : Player  --------  team1 : Team

connects the player to another object.

Both can be important.

The diagram becomes meaningful when you read object identity, values, and relationships together.

Reading a Complete Soccer Snapshot

Suppose a diagram contains:

player1 : Player
-------------------------
name = "Jordan"
isAvailable = true
team1 : Team
-------------------------
name = "Wildcats"
match1 : Match
-------------------------
opponent = "Rangers"
location = "North Field"

with relationships connecting player1 to team1 and team1 to match1.

A plain-language reading is:

That sentence is the meaning behind the diagram.

The boxes and lines are a compact visual way to communicate it.