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.
A UML object is commonly drawn as a rectangle.
A simplified text version might look like this:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
isAvailable = trueIn 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:
The rows below the header show selected field values for that particular object.
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:
player1 : Player
-------------------------
name = "Jordan"
position = "Forward"
isAvailable = trueBefore looking at any relationships, identify:
Now you know what that one object represents.
Repeat that process for the other objects.
Imagine the diagram also contains:
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.
Once you understand the boxes and lines, turn the diagram into plain language.
For example, a small object diagram could communicate:
If you can explain the diagram accurately in ordinary language, you are reading the model rather than simply recognizing its symbols.
Object identity matters when several objects have the same type.
A diagram might contain:
player1 : Player
player2 : Player
player3 : PlayerAll 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.
An object diagram shows selected values at the moment being modeled.
Suppose:
player1 : Player
-------------------------
name = "Jordan"
isAvailable = trueLater, 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.
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.
When you open an object diagram, use this order:
This routine makes larger diagrams easier to understand because you are building meaning from smaller pieces.
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.