Issue 18321: Certain Boolean flags are not properly initialized in some cases (fuml-rtf) Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com) Nature: Uncategorized Issue Severity: Summary: 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 usine 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. (It 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 activations 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. Resolution: 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. Revised Text: In 8.5.2.1, Figure 8.25, and in the normative XMI, remove the operations addNodeActivation and addEdgeInstance from class ActivityNodeActivationGroup. In Figure 8.26, add the following operation to class ActivityNodeActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.5.2.2.4 ActivityNodeActivation, add the following operation after operation getTokens and renumber subsequent operations appropriately: [14] initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) // Initialize this action activation to be not firing. super.initialize(node, group); this.firing = false; [Editor's Note: The code listed above for the ActivityNodeActivation::initialize operation (added to 8.5.2.2.4) is an accidental duplicate of the code listed for ActionActivation::initialize (added to 8.6.2.2.1 below). The correct code (as tested in the prototype implementation) is: // Initialize this node activation. this.node = node; this.group = group; this.running = false; ] In 8.5.2.2.5 ActivityNodeActivationGroup, remove operations [2] addEdgeInstance and [3] addNodeActivation and renumber subsequent operations as appropriate. In the createNodeActivation operation, replace the statements activation.node = node; activation.running = false; this.addNodeActivation(activation); with activation.initialize(node, this); this.nodeActivations.addValue(activation); In the createEdgeInstances operation, in the first for statement, replace the statement this.addEdgeInstance(edgeInstance); with edgeInstance.group = this; this.edgeInstances.addValue(edgeInstance); In 8.5.4.2.3 ExpansionRegionActivation, in operation doStructuredActivity, in the third nested while loop, change the statement activationGroup.groupOutputs.addValue(new OutputPinActivation()); to activationGroup.groupOutputs.addValue(groupOutput); In 8.6.2.1, Figure 8.31, and in the normative XMI, add the following operation to class ActionActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.6.2.2.1 ActionActivation, add the following operation after the operation getTokens and renumber subsequent operations appropriately: [9] initialize ( in node : ActivityNode, in group : ActivityNodeActivationGroup ) // Initialize this action activation to be not firing. super.initialize(node, group); this.firing = false; In the addOutgoingEdge operation, after the statement forkNodeActivation = new ForkNodeActivation(); add the statement forkNodeActivation.running = false; In 8.6.4.1, Figure 8.36, and in the normative XMI, add the following operation to class AcceptEventActionActivation: initialize ( node : ActivityNode, group : ActivityNodeActivationGroup ) In 8.6.4.2.1 AcceptEventActionActivation, after the operation fire, add the following operation and renumber subsequent operations appropriately: [4] initialize ( in node : ActivityNode, in group : ActivityNodeActivationGroup ) // Initialize this accept event action activation to be not waiting for an event. super.initialize(node, group); this.waiting = false; Actions taken: December 17, 2012: received issue October 8, 2015: Resolved December 22, 2015: closed issue Discussion: End of Annotations:===== m: Ed Seidewitz To: "issues@omg.org" Date: Mon, 17 Dec 2012 18:41:59 -0500 Subject: Certain Boolean flags are not properly initialized in some cases Thread-Topic: Certain Boolean flags are not properly initialized in some cases Thread-Index: Ac3csBrRT/zKlIIDReG813Oe5rOxuQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars clean X-Mailprotector-Score: 60 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.728728 p=-0.986418 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-17104-c X-Mailprotector-ID: 10f2430d-bdca-400c-8565-2f8d039d4bf8 X-Brightmail-Tracker: AAAAAgr+n5EctjSA X-Brightmail-Tracker: AAAAAA== 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 usine 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. (It 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 activations 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.