FUML13 — Refactor EventOccurrence to provide useful operations

The EventOccurrence class was introduced in fUML 1.2 as the parent of SignalEventOccurrence and InvocationEventOccurrence. However, as introduced, it has no operations. This means that, to operate on any EventOccurrence instance, it is necessary to check what the actual type of the instance is and then cast it to the appropriate subclass. This becomes increasingly cumbersome as additional subclasses are added in other specifications built on fUML (such as CallEventOccurrence for PSSM). It would be clearer and more extensible to have certain general operations defined abstractly for EventOccurrence, which could then have proper implementations in appropriate subclasses. Useful such operations would include at least one to match an EventOccurrence against a Trigger and one to extract any event data from an EventOccurrence.

Add operations to EventOccurrence

Other than for invocation event occurrences, the acceptance of an event occurrence is constrained to the case when they match a trigger. In fUML only accept event actions have triggers, and only for signal events, but specifications built on fUML (such as PSSM) may allow other model elements to have triggers (such as transitions in state machines) and allow other kinds of events on triggers (such as call events). Each kind of event occurrence has specific logic required to determine whether it matches a specific trigger and to extract any data embedded in it. Currently, fUML embeds this logic in classes specific to the handling of signal event occurrences, without providing a common interface for allowing other specifications to provide different logic for different kinds of event occurrences.

A better approach would be to provide a common interface of abstract operations in EventOccurrence for matching (match) and data extraction (getParameterValues). These operations would have different behaviors in different concrete subclasses of EventOccurrence, but they could be accessed consistently across all kinds of event occurrences. For fUML, this would then require providing such concrete behavior in the SignalEventOccurrence subclass, with corresponding updates to AcceptEventActionActivation and AcceptEventActionEventAccepter to take advantage of the new operations. (The operations would be essentially stubbed out in InvocationEventOccurrence.)

Note also that the matching of a signal occurrence to a signal event trigger that currently occurs in AcceptEventActionActivation::match uses the checkAllParents helper operation. This helper operations is currently in ActionActivation, since it is also used in ReadIsClassifiedObjectActionActivation::doAction. However, when the signal matching logic is moved to SignalEventOccurrence::match, ActionActivation is no longer a common superclass. In order to avoid repeating the definition of checkAllParents, this helper operation can be moved to the Value class. This allows the definition of a useful Value::isInstanceOf operation, which can be used in both SignalEventOccurrence::match and ReadIsClassifiedObjectActionActivation::doAction instead of calling checkAllParents directly, simplifying both of those operations.