FUML15 — fUML should include unmarshall actions

Unmarshall actions are currently excluded from the fUML subset with the rational that they "redundant with unmarshalling a signal as received by an accept event action" (see subclause 7.11.1 in the fUML 1.4 specification). However, there are cases when it is useful to accept a signal without unmarshalling it initially (e.g., in order to be able to test its type), and then later unmarshall it. Further, unmarshall actions can be used for objects other than signals, providing a more convenient way to access object attributes than using multiple read structural feature actions.

Therefore, the rationale for excluding unmarshall actions from fUML is weak. They would also be very simple to specify (since their behavior is effectively already included in the specification for accept event actions with isUnmarshall = true). So, these actions should be included in fUML.

Add UnmarshallAction

Add UnmarshallAction to the fUML syntax subset and UnmarshallActionActivation to the fUML execution model.

In addition, fix the unmarshalling logic in AcceptEventActionActivation. The current logic does not properly handle the case when an accepted signal instance has a type that is a subtype of the signal declared for the triggering signal event. This is because SignalEventOccurrence::getParameterValues returns parameter values for all the attributes of the signal instance, which may be more than those of the signal supertype declared in the triggering signal event. The unmarshalling loop in AcceptEventActionActivation::accept then tries to unmarshall all the parameter values, but the number of result pins is determined by the number of attributes on signal declared in the signal event.