Consider the word:
Player
That describes a kind of thing in a soccer system.
It does not identify one particular player.
Now consider:
player1 : Player
That describes one specific object instance.
The part before the colon identifies the object.
The part after the colon identifies its type.
Read it as:
player1 is an instance of Player.
This identity-and-type pattern is central to UML object diagrams.
A soccer team can contain many players.
A diagram might include:
player1 : Player
player2 : Player
player3 : Player
Each object has the same type, Player.
The objects remain separate because their identities are different.
Their values might also differ:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
player2 : Player
-------------------------
name = "Casey"
jerseyNumber = 1
The model represents two specific Player objects, not one Player definition.
The object identity and a field value can look similar, but they have different jobs.
For example:
player1 : Player
-------------------------
name = "Jordan"
player1 is the object's identity in the model.
"Jordan" is a value stored in the name field.
A different model might use another internal object identity while still storing "Jordan" as the player's name.
The object identity helps the model distinguish one instance from another.
The field value describes information about that instance.
Suppose the diagram contains:
player3 : Player
-------------------------
name = "Alex"
jerseyNumber = 10
player4 : Player
-------------------------
name = "Alex"
jerseyNumber = 10
The values happen to match.
The object identities do not.
The diagram therefore represents two distinct objects.
This is an important modeling idea:
Matching values do not automatically mean matching identity.
A computerized system often needs to distinguish specific objects even when their visible information is temporarily identical.
If an object is:
player1 : Player
you would expect the displayed fields to describe a player.
If another object is:
match1 : Match
you would expect fields that describe a match.
For example:
match1 : Match
-------------------------
opponent = "Rangers"
location = "North Field"
It would be unusual for a Match object to contain a jerseyNumber field because that information describes a player rather than a match.
The object type helps you interpret the values inside the box.
A single soccer snapshot might include:
player1 : Player
team1 : Team
match1 : Match
These are three object instances of three different types.
Together they can represent a richer situation than any one object can represent alone.
For example:
player1 can represent Jordan;team1 can represent the Wildcats;match1 can represent Saturday's match.Relationships can then connect those specific objects.
This is one of the most important distinctions to keep clear.
A class-oriented idea asks:
What information should a Player type be able to represent?
An object diagram asks:
Which particular Player objects exist in this snapshot, and what is true about them right now?
For this part of the course, keep your attention on the second question.
You are reading and creating diagrams of specific instances.
Whenever you encounter a UML object box, begin with its header.
For:
player2 : Player
ask:
player2PlayerOnly then move on to its field values and relationships.
That simple habit prevents a common beginner mistake: confusing one object instance with the general type it belongs to.