FUML13 — EventOccurrence should be used instead of SignalInstance in execution model operation parameters

The EventOccurrence class was introduced in fUML 1.2, with SignalEventOccurrence . However, the execution model classes Object, ObjectActivation and Reference still use SignalInstance as the type of various operations related to sending. These should be changed to EventOccurrence to allow other specifications built on fUML to specify the sending of other types of EventOccurrences (such as CallEventOccurrences in PSSM).

Change SignalInstance usage to EventOccurrence

In the current shape of the fUML semantic model, active objects can only perform event based communications using signals. This limitation is introduced by the way that: Reference, Object and ObjectActivation classes are defined. Indeed, these latter all provide a send(in signal: SignalInstance) operation which only enables a signalInstance to be sent to the event pool of an active object.

However, it became clear that extensions to fUML may need to support event based communications not limited to signal event occurrence. PSSM is good example of this with the introduction of a support for call event occurrence. In order to relax the constraint on the type of event based communications that can be performed between instance of active objects, the signatures and the implementations of the send operations provided by Reference, Object_ and ObjectActivation must be changed. This change consists in using EventOccurrence in place of SignalInstance in the signatures and implementations of the different send operations. Note that the doAction operation of the SendSignalActionActivation class will have to be updated to account for changes performed in Reference class.