FUML12 — Certain Boolean flags are not properly initialized in some cases

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)

Subclauses: 8.5.2.2.4 ActivityNodeActivation, 8.6.2.2.1 ActionActivation and 8.6.4.2.1 AcceptEventActionActivation

The Boolean attributes ActivityNodeActivation::running, ActionActivation::firing and AcceptEventActionActivation::waiting are presumed to be initialized when instances of the respective classes are created. However, since fUML (and hence bUML) does not support default values, such initialization needs to be done explicitly. Unfortunately, there are times when this is not happening properly.

ActivityNodeActivation::running is set to false when an activity node activation is created by ActivityNodeActivationGroup::createNodeActivation. However, there are a couple of cases when activity node activations are created other than by using this operation:

1. When an action has outgoing edges, an anonymous fork node activation is created for the corresponding action activation, to handle the implicit fork semantics for tokens offered on the outgoing edges. The running attribute of this fork node activation is not initialized when it is created. (The run operation is called on the fork node activation when it's corresponding action activation is run, but until then the running attribute of the fork node action is unitialized.)

2. Output pin activations are created in ExpansionRegionActivation::doStructuredActivity for the expansion activation groups of an expansion region activation. The ActivityNodeActivation::run operation is immediately called on each of these output pin activations, so that running is initialized to true in this case. Unfortunately, the call to add an output pin activation to the groupOutputs of an expansion activation group (the third set of such pin activations in an expansion activation group) erroneously constructs a new output pin activation, rather than adding the one that has been properly initialized.

The attributes ActionActivation::firing and AcceptEventActionActivation::waiting are both set to false in the run operation of their respective classes. However, when an action is in the body of a loop node or conditional node clause, it is possible for isReady operation on the action activation to be called before the action activation is actually run. Since the isReady check for an action, in general, checks the firing attribute, and the isReady check for an accept event action checks the waiting attribute, if isReady is called before run, these attributes will not have been properly initialized. In addition, AcceptEventActionActivation::waiting is checked in AcceptEventActionActivation::terminate, and it will not have been initialized if an accept event action activation is terminated without ever having been run.

Add attribute initializations

Agreed.

The first two points in the issue can be handled by small updates to ActionActivation and ExpansionRegionActivation. The remaining points, however, require more extensive updates, to ensure that all activations are properly initialized when they are added to an activity node activation group, even before they are run.