An object instance tells you which specific thing is being represented.
Fields tell you selected information about that object.
For example:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
position = "Forward"
isAvailable = true
The object is player1.
Its type is Player.
The fields shown are:
namejerseyNumberpositionisAvailableThe values shown are:
"Jordan"7"Forward"trueTogether, those values describe part of the object's current state.
A useful reading habit is to turn each row into a sentence.
name = "Jordan"
becomes:
The
namefield currently has the value"Jordan".
jerseyNumber = 7
becomes:
The
jerseyNumberfield currently has the value7.
isAvailable = true
becomes:
The
isAvailablefield currently has the valuetrue.
Reading the diagram this way keeps the field name and its current value separate.
A field name should help explain what the value means.
Consider:
7
By itself, the number is ambiguous.
It could represent:
The field name provides the context:
jerseyNumber = 7
Now the meaning is much clearer.
A UML object diagram may show several kinds of simple values.
name = "Jordan"
position = "Forward"
Quotation marks help show that the values are text.
jerseyNumber = 7
goals = 2
isAvailable = true
The field's name should make the meaning of the Boolean value understandable.
isAvailable = true
is clearer than a vague field such as:
status = true
Suppose two players have different availability.
player1 : Player
-------------------------
name = "Jordan"
isAvailable = true
player2 : Player
-------------------------
name = "Casey"
isAvailable = false
The field name isAvailable appears in both objects.
The values are independent because the objects are different.
Do not read the field as one shared value for every Player.
Each object instance has its own current state.
Suppose Jordan becomes unavailable.
Earlier snapshot:
player1 : Player
-------------------------
name = "Jordan"
isAvailable = true
Later snapshot:
player1 : Player
-------------------------
name = "Jordan"
isAvailable = false
The object is still player1 : Player.
The state changed.
Object diagrams can therefore help you reason about how the same object looks at different moments.
A soccer player has many characteristics in the real world.
A lineup model may need:
It probably does not need:
UML does not require you to fill the object box with every fact you know.
Abstraction still applies.
The diagram should display the fields needed to communicate the current purpose clearly.
Suppose the diagram has both a player and a match.
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
match1 : Match
-------------------------
opponent = "Rangers"
location = "North Field"
The player's jersey number belongs with the player object.
The match location belongs with the match object.
A clear model puts information with the object it actually describes.
This becomes especially important as diagrams grow.
Fields describe an object's own state.
They do not always explain how one object is connected to another.
For example, the player object may show:
name = "Jordan"
and the team object may show:
name = "Wildcats"
A relationship line can communicate that the specific player belongs to the specific team.
That relationship is different from simply repeating the team name as text inside every player.
The next part of object-diagram reading is understanding those object references and relationships.