SYSML2_ — Textual notation for send actions is too limited

According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

send payloadExpression via senderExpression to receiverExpression

In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

Revise send and accept action notation

This resolution improves the expressiveness of send action usage syntax, as suggested in the issue, while still maintaining the parsability of send action usages used as entry, do or exit actions, or used as transition effect actions.

It is possible to make the payloadExpression optional, as well as allowing parameters to be bound in the body of the send action usage, rather than using the special notation in the declaration header. However, since parameters must be redefined in order, if the sender and/or receiver parameters are bound (in the header or in the body), then the initial payload parameter must also be redefined, even if no value is provided for it. Therefore, this resolution proposes to allow send action usage notation of the following form, in which all parameters are bound in the send action usage body:

send {
    in payload = payloadExpression;
    in sender = senderExpression;
    in receiver = receiverExperssion;
}

as well as the following mixed forms.

send payloadExpression {
    in sender = senderExpression;
    in receiver = receiverExpression;
}

and

send payloadExpression via senderExpression {
    in receiver = receiverExpression;
}

Further, instead of using feature values, values can also be provided for the nested parameters by using either flows or binding connections outside the send action usage. In addition, in the form

action actionName send via payloadExpression to receiverExpression;

the payload parameter is also implicitly redefined, but it can still be referred to by name (e.g., actionName.payload), for use as the target of a flow or binding connection.

For consistency, this resolution also proposes a similar update to the syntax for accept action usages. The current syntax is

accept triggerDeclaration via receiverExpression;

The proposal is to allow the receiver parameter (but not the triggerDeclaration, which declares an output parameter) to be redefined in the body of the accept action usage, so it can be given a value using an explicit binding or flow. The proposed notation has the form:

accept triggerDeclaration {
    in receiver = receiverExpression;
}