PSSM_ — PSSM shall be aligned with fUML 1.3 and PSCS 1.1

PSSM is not compatible with fUML 1.3 and PSCS 1.1. This is the consequence of the changes introduced by FUML13-23, FUML13-25, FUML13-16, FUML13-1, FUML13-60 and PSCS11-6. The description below provides an overview of the changes that must be performed in the PSSM semantic model in order to make PSSM comptabile with fUML 1.3 and PSCS 1.1. Note that these changes will also require an update of the PSSM document.

Update PSSM for fUML 1.3

There are four categories of changes needed to align PSSM with fUML 1.3 and PSCS 1.1:

1. Changes to the signature of the Object::send operation (see [fUML 1.3], 8.3.2.2.19, and issue resolution FUML13-23)
   This requires adjusting the implementation of DoActivityContextObject, which redefines the inherited send operation.
2. API changes introduced in the EventOccurrence class (see issue resolutions FUML13-25, FUML13-1, and FUML13-60)
   These API changes impact the specification of the trigger-matching semantics of CompletionEventOccurrence and DeferredEventOccurrence (see [PSSM 1.0b], 8.5.9). Specifically, a completion event cannot match a trigger since it is used to only trigger transitions with no triggers, and a deferred event occurrence merely delegates to the matching semantics of the deferred event. fUML now also provides the capability for an EventOccurrence to be sent through its own execution thread, but neither the CompletionEventOccurrence nor the DeferredEventOccurrence use this capability. Finally, the alignment with the new EventOccurrence API enables the refactoring of the code of StateActivation (canDefer, defer and notifyCompletion operations), SM_ObjectActivation (registerCompletionEvent operation), TransitionActivation (canFireOne and hasTrigger operations), StateMachineEventAccepter (isDeferred operation) and StateMachineSemanticVisitor (removal of the match operation).
3. Introduction of class CS_EventOccurrence in PSCS (see [PSSM 1.0b], 8.5.1.2.7, and issue resolution PSCS11-6)
   This requires refactoring EventTriggeredExecution (see [PSSM 1.0b], 8.5.10.1), StateMachineEventAccepter (see [PSSM 1.0b], 8.5.2) and SM_OpaqueExpressionEvaluation (see [PSSM 1.0b], 8.2) to account for the possibility of receiving an CS_EventOccurrence .
4. Handling of call events in fUML (see [fUML 1.3], 7.3.3 and 8.8, and issue resolution FUML13-16)
   Since fUML 1.3 now includes CallEvent, this no longer needs to be added in the syntax subset for PSSM (see [PSSM 1.0b], 7.5), and CallEventOccurrence and CallEventExecution (and all the associations in which they are involved) can be removed from the semantics for PSSM (see [PSSM 1.0b], 8.5.9).