You have now worked with three UML diagram types:
All three can describe the same soccer system.
They do different jobs.
A useful shortcut is:
Object diagram: What specific things exist right now?
Activity diagram: What happens next?
Class diagram: What kinds of things can the system represent?
An object diagram focuses on a snapshot.
For example:
![Activity diagram showing Start, then Read availability, then Is player available?, then [yes] Add player to list, then [no] Continue, then End.](Diagrams/0.3.CompareObjectActivityClass.Activity.DiagramsShowSpecificInstances.light.svg)
This diagram is not primarily about the internal field list for Player.
It is about the process.
Activity diagrams are useful when the important information is:
A class diagram describes kinds of objects.
For example:
![Activity diagram showing Is player available?, then [yes] Add to lineup, then [no] Continue.](Diagrams/0.3.CompareObjectActivityClass.Activity.DiagramsShowTypesStructure.light.svg)
Question answered:
The concept is related across all three diagrams.
The representation changes because the question changes.
An object diagram should not become a substitute for process flow.
A class diagram should not be filled with one particular player's current values.
An activity diagram should not become a list of every attribute in the system.
Using the wrong representation makes the model harder to interpret.
Choose the diagram based on the problem you are trying to understand.
A class diagram can define:
![Activity diagram showing Is player available?, then [yes] Include player, then [no] Exclude player.](Diagrams/0.3.CompareObjectActivityClass.Activity.DiagramsCanSupportOne.light.svg)
Those models are not duplicates.
They are complementary views.
The same class attribute:
isAvailable : boolcan correspond to a Boolean value in C#.
The object diagram shows the current value.
The activity diagram shows how the value affects flow.
C# provides executable instructions that create the object, store the value, and make the decision.
That creates a useful chain:
Class structure → Object state → Process flow → Program code
Use this table as a mental guide:
| Question | Diagram |
|---|---|
| Which specific objects exist? | Object diagram |
| What values do those objects currently have? | Object diagram |
| What action happens next? | Activity diagram |
| Which path is followed? | Activity diagram |
| What classes exist? | Class diagram |
| What attributes and types belong to a class? | Class diagram |
| How are kinds of objects structurally related? | Class diagram |
The strongest diagram is not the one with the most information.
It is the one that answers the current question clearly.