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:
player1belongs toteam1.
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.
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.
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.
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.
Real-world objects can be connected in many ways.
A player may be connected to:
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.
When reading a larger UML object diagram:
This prevents you from treating the diagram as a collection of disconnected boxes.
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.
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:
Jordan is represented by
player1, a Player object. Jordan is currently available.player1is connected to the Wildcats team represented byteam1, and that team is connected to the match represented bymatch1, which is against the Rangers at North Field.
That sentence is the meaning behind the diagram.
The boxes and lines are a compact visual way to communicate it.