You already know a parameterized C# method:
public void SetJerseyNumber(int number)
{
this.jerseyNumber = number;
}A call can supply an argument:
player1.SetJerseyNumber(7);A sequence diagram can represent that method call and the value being passed.
Conceptually:
controller1 ── SetJerseyNumber(7) ──> player1The message communicates:
The sequence diagram is showing a specific call.
The method definition contains:
int numberThat is the parameter.
The sequence message:
SetJerseyNumber(7)shows the argument supplied in this particular interaction.
That distinction matches the C# difference between:
public void SetJerseyNumber(int number)and:
player1.SetJerseyNumber(7);Suppose the diagram later shows:
SetJerseyNumber(12)That is another call to the same method with a different argument.
The method definition does not need a different parameter name.
The sequence diagram captures what value is sent during each interaction.
For:
SetJerseyNumber(7)the arrow should point to the Player object whose method executes.
Do not place the parameterized message on the wrong lifeline.
The receiver still matters just as it did for parameterless method calls.
If the method is:
public void SetAvailability(bool available)a sequence message might represent:
SetAvailability(true)Conceptually:
controller1 ── SetAvailability(true) ──> player1The argument tells the reader what information is sent to the Player.
Methods with multiple parameters are taught later.
For CO-039, use message labels such as:
SetJerseyNumber(7)
SetAvailability(true)Do not introduce several comma-separated arguments yet.
A class diagram will show that the method accepts a parameter.
A sequence diagram shows:
Those are related but different modeling jobs.