Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14)

The submission team for the Alf action language felt that it was important that the action language be able to support exceptions, since existing class models in UML may include operations that raise exceptions and it should be possible to use the action language to specify methods for such operations without having to change how errors are reported. However, without exceptions being included in the fUML subset, the mapping of the raising and handling of exceptions in the action language to fUML was too complicated and probably semantically questionable.

Therefore, support for the raising and handling of exceptions should be included in the fUML subset so that it can properly be included in the surface action language notation.

Add exception handling

The request to include exceptions in the fUML subset is one of the oldest that has not been resolved. As noted in the issue description, it was originally submitted against the FTF beta version of the fUML specification. Since then, the lack of support for exceptions has continued to be an impediment, particularly when using fUML for executable modeling for software. This lack often results in the use of poor workarounds, such as using "null" to represent an undefined or erroneous value, or other such "flagging" mechanisms – just the kind of things that exceptions were invented to avoid.

Further, exceptions are now also needed in fUML to support the proposed precise semantics SysML 1.7 (see https://issues.omg.org/browse/SYSML17-237), which will include an option in which constraint failure causes an exception to be raised. It is not considered feasible to add exception handling as just an extension for SysML 1.7 semantics.

And it turns out that adding exception handling to fUML is fairly straightforward, primarily just requiring a way to record the propagation of an exception up the call chain and new semantics for exception handlers. Specifically, this involves the following updates.

7. Abstract Syntax
7.5 Classification

• Add BehavioralFeature::raisedException. (Note that the UML specification does not give any formal constraints that would actually prevent the raising of exceptions not declared in the raisedException list. However, its inclusion would allow a tool to potentially do optional static checking for unexpected exception raising.)
• Add Operation::raisedException. (This is just a redefinition of BehavioralFeature::raisedException.)

7.10 Activities

• Add ExceptionHandler.

7.11 Actions

• Add RaiseExceptionAction.

8. Execution Model
8.3 Loci

• Update ExecutionFactory to add instantiation of RaiseExceptionActionActivation as the semantic visitor for RaiseExceptionAction.

8.8 Common Behavior

• Update Execution with semantics to propagate an exception raised during execution.

8.9 Activities

• Add (abstract) ExecutableNodeActivation with semantics for handling exceptions.

8.10 Actions

• Update ActionActivation with action-specific semantics for handling an exception.
• Update CallActionActivation with semantics for propagating an exception raised by the call execution.
• Add RaiseExceptionActionActivation with the semantics for raising an exception.

constraint 3 is a repetition of constraint 1

Restore fuml_class_active_class_classifier_behavior constraint

In the normative fUML_Syntax XMI for fUML 1.4, there are actually three constraints for Class (as there were in fUML 1.3). In subclause 7.7.2.2, constraint [1] should actually be fuml_class_active_class_classifier_behavior, as in the XMI.

[Editorial note: This subclause was incorrectly numbered 7.7.2.1 in the fUML 1.4 document.]

The constraint fuml_association_owns_memberEnds added to Association in 7.7.2.1 requires an association in fUML to own all its ends. While this simplifies association semantics, it is inconsistent with the default in most UML tools, which is to have association ends owned by the end types. Further, SysML requires that only non-navigable ends can be association owned (see SysML 1.5, 8.3.2.4 Block, Constraint 3).

Now, it is often sufficient to simply consider non-association-owned ends to be just regular attributes of their owning classifiers, ignoring the association, for the purpose of fUML semantics. Nevertheless, doing this loses any bidrectional semantics the association might have. And such a model is technically not fUML conformant.

Therefore, it would be better if fUML provided semantics for associations that did not own all their ends.

Allow associations with unowned ends

If there current constraint requiring associations to own their ends is simply removed, the current semantics already handles associations with unowned ends almost completely correctly. This is because it is already possible to perform structural feature actions on owned ends of associations as if they were features of the types of the opposite ends. The semantics works the same even if the ends are not owned by the association, including bidirectionality. The key to this is that if an association end is owned by an end type, then the values of that end are still maintained only in links of the association, not in feature values on instances of the end types.

There are only two additional actions that need to be considered:

• Reclassify object action: If an object is reclassified such that it losses a feature that is an association end, then all links from that object via that association end need to be destroyed.

• Unmarshall action: The values of any attribute of an unmarshalled value that is an association end needs to be obtained from the links of the appropriate association. (Unmarshall actions where added to fUML by the resolution of FUML15-13.)

While the fUML subset includes classes and associations, it currently does not include association classes. The original reason for this was that association classes can always be simulated using just regular classes, and keeping associations separate from classes made the fUML execution model simpler. However, when one uses a class instead of an association class, the effective end multiplicities do not reflect the association multiplicities, so the model is less clear. Therefore, it would be preferable to support association classes directly, along with the relevant link object actions on them.

Out of scope

The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

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.

The fUML subset currently specifically excludes streaming parameters (see constraint fuml_parameter_not_exception_not_streaming in subclause 7.5.2.5 of the fUML 1.4 specification). While the use of streaming parameters is not critical for the modeling of software behavior, it is very commonly used in SysML activity models. Indeed, there is currently work ongoing to specify precise execution semantics for SysML 1.7, which will need to include the semantics of streaming. But the semantics of streaming are not really specific to SysML, and would also be useful for modeling the equivalent of "lazy evaluation" of lists, even in software models. Therefore, the fUML subset should be updated to include streaming parameters and the semantics of streaming in the execution of activities.

Add semantics for streaming

Including semantics for streaming parameters in fUML was of interest from the time the standard was first developed. While it was decided not to include originally, the lack of streaming semantics has been increasingly detrimental to the use of fUML in the core area of model simulation. Further, much of the functionality need for streaming actually already exists in the current fUML execution model.

During the execution of an activity, the primary effect of using streaming parameters is on the semantics of call actions. When calling a behavior without streaming parameters, values on the input pins of the calling action are made available to the executing behavior, then the behavior executes to completion, after which any output parameter values are placed on the output pins of the calling action. On the other hand, if a behavior with input streaming parameters is called, then the behavior may continue executing even after all non-streaming inputs have been processed, in order to handle additional inputs that may be received through the streaming parameters. Further, if the behavior has streaming output parameters, then values posted to those parameters will be immediately offered from the output pins of the calling action, even while the behavior is still executing.

There is a close similarity between the semantics of calling an activity and the semantics of a structured activity node with a similar body to the activity. To a certain extent, the semantics of such a call can be thought of as being much like doing a “macro insertion” of the body of the called activity as a structured activity node at the point of the call. The semantic model for a structured activity node gives it an associated activity node activation group, similar to the activation group associated with a called activity. The activity node activation group for the structured activity node activation is created when the structured activity node activation fires.

In this semantic analog, the pins for non-streaming parameters on the call action are analogous to pins on the structured activity node. This means that the normal rules for firing and completing the structured activity node as an action apply to these pins. Extending this analogy to streaming, the pins for streaming parameters on the call action do not correspond to pins on the structured activity node, but, rather, the incoming object flows for streaming input parameter values pass directly into the interior of the structured activity node, and the outgoing object flows for output parameter values pass directly out. This reflects the semantics that, once the structured activity node has fired, tokens can pass freely in and out on these flows. The semantics of a call action with streaming parameters is analogous. Once the call action has fired, tokens can continue to pass in and out on the flows attached to pins corresponding to streaming parameters, during the execution of the called activity.

In the current semantic model for structured activity nodes, when a structured activity node activation fires, activity edge instances are also created at this time for the object flows that cross the structured activity node boundary. These edge instances directly connect pin activations outside the nested activity node activation group to those inside, allowing the flow of tokens regardless of the presence of the surrounding structured activity node. In order to allow such streaming semantics for call actions, it is necessary to create similar connections across the activity node activation group for containing the call action activation and the group for the called activity, in order to allow values to stream in and out of the called activity during its execution. The proposal here is to provide the necessary connections by allowing a streaming parameter value to have a registered listener. With this approach when values are posted to the streaming parameter, they are distributed to the registered listener.

• In the case of an input parameter, the corresponding activity parameter node creates a listener for itself and registers it with the appropriate parameter value. The call action input pin activation then continues to post values to the streaming parameter value as it receives them at any time during the execution of the call action, and these are then forwarded via the listener to the activity parameter node to be offered within the called activity.

• For an output parameter, the call behavior action creates a listener for its corresponding output pin activation. The activity parameter node activation for the output parameter within the called activity execution then posts values to the streaming parameter value as it receives them at any time during the activity execution, and these are then forwarded via the listener to the output pin activation to be offered within the calling activity. Note that there is no direct connection between the activity parameter node activation for an output parameter and the streaming parameter value object for that parameter. Instead, the activity parameter node activation obtains the appropriate parameter value from its activity execution when necessary to post new values.

In addition to new execution model class related to the listeners, this mechanism requires some significant changes to the specification of, particularly, the classes ActivityParameterNodeActivation, ActionActivation and CallActionActivation. However, the proposed streaming semantics are a clear extension of those currently specified for execution within an activity, and the adding this capability is entirely backwards compatible with previous fUML-conformant models that do not use streaming.

The UML specification the, for a DestroyObjectAction, "If isDestroyOwnedObjects is true, objects owned by the object through composite aggregation are destroyed..." [UML 2.5.1, 16.4.3.2] Clearly, this includes the case when one object "owns" another that is referenced in a composite property of the first object. It is less clear whether such ownership should also include an object linked to the first object by a composite association, in which the composite association end is owned by the association. However, it would seem likely that one would expect such objects to be included.

In fUML, the currently specified behavior for a DestroyObjectAction with isDestroyOwnedObjects = true is that composition links from an object being destroyed are always destroyed, but the object at the other end is not destroyed (see [fUML 1,4, 8.10.2.16 DestroyObjectActionActivation, operation destroyObject]). Note that such links are destroyed even if isDestroyLinks = false, which does not seem consistent with the UML specification. It would be more consistent if such linked objects were also considered "owned objects" and destroyed along with the owning object, just as if they had been referenced by a composite property of the owning object.

Update DestroyObjectActionActivation::destroyObject

The specification for DestroyObjectActionActivation::doAction actually includes the comment "If isDestroyOwnedObjects is true, destroy all objects owned by the referent via composition links", not even mentioning objects owned via attributes. The behavior of the action should be revised to destroy objects owned both via attributes and via links.

According to FUML13-16 the Class ReturnInformation should have following operations:

• getOperation
• copy
• equals
• getTypes
• new_
• reply
• specify
• toString

Obviously the text has been truncated, since in 1.4 only the first 3 are listed.

Add ReturnInformation operation descriptions

The submitter is correct, several operations for class ReturnInformation seem to have gotten lost in the restructuring of the specification document from 1.3 to 1.4. The operations are all in the normative fUML_Semantics XMI file for 1.4, though, so the descriptions just need to be added back into the specification document.

The class descriptions that were under Extra Structured Activities in the execution model in fUML 1.3 (ExpansionRegionGroup, ExpansionNodeActivation, ExpansionRegionActivation, TokenSet) were accidentally left out of the fUML 1.4 specification. The semantics of expansion regions are described in 8.10.1 in the fUML 1.4 specification, and the classes are shown in Figure 8.34 in that subclause. Descriptions of these classes should have been included in 8.10.2.

Add missing descriptions for expansion region activations

The following subclauses from the fUML 1.3 specification (formal/17-07-02)

• 8.5.5.2.1 ExpansionActivationGroup
• 8.5.5.2.2 ExpansionNodeActivation
• 8.5.5.2.3 ExpansionRegionActivation
• 8.5.5.2.4 TokenSet

should be added to the fUML 1.5 specification as subclauses 8.10.2.17, 8.10.2.18, 8.10.2.19 and 8.10.2.42 (after adjusting for the other added subclauses), respectively.

It should be made available a computer-readable version of the Base Semantics, as a CLF file. The place would be the OMG site where other files defined by this specification were available, such as, XML Metadata Interchange (XMI).

Defer

The fUML 1.5 RTF agrees that this issue should be resolved but, due to lack of time, is deferring it to a future RTF.

The specification should cover all ActivityNodes used in bUML. It should be added declarative definition for ActivityFinalNode because it is used in annex A.3.1, and A.3.2, pages 401, and 402. However, it should be evaluated the replacement of this node to FlowFinalNode. For the last, a proposal is defined

Defer

The fUML 1.5 RTF agrees that this issue should be resolved, but was not able to apply the necessary expertise to resolve it at this time, so is deferring it to a future RTF.

UML does not require that a model include signal receptions in order to send or accept signals. However, fUML adds the constraints SendSignalAction::fuml_send_signal_action_target_signal_reception (in 7.11.2.11) and AcceptEventAction::fuml_accept_event_receive_all_triggering_signals (in 7.11.2.2) that require the use of signal receptions for both sending and accepting signals. These constraints are entirely methodologically motivated, and they are unnecessary to the execution semantics for SendSignalActionActivation (in 8.10.2.33) or AcceptEventActionActivation (in 8.10.2.3), since both deal directly with signals (and their instances), not signal receptions.

Since UML does not itself require the use of signal receptions, they are often not use in practice by modelers, and having to add them just to be properly conformant with fUML is a nuisance. The constraints should be removed.

Remove constraints requiring receptions

It is agreed that the contraints SendSignalAction::fuml_send_signal_action_target_signal_reception and AcceptEventAction::fuml_accept_event_receive_all_triggering_signals should be removed.

Is: Inv(x: Real, y: Real)
Should be: Inv(x: Real) : Real

Correct Inv in Table 9.4.

The specification of the Inv function is correct in the normative library XMI, but, as described in the issue, this is shown incorrectly in Table 9.4 in 9.3.3. This should be corrected.

Interruptible activity regions are currently excluded from the fUML subset "because they are considered to be more appropriate for 'higher level' process modeling and outside the scope of fUML" (see subclause 7.10.1 of the fUML 1.4 specification). However, in the specification of the detail behavior of an asynchronously running activity, it is often useful to be able to break out of some ongoing behavior when some event is accepted. Using an interruptible region is the most convenient way to do this, and this is not really "higher level" process modeling.

Indeed, using interruptible regions in this way is common in SysML activity models. And current ongoing work on specifying the precise semantics of SysML 1.7 will need to include the semantics of interruptible regions. However, since this semantics is not really specific to SysML, it would be better if it was specified within fUML.

Out of scope

The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

Subclause 8.9.1 of the fUML 1.4 speification describes the "threading model" for concurrent execution of actions within an activity. Currently, this is an "implicit" threading model, in the sense that a "thread" is simply a sequence of operation calls between action activation objects. There is no explicit class in the execution model that represents such a "thread" (as opposed to, for example, the explicit model for the execution of a behavior).

While this is sufficient for the purposes of defining the semantics of activities as currently defined in fUML, it can be problematic in some cases for building additional semantics on this foundation. For example, in order to define the semantics of timing of execution within an activity (as required to respond to the currently open Precise Semantics of Time RFP), it would be very helpful to have a reified model of threads to which time semantics could be attached. This would also simply the current modeling of suspension and resumption of threads due to accept event actions.

So, while a refactoring of the fUML execution model to introduce an explicit threading model would not introduce any functional change to fUML itself, it would allow fUML to be a better foundation on which to build other precise semantics standards.

Defer

The fUML 1.5 RTF agrees that this issue should be addressed. However, more analysis is necessary to consider if such a sweeping change can actually be made without functionally changing the execution semantics. The RTF has decided to defer resolution of the issue until this analysis can be done.

According to UML semantics, "when an object is destroyed, it is no longer classified under any Classifier" [UML 2.5.1, 16.4.3.2], which is realized operationally in fUML. The fUML specification states, further, that "since such [destroyed] objects do not have any types, they will have neither attributes nor behaviors" [fUML 1.4, 8.10.1, Destroy Object Actions].

However, while the Object::destroy operation (called by DestroyObjectActionActivation::destroyObject) does remove all of an Object's types, it leaves any FeatureValues that have been set for the Object. This means that the Object still effectively has values for the attributes of types it no longer has. This does not seem to be what would be expected from the text in either the UML or fUML specifications. It would be better if the FeatureValues of an Object were also removed when it was destroyed.

Update Object::destroy

This is a simple change to the Object::destroy operation to clear the featureValues attribute as well as the types attribute.

Activity partitions are currently excluded from the fUML subset "because they are a very general modeling construct in UML activities and their precise execution semantics is unclear" (see subclause 7.10.1 of the fUML 1.4 specification). And, in fact, despite more careful wording in the UML 2.5 specification than in previous versions of UML (see subclause 15.6.3.1 in the UML 2.5.1 specification), activity partitions still have a very broad set of possible uses with semantics that are not very precisely defined.

Nevertheless, activity partitions are widely used by modelers to define "swim lanes" on activity diagrams. Further, they are used in SysML as one important way for allocating system functionality to subsystems. Therefore, it would be very helpful if fUML provided a precise semantics for at least the most common usage patterns for activity partitions in general, which could also provide a foundation for more specific usages in profiles such as SysML.

Out of scope

The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

Base Semantics should declare the PSL version used to define it.

Update footnote 2 in subclause 10.1

There has only been one internationally standardized version of PSL so far. However, just in case there may eventually be an update, the reference in footnote 2 in subclause 10.1 can be updated to specifically cite "ISO 18629-1:2004", which is the overview part of the standard as of 2004 (which is still the current version). In addition, the link http://www.nist.gov/psl now seems to redirect to a general NIST Engineering Laboratory page, not a page on PSL, so that should also be removed from the footnote.

There were found 42 issues, 5 of them were enhancements proposals, and 37 were defects.

The main issues concerning defects were:
1. The Base Semantics had a defect in the section 10.4.8.3 (pg. 383). There was missing a forall construction, which did not allow to parse entire definition.
2. After applied the necessary remedy actions to the definition, a model finder (EPROVER) was used to check if the fUML definition together with PSL definition - psl_outer_core - was satisfiable. The fUML Base Semantics together with PSL was unsatisfiable.
3. A model finder (EPROVER) also was used to check if the Base Semantics alone (without PSL) was satisfiable. The fUML Base Semantics was unsatisfiable.

I have been made available a file with all analyzed files at the following address:

http://es.cs.uni-kl.de/people/romero/fUMLOMGIssue20130630.zip

This file can help to recognize the defects.

Update subclause 10.4.8.3

Unfortunately, the file referenced in the issue is no longer available at the given link, and it was never physically attached to the issue (or, if it was at some point, it is now lost). Further, whether the base semantics are provably satisfiable has not seemed to be an issue in the successful use of fUML. Therefore, until someone takes the initiative to do further research and compile a new list of identified defects in the base semantics, it does not seem to be necessary to make any changes in this regard for now.

On the other hand, the defect specifically identified in subclause 10.4.8.3 is, indeed, an error that should be corrected.

Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.

Annex is no longer necessary

At the time this issue was submitted, the fUML abstract syntax metamodel was technically distinct from the UML abstract syntax. However, the intent was that fUML models would still be serialized using UML XMI. So some further explanation would have been useful.

However, as of fUML 1.4, the fUML abstract syntax is now formally a true subset of the UML 2.5.1 abstract syntax. So there is no question that a conforming fUML 1.4 model can be serialized using corresponding UML 2.5.1 XMI – since an fUML 1.4 model is a UML 2.5.1 model. So no further explanation is really necessary now.

Inference rules not used, and not needed for completeness, should be removed

Close, no change

This issue has been carried over for some time. If there was any analysis provided with the original issue indicating which inference rules in the base semantics are currently not needed, it has been lost. Such inference rules, if there are in fact any, may not strictly be needed, but having them is not harmful, especially since it is unlikely that there are many, and there have been no further issues filed relating to this.

Therefore, it seems safe to close this issue without changing the specification.

It should not define constraints for Actions outside the bUML: AcceptEventAction and ReadIsClassifiedObjectAction. In the other way around, it should be evaluated if these actions should be included in bUML. The java statement instanceof is used from page 98 to page 328, therefore the ReadIsClassifiedObjectAction should be added to bUML.

Close, no change

The specification already does provide base semantics for both AcceptEventAction (in 10.4.13) and ReadIsClassifiedObjectAction (in 10.4.12).

p94 8.6.2.2 Operations [2]

// To be equal, the otherValue must also be a compund value [...]

-> compound

p123 8.7.2.3 Operations [7]

// Create a new link with no type or properies.

-> properties

p146 8.8.2.7 2nd sentence

The parameteValues for any output [...]

-> parameterValues

p170 8.9.2.4 Attributes

• running : Boolean
  [...] enabled for execution once all its other prerequesites

-> prerequisites

p185 8.9.2.9 Operations [2]

// Return true if [...], because control tokens are interchangable.

-> interchangeable

p205 8.9.2.21 Operations [6]

// Otherwise, [...] and return a copy of it transfered to a new

-> transferred

p213 2nd para 2nd sentence

The operation StructuredActivity
Activcation::doAction checks the mustIsolate flag [...]

-> Activation::doAction

p230 Operations [16] run ()

{{// Run this action activation and any outoging fork node [...]}

-> outgoing

p239 Operations [1]

// [Note that this requires the behavior context to be compatible with [...]
current contect object.]

-> context

p245 8.10.2.12 Associations 2nd bullet

• selectedClause : clause
  The clause chosen from the set of selected Blauses [...]

-> Clauses

p285 8.10.2.37 Operations [1]

TokenList incomingTakens = new tokenList();

-> incomingTokens

p289 Operations [13]

// Terminate the execution of all contained node activations (whice

-> which

p291 8.10.2.42 Operations [1]

// Return the position (counting from 1) of the first occurance [...]

-> occurrence

p314 10.1 2nd para 2nd bullet

• Process Specification Language (PSL), a foundational axiomitization [...]

This clause uses an embedded approach to axiomitization, which [...]

-> axiomatization

Make editorial corrections

It is agreed that the typos identified in the issue should be corrected.

Consider the following activity:

Per the fUML execution model, when the ActivityFinalNodeActivation is fired, the ActivityExecution will terminate, and all nodes inside the activity group will be terminated (ActivityNodeActivationGroup::terminateAll()).

When ForkNodeActivation is terminated, it will clear all its tokens. And, when the token is cleared, it will be removed from its holder (Token::withdraw()). In the case the holder of the token is a DataStoreNodeActivation, it then will remove that token (DataStoreNodeActivation::removeToken(Token))

According to the specification of DataStoreNodeActivation:

[1] removeToken ( in token : Token ) : Integer
// Remove the given token from the data store, but then immediately
// add a copy back into the data store and offer it (unless the
// node activation has already been terminated).

int i = super.removeToken(token);
if (this.isRunning()) {
    super.addToken(token.copy());
    this.sendUnofferedTokens();
}

return i;

If this.isRunning() returns true, it will continue to send unoffered tokens, leading to the execution never ending.

Whether this.isRunning() returns true or false depends on the order of termination of DataStoreNodeActivation and ForkNodeActivation in the activity group. If DataStoreNodeActivation::terminate() is called before ForkNodeActivation::terminate(), it is fine (DataStoreNodeActivation::isRunning() will be false). If DataStoreNodeActivation::terminate() is called after ForkNodeActivation::terminate(), DataStoreNodeActivation::isRunning() is still true, and the execution does not end.

Fix ForkNodeActivation::terminate

The problem is that ForkNodeActivation::terminate clears its tokens before it terminates the activation. If it terminated first (i.e., called super.terminate() before calling self.clearTokens()), then, when it received another offer from the data store node, it would ignore it. ObjectNodeActivation::terminate used to have this same problem, but it was changed in fUML 1.3 as part of the update adding central buffer and data store nodes. Unfortunately, a similar change to ForkNodeActivation::terminate was not made at that time.