*Generalizations

•

AcceptEventAction (from CompleteActions ) on page 245

*Description

AcceptCallAction is an accept event action representing the receipt of a synchronous call request. In addition to the normal operation parameters, the action produces an output that is needed later to supply the information to the ReplyAction necessary to return control to the caller.

This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

*Attributes

No additional attributes

*Associations

Issue 8145 -add subsets constraint


• returnInformation: OutputPin [1..1]	Pin where a value is placed containing sufficient information to perform a subsequent reply and return control to the caller. The contents of this value are opaque. It can be passed and copied but it cannot be manipulated by the model. {Subsets Action::output}

*Constraints

[1] The result pins must match the in and inout parameters of the operation specified by the trigger event in number, type, and order.

[2] The trigger event must be a CallEvent .

trigger.event.oclIsKindOf(CallEvent )

[3] isUnmarshall must be true for an AcceptCallAction .

isUnmarshall = true

*Semantics

This action accepts (event) occurrences representing the receipt of calls on the operation specified by the trigger call event. If an ongoing activity behavior has executed an accept call action that has not completed and the owning object has an event occurrence representing a call of the specified operation, the accept call action claims the event occurrence and removes it from the owning object. If several accept call actions concurrently request a call on the same operation, it is unspecified which one claims the event occurrence, but one and only one action will claim the event. The argument values of the call are placed on the result output pins of the action. Information sufficient to perform a subsequent reply action is placed in the returnInformation output pin. The execution of the accept call action is then complete. This return information value is opaque and may only be used by ReplyAction .

Note that the target class must not define a method for the operation being received. Otherwise, the operation call will be dispatched to that method instead of being put in the event buffer to be handled by AcceptCallAction . In general, classes determine how operation calls are handled, namely by a method, by a behavior owned directly by the class, by a state machine transition, and so on. The class must ensure that the operation call is handled in a way that AcceptCallAction has access to the call event.