The question has been answered nicely by @gnat's reference.
To add to the discussion, broadly, and then in the context of UML Sequence Diagrams, the following.
If your colleagues are calling 100 a parameter, they are using the term loosely, but still it is common to do so.
Even Wikipedia cites: The terms parameter and argument are sometimes used interchangeably, and the context is used to distinguish the meaning.
If you want to be even more precise, you can use the terms formal parameter vs. actual argument. I think that the shorter terms formal and actual are not as often interchanged as parameter an argument. Further, you might say the parameter's value is 100 rather than that 100 is a parameter.
As another data point, the the ANSI C standard cites terminology :
- actual argument
- actual parameter (deprecated)
and
- formal parameter
- formal argument (deprecated)
In the context of UML sequence diagrams, we see:
IBM describes amount as a parameter.
However, they describe 100 as the value the parameter will be, not as the parameter itself. Still, they seem use the term parameter as the thing being passed, though consistently with the notion of a name rather than a value (evocative of the notion of formal parameter despite describing it as that which is being passed).
Another text on sequence diagrams uses terminology like: substitute formal parameters with arguments, distinguishing between the two terms in the usual way.
Microsoft's texts on UML sequence diagrams defer the subject of discussion of parameters to UML class diagrams (and of course, in class diagrams the term parameter means formal parameter as there are no actuals in class diagrams).
From the Object Management Group; the UML Specification, we see terminology such as "The arguments of the Message correspond to the in and inout
ownedParameters of the Operation", and, "An argument of a Message is a ValueSpecification. If the Message has a signature and it is not a reply Message, then its argument ValueSpecifications are considered to be evaluated at the point of the send event of the Message. Their results provide the values for the corresponding Operation input parameters or Signal attributes."
Was my answer indeed wrong? Am I confusing terminology?
No, technically, you are correct.
However, as this is an area with a fair amount of grey, I would have answered yes, to be non-argumentative, it is a parameter, and immediately included with my answer that: with more precision, 100 is the actual parameter (though that term tends to be deprecated), aka actual or actual argument, more precisely, and, also that 100 is the value of the parameter being passed (or sent or received).
In the context of a specific programming language, they may define their own terminology (C, Java, C#, and even UML appear to all agree on formal parameter vs. actual argument), but in other contexts, the terminology should be seen as potentially somewhat interchangeable.
In programming languages we tend to think of the invoking caller and the receiving callee, so it is natural to think callee side as providing an evaluated argument list and then parameters as the variables of the invoked method.
However, in messaging, there is a reified notion of the message itself, as a piece of data or content, e.g. on the wire, in between being sent and received; think of XML or JSON. As such, I suppose that we tend to see parameters as something being passed or sent, because the content of the message often identifies the parameters by name along with the actual values being supplied.
