You have already used UML object diagrams.
An object diagram shows specific instances.
For example:
player1 : Player
player2 : Player
Those are two particular Player objects.
A UML class diagram answers a different question:
What kind of object is a Player, and what information should Player objects be able to contain?
Instead of showing player1 and player2, a class diagram can show the Player class itself.
Compare these two ideas.
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
This shows one specific object and its current values.
Player
-------------------------
name
jerseyNumber
This describes the kind of information Player objects can have.
The class is not one particular soccer player.
It is the model for a category of objects.
A class diagram can represent:
At this stage, focus on structure rather than behavior.
For a simple soccer system, a class model might include:
Player
Team
Match
These are kinds of things the software may need to represent.
A class box begins with the class name.
Conceptually:
+----------------------+
| Player |
+----------------------+
| name |
| jerseyNumber |
| isAvailable |
+----------------------+
The upper section identifies the class.
The attribute section identifies selected information objects of that class can contain.
Later programming courses will add more class-diagram detail.
For now, the important distinction is:
class name → kind of object
attributes → information that kind of object can store
An object diagram might say:
name = "Jordan"
jerseyNumber = 7
A class diagram usually describes the attribute itself rather than one current object's value.
For example:
name
jerseyNumber
The class says Player objects can have a name and jersey number.
It does not say that every Player object is Jordan or wears number 7.
If the class is:
Player
the program could later contain many Player objects:
player1 : Player
player2 : Player
player3 : Player
The class defines the shared structural idea.
The objects are the specific instances.
This is one of the most important reasons class models are useful.
They let a designer describe the common structure once.
A soccer model may contain:
Player
Team
Match
A class diagram can show that Player and Team are related.
Conceptually:
Player -------- Team
This means Player objects and Team objects participate in some modeled relationship.
At this stage, the important idea is not advanced relationship notation.
It is that the class diagram describes which kinds of objects can be related, rather than showing only one specific pair of current objects.
A real soccer player has many characteristics.
The software may need only:
The Player class diagram should include the attributes required by the model's purpose.
It should not become a catalog of everything that could possibly be known about a person.
The same abstraction decisions you used for object diagrams still apply.
When you see:
Player
-------------------------
name
jerseyNumber
isAvailable
read it as:
A Player is a kind of object that can contain a name, jersey number, and availability value.
When another class appears:
Team
-------------------------
name
read it as:
A Team is a kind of object that can contain a name.
The relationship between the classes can then communicate that players can be associated with teams.
A class diagram might define:
Player
-------------------------
name
jerseyNumber
An object diagram might later show:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
The class diagram describes the type.
The object diagram shows one instance.
That connection becomes even more useful when the class attributes also include data types.