PSSM_ — Synchronous operation call on an active object ends if the corresponding call event occurrence was deferred

FUML 1.3 provides a support for the CallEvent semantics. When an object performs a synchronous operation call on an active object then a call event occurrence is placed in the event pool of the target (i.e. the active object that is the target of the call). While the target has not accepted the call and the RTC initiated by the acceptance is not completed, the execution thread in which the caller executes remains suspended.

In PSSM context, the target of the call can be an active object whose executing a classifier behavior described thanks to a state machine. This state machine can have states that declare a call event as being deferred. This means that when the state is active and such call event is dispatched then it is going to be accepted by the state machine. The acceptance leads the call event occurrence to be placed in the deferred event pool of the active object.

The problem here is that since the call event was deferred, this implies the operation call was not performed by the target. Hence the caller shall not be released before the call event gets "undeferred" (i.e., return back to the regular event pool). However, this is not what is specified in the StateMachineEventAccepter (see section 8.5.2 in [PSSM 1.0b]) semantics. Indeed, the acceptance of the call event occurrence systematically leads to release the caller. Instead, the caller shall only get released if the call event occurrence is used to trigger one to many transitions.

The problem can be highlighted through the test case Deferred007_Test provided through the PSSM test suite.

In this test, the call event occurrence corresponding to the op operation is dispatched when in configuration S1. This implies the state machine accepts and defers the event occurrence. At the end of the RTC step, the tester (i.e., the object that emitted the call) shall remain suspended. This shall be maintained until the end of the RTC in which the transition T6 is fired. To demonstrate this semantics, Deferred007 Test shall be refactored.

Update the StateMachineEventAccepter and test Deferred 007.

Rules that constrain the acceptance of an event by a state machine are specified in the accept operation of class StateMachineSemanticVisitor. The specification of this operation needs to be updated to ensure that the caller of an operation gets released only when the corresponding call event occurrence is accepted, not when it is deferred.

In addition, the test Deferred007_Test must be updated because it currently does not enable the assessment of the combined usage of a call event and deferral semantics. Indeed, as soon as S1 is deferred, the tester (i.e., the entity providing the stimulus) is suspended until the call event occurrence for the operation op is un-deferred and accepted. As Deferred007_Test will never receive a Continue signal event occurrence (since the tester is suspended), T3 will never have a chance to be fired, hence the state machine (and so the test) will remain stuck forever.

The issue can be resolved by giving S1 a do-activity behavior that is responsible for sending the Continue signal event occurrence to the test (i.e., the instance of Deferred007_Test). The Continue signal event occurrence will then be accepted by the state machine, T3 will be triggered and the call event occurrence will be un-deferred. This un-deferred event occurrence will then be used to trigger T6. Note, however, that this solution will only work if the call event occurrence is received before the Continue event occurrence.