LoopNodeActivation does not correctly handle the firing of a contained activity final node
Legacy Issue Number: 18280
Source: Model Driven Solutions ( Ed Seidewitz)
Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 RTF Beta (ptc/2012-10-18)
Subclause: 18.104.22.168.3 LoopNodeActivation
When an ActivityFinalNode fires within a StructuredActivityNode (other than an ExpansionRegion), the ActivityFinalNodeActivation terminates the containing node activation by calling the terminateAll operation. This operation is specified in StructuredActivityNodeActivation to terminate all activations in the activation group for the structured node activation. As a result, none of these activations can fire any more, and the structured node activation as a whole eventually completes its firing. Note that the structured node itself does not terminate, since it can still fire again.
For a LoopNodeActivation, the call to TerminateAll will happen within a loop iteration. Terminating all activations in the loop node activation group will result in the body of the loop completing, resulting in the runBody operation to return from its call within the LoopNodeActivation::fire operation. The fire operation then checks whether the loop should continue. However, this only includes checking whether the loop node as a whole has terminated or been suspended. Neither of these will be the case if the firing of the loop was terminated due to an activity final node. As a result, the loop may be determined to continue, even though it should not.
What is necessary is to set a flag when LoopNodeActivation::terminateAll is called and to check this flag in the same conditionals in the fire that check isRunning and isSuspended. This flag also needs to be checked in the LoopNodeActivation::resume operation to prevent the loop from continuing on resumption if the firing has been terminated by an activity final node.
(Note also that there are two conditionals at the end of the fire operation as currently specified that use the “&&” operator, which is not allowed by the bUML subset as specified in Annex A.)
Reported: FUML 1.0 — Fri, 23 Nov 2012 05:00 GMT
Disposition: Resolved — FUML 1.2
Updated: Tue, 22 Dec 2015 15:09 GMT