A UML sequence diagram is useful when the main question is:
How do objects interact over time?
The diagram commonly includes:
For example:
controller1 : Controller
team1 : Team
These are object instances, not class definitions.
The class diagram can describe the Team type.
The sequence diagram shows a specific team1 participating in an interaction.
A message such as:
DisplayName()
can represent a method call from one participant to another.
The direction of the arrow identifies the receiver.
Messages nearer the top occur before messages below them.
This creates a readable execution story.
You can now compare:
Class diagram
What methods exist on the type?
Object diagram
Which objects and state exist?
Sequence diagram
Which objects call methods on which objects?
C#
What executable statements create and perform those interactions?
Do not attempt to diagram the entire application.
Choose the method calls needed to explain the behavior under study.
Later modules add:
Those features are not required for the first sequence diagram.