PSCS11 — Behavior Ports should be able to handle CallEventOccurrences

In PSCS 1.0, when an Operation is dispatched to a behavior Port, it is ignored, because fUML 1.2 does not support CallEvents. However, PSSM allows StateMachines to have CallEvents on Triggers, and it should be possible to dispatch an Operation call through a behavior Port, as a CallEventOccurrence to be handled by a classifierBehavior that is a StateMachine.

Behavior Ports should be able to handle CallEventOccurrences

Note: The technical changes proposed to PSCS are dependent on issues resolved for fUML 1.3:

FUML13-16: Support for synchronous call of operations on active objects.
FUML13-1: SendSignalAction completion semantics.
­FUML13-60: Simplification to resolution of issue FUML13-1.

It also relies on the resolution specified for PSCS11-6. This resolution introduces the possibility to have any event occurrence associable with an interaction point.

Proposal: Enabling the possibility to dispatch an operation call on a behavior port requires to allow the creation of an execution when the dispatched operation arrives at a CS_InteractionPoint which is a manifestation of a behavior Port. The created execution must be a CS_CallEventExecution (a specialization of CallEventExecution – see FUML13-16). This latter is an execution that describes the production and the sending of a CS_EventOccurrence wrapping a CallEventOccurrence. The target of the sending is the owner of the interaction point which is the manifestation of the behavior port. The CS_EventOccurrence that is added to the event pool of the active object references this interaction point. This enables the classifier behavior that may accept this event occurrence to declare a trigger that identifies a Port from which the event occurrence might be accepted.

The introduction of such changes require to update both AcceptCallActionActivation (see FUML13-16) and CS_SendSignalActionActivation. Hence, a CS_AcceptCallActionActivation must be provided in order to enable a CallEventOccurrence to be unwrapped in the case a CS_Eventoccurrence is accepted. In the case of CS_SendSignalActionActivation, only an update to the doAction operation is required. This update enables the possibility to wrap the SignalEventOccurrence to a CS_EventOccurrence, to initialize this latter with the Port and the direction to which the event occurrence shall be propagated and to make this event occurrence responsible for the effective sending to the target. The sending will occur using specific operations sendInTo and sendOutTo provided by CS_EventOccurrence.

As CS_EventOccurrence is an active object (it specializes EventOccurrence – see FUML13-1 and FUML13-60). In order to specialize the classifier behavior inherited from EventOccurrence the doSend operation must be overridden in CS_EventOccurrence. The behavior specified for this operation enables to account for the direction and the port through which the event occurrence must be forwarded.