Issues for Mailing list of the Semantics of a Foundational Subset for Executable UML Models 1.1 (fUML) RTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 13872: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add
Issue 14526: Flow final nodes should be included
Issue 15130: An action may not stop firing again
Issue 15986: fUML 1.1 should be based on UML 2.4
Issue 15987: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type
Issue 16654: Error in ExpansionRegionActivation::takeOfferedTokens
Issue 16686: Error in CreateLinkAction semantics
Issue 16687: Duplicate code for ActionActivation::putToken
Issue 16948: Error in DecisionNodeActivation semantics
Issue 17168: Spurious comment on operation PinActivation::fire
Issue 17200: Error in RemoveStructuralFeatureVauleActionActivation::doAction
Issue 17201: Bug in DestroyObjectActivation::objectIsComposite
Issue 17203: Bug in ForkedToken::withdraw when the baseToken is a ForkedToken
Issue 17205: Error in ActivityNodeActivationGroup::getOutputParameterNodeActivations
Issue 17209: Error handling creation and destruction of links of associations with ordered ends
Issue 17211: ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor
Issue 17213: ActionActivation.sendOffers(): Missing sending of offers on outgoing control flows?
Issue 17270: Structural Feature Actions on Data Values Need to Create a new Result Value
Issue 17282: Error in check for enable nodes
Issue 17288: ExpansionRegionActivation does not reset its activationGroups
Issue 17291: ForkNodeActivation does not clear its tokens on termination
Issue 17298: ExpansionRegionActivation isReady condition is too strong
Issue 17299: LoopNodeActivation does not properly handle termination due to an activity final node
Issue 17300: An activity final node should not fire if it is not offered any tokens
Issue 17311: Having a fork node as initial enabled node does not work
Issue 17312: DecisionNodeActivation can send offers to multiple outgoing edges
Issue 17314: Structured activity node activations do not wait for contained accept event action activations
Issue 17345: Correction to the resolution of Issue 17209
Issue 17346: Read link actions and read structural feature actions do not handle ordered ends correctly
Issue 17391: Error in setting result pin values for CallActions
Issue 17392: Addition to resolution to Issue 17299
Issue 17396: Errors in ReduceActionActivation::doAction
Issue 17397: Null tokens are not sent on by control nodes
Issue 17499: Conditional node and loop node activations do not wait for contained accept event action activations
Issue 17502: Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A
Issue 17557: Addition to the resolution to fUML Issue 15987
Issue 17558: Addition to the resolution of fUML Issue 17203
Issue 17559: Correction to the resolution to fUML Issue 17209
Issue 17560: Addition to the resolution to fUML Issue 17499

Issue 13872: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add (fuml-rtf)

Specification: Semantics of a Foundation Subset for Executable UML Models, FTF – Beta 1 (ptc/08-11-03)



Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add 



Summary:



The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification.

 

Unfortunately, this  Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value {isReplaceAll=false}.

 

This creates a problem in several places where fUML class attributes are defined to be unique; in particular:

7.4.2.2.2 ActivityEdge::source {unique}

7.4.2.2.2 ActivityEdge::target {unique}

7.4.2.2.4 ActivityNode::incoming {unique}

7.4.2.2.4 ActivityNode::outgoing {unique}

 

The fUML reference implementation [1] loads an fUML model by CMOF reflection.

This means that it processes each activity edge in three parts:

1.       The activity node at the source of the edge

2.       The activity node at the target of the edge

3.       The edge itself

 

#1 and #3 lead to a duplication of the same edge on the outgoing list of the source node.

#2 and #3 lead to a duplication of the same edge on the incoming list of the target node.

 

[1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation 


Proposed resolution:

 

The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML.

 

The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections. 

 

A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows:

 

    public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) {

        this.target = target;

        /**

         * NFR 04/15/2009

         * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI,

         * it turns out that activity edges get a duplication of their source pins because:

         * - once by reflection when creating the ActivityNode whose .incoming edges includes this instance.

         * - a second time this ActivityEdge is constructed by reflection.

         */

        if (!target.incoming.contains(this)) {

            target.incoming.addValue(this);

        } else {

            Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]");

        }

 

    }

 

    public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) {

        this.source = source;

        

        /**

         * NFR 04/15/2009

         * Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI,

         * it turns out that activity edges get a duplication of their source pins because:

         * - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance.

         * - a second time this ActivityEdge is constructed by reflection.

         */

        if (! source.outgoing.contains(this)) {

            source.outgoing.addValue(this);

        } else {

            Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]");

        }

    }

 

The FTF agrees that this is a problem that needs fixing but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.
Revised Text:
None.
Disposition:	Deferred

Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)
Subclause:  7.4.2 IntermediateActivities

 

Flow final nodes are currently excluded from the fUML subset. However, such nodes can be useful to explicitly consume tokens without terminating an activity. Since their semantics would be very easy to add to the execution model, it should be considered to add them to the fUML subset

The FTF agrees that this is a problem that needs fixing but, due to lack of time, decided to defer its resolution to a future RTF working on this specification.
Revised Text:
None.
Disposition:	Deferred

The code for ActionActivation::fire, as updated for the resolution of Issue 15094, is missing the statement “fireAgain := false;” that should appear after “_beginIsolation();” and before “_endIsolation();”. As a result, if an action fires again at least once, but eventually is not ready to fire any longer, fireAgain will still stay true, causing it to erroneously continue to fire anyway.

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

 

Foundational UML (fUML) 1.0 as finalized is based on UML 2.3. With the completion of the UML 2.4 RTF, fUML should be moved to UML 2.4. This would be consistent with the recently adopted Alf action language specification, which will be finalized based on UML 2.4.

 

Fortunately, nothing seems to have changed in UML 2.4 that would substantively effect the specification of the fUML abstract syntax subset. However, the fUML normative XMI should be regenerated consistent with UML 2.4/XMI 2.4. Further, UML 2.4 has separated the primitive type model into a separate XMI file with normative XMI IDs, and these should be used for referencing those types in the normative XMI for the fUML Foundational Model Library.

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

 

UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library.

 

Specification: Semantics of a Foundation Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

Subclause: 8.5.4.2.3 ExpansionRegionActivation

 

In the ExpansionRegionActivation class, operation [8] takeOfferedTokens is missing an initial call to super.takeOfferedTokens(). This means that, when an expansion region activation fires, it does not properly handle tokens on control flows incoming to the expansion region, nor does it fire any input pin activations for the region, both of which should be handled as usual for an action. Because of this, the subsequent copying of input tokens from input pin activations in ExpansionRegionActivation never actually produces any tokens, even though some may have been offered to the input pins.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

Subclause: 8.6.3.x CreateLinkActionActivation

 

In Subclause 8.6.3.1 (Overview), under “Link Actions”, it says for a Create Link Action that “if a link already exists in the association extent with the same tuple of values, and all the ends of the association are specified as unique, then no new link is actually created (though this is not an error).” However, the specification for CreateLinkActionActivation::doAction in Subclause 8.6.3.2.4 always creates a new link even if an identical link already exists (unless isReplaceAll=true for one of the ends), regardless of whether the ends of the association are all unique.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

Subclause: 8.6.2.2.1 ActionActivation

 

The code listed under operation [12] PutToken for class ActionActivation is accidentally duplicated. The lines starting with the second set of comments to the end should be deleted.

: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

Subclause: 8.5.2.2.9 DecisionNodeActivation

 

In the method for the DecisionNodeActivation::getDecisionInputFlowValue operation contains the statement:

 

value = ((ObjectToken)(tokens.getValue(0))).value;

 

Since a decision input flow must be an object flow, it would seem reasonable to be able to assume that this flow would only contain ObjectTokens. However, all tokens offered by ForkNodeActivations are wrapped in ForkTokens, which is directly a subclass of Token. If such a token is offered on a decision input flow, then the above cast will fail.

 

To fix this, the above statement should be replaced with:

 

value = tokens.getValue(0).getValue();

 

The getValue operation is defined for all types of tokens (it returns null for control tokens, but that would not be an issue here).

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/11-02-01)

Subclause: 8.6.2.2.8 PinActivation

 

The operation PinActivation::fire includes the comment “[Note that a pin will consume all tokens offered to it, even if this is more than the multiplicity upper bound, but will only offer tokens up to that upper bound.]” However, this is not true in fUML as finalized. The incoming tokens passed to the fire operation are determined using the takeOfferedTokens operation, which is defined to “Take only a number of tokens only up to the limit allowed by the multiplicity upper bound of the pin for this activation.”

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0

Subclause: 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation

 

The following conditional appears toward the end of the specification of the RemoveStructuralFeatureValueActionActivation::doAction() operation:

 

if (featureValue.values.size() <= removeAt) {

    featureValue.values.remove(removeAt - 1);

}

 

The “<=” operator in the condition should instead be “>=”.

 

Destroying an object (with "isDestroyLinks" = true) can potentially result in an infinite loop, since the loop variable "i" is never incremented.


Solution: 
while (!isComposite & i <= linkFeatureValues.size()) {
      FeatureValue featureValue = linkFeatureValues.getValue(i-1);
      if (!featureValue.values.getValue(0).equals(reference) &
         ((Property)featureValue.feature).aggregation == AggregationKind.composite) {
            isComposite = true;
      }
      i = i + 1;
}

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclause: 8.5.2.2.10 ForkedToken

 

ForkedToken::withdraw calls isWithdrawn() to check if its baseToken is withdrawn, and then withdraws it if that is false. The intent is that baseToken.withdraw() only be called once. However, if the baseToken is itself a ForkedToken, then calling withdraw() may only decrement the remainingOffersCount of that token, with isWithdrawn() only becoming true if this count goes to zero. This means that additional calls to withdraw() on the first ForkedToken may result in additional calls to withdraw() on its baseToken, prematurely reducing the remainingOffersCount for the baseToken.

 

This can be avoided by adding an explicit baseTokenIsWithdrawn flag to ForkedToken that is set when the baseToken is withdrawn and then checked to avoid further withdraws.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01) 

Subclause: 8.5.2.2.5 ActivityNodeActivationGroup

 

The ActivityNodeActivationGroup::getOutputParameterNodeActivations operation is supposed to return the output ActivityParameterNodeActivations for an Activity. As currently specified, it finds all the ActivityParameterNodes for parameters with direction inout, out and return. However, inout parameters actually have two ActivityParameterNodes: one for input and one for output. The current specification results in the operation incorrectly returning both the input and output nodes for an inout parameter.

 

The UML well-formedness constraints require that an input ActivityParameterNode only have outgoing edges and that and output ActivityParameterNode only have incoming edges. Therefore, instead of checking the parameter to determine output nodes, getOutputParameterNodeActivations should instead check whether the node activation has incoming edges.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

Subclause: 8.3.2.2.11 Link

 

The behavior of the Link::setFeatureValue operation results in the FeatureValues for an ordered end to be totally ordered by “position” across all links of an association. However, when a new link is created, the insertAt position for an ordered end isn’t relative to all links but only relative to links for which the other ends have the same values as the link being created. This means that the FeatureValues of the ordered ends of the new link may not be inserted at the correct position.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

 

Subclause: 8.2.3.2.1 ExecutionFactoryL2

The code listed under operation [1] instantiateVisitor for class ExecutionFactoryL2 accidentally duplicates code from ExecutionFactoryL3.instantiateVisitor. The code of ExecutionFactoryL2.instantiateVisitor should be modified to properly cover L2 elements.

It seems that in ActionActivation.sendOffers(), a loop for sending a control token on outgoing edges is missing. The code should probably be completed with something like:

 

// *** Send offers on all outgoing edges concurrently. ***

ActivityEdgeInstanceList outgoingEdges = this.outgoingEdges;

for (Iterator i = outgoingEdges.iterator(); i.hasNext();) {

ActivityEdgeInstance outgoingEdge = (ActivityEdgeInstance)i.next();

TokenList tokens = new TokenList();

tokens.addValue(new ControlToken());

outgoingEdge.sendOffer(tokens);

}

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclauses: 8.6.3.2.1 AddStructuralFeatureValueActionActivation, 8.6.3.2.3 ClearStructuralFeatureActionActivation, 8.6.3.2.12 RemoveStructuralFeatureValueAction

 

Data values are not mutable, so, when given a data value, the structural feature actions are supposed to produce a new data value on the result pin, with the same feature values as for the input data value except for the structural feature on which the action acts. However, the current specifications for the activations of these actions do not copy the value before modifying it, resulting in an incorrect “in place” modification of the feature value of the original data value.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation

 

The ActivityNodeActivationGroup::run operation checks which of the node activations in a given set are initially enabled. It does this using the checkIncomingEdges operation to check whether a node has incoming edges with a source within the given set of node activations. The checkIncomingEdges operation in turn uses the ActivityNodeActivation::sourceFor operation to check if an activity node activation is the source for a given activity edge instance. By default, this is true if the activity node activation is the source of the activity edge instance. The sourceFor operation is overridden in ActionActivation to account for the fact that outgoing control flows are attached to an ActionActivation via an anonymous fork node but, otherwise, the default behavior is used.

 

With the current specification for sourceFor, if a node activation has an incoming edge instance from within a structured activity node activation, rather than from the structured activity node itself, the structured activity node activation will not be considered the source for the edge instance, and the current specification for checkIncomingEdges does not look for sources inside structured activity nodes. This means that, if an activity node only has incoming edges with sources nested within a structured activity node, it may be spuriously considered to be enabled when it really has predecessor dependencies.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)
Subclause: 8.5.4.2.3 ExpansionRegionActivation

 

ExpansionRegionActivation creates a set of activation groups that it uses to run the contents of the expansion region for each input value. However, after an ExpansionRegionActivation fires, it does not clear its activationGroups attribute. This means that, if the same activation fires again (as might happen if it is within a loop), subsequent firings add additional activation groups to the set already created in previous firings. This results in spurious extra executions of the contents of the expansion region.

 

To avoid this, the statement “this.activationGroups.clear();” should be added before the loop in ExpansionRegionActivation::doStructuredActivity.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclause: 8.5.2.2.11 ForkNodeActivation

 

Unlike other control nodes, a fork node actually holds forked tokens pending their acceptance by downstream nodes. Therefore, when a ForkNodeActivation terminates, it needs to clear its held tokens, similarly to an ObjectNodeActivation. It currently does not do this, which means, if it is fired repeatedly in a loop node, and not all of its held tokens are accepted on previous iterations, it will be spuriously holding extra tokens on subsequent iterations.

 

Adding the following overriding method to ForkNodeActivation is sufficient, because ActivityNodeActivation::clearTokens() repeatedly withdraws held tokens until none are left, which will work even for multiply forked tokens.

 

                public void terminate() {

                                // Remove any offered tokens and terminate.

 

                                this.clearTokens();

                                super.terminate();

                } // terminate

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclause: 8.5.4.2.3 ExpansionRegionActivation

 

The specification for ExpansionRegionActivation::isReady() requires that each of the input expansion nodes for an expansion region have the same (non-zero) number of values offered to it before the expansion region can fire. In particular, this means that if an expansion region receives null tokens representing “empty collections”, then the expansion region will not fire. This may seem to be the same as having the expansion region fire and do nothing, except that, if the region does not actually fire, then it does not offer control tokens on any outgoing control flows and any node downstream of those flows will be inhibited from firing. This does not like a reasonable limiting case of expansion region semantics on “empty” collections, and, in fact, it seems to violate what would be expected from the semantics of expansion regions as described in the full UML spec.

 

The requirement for all input expansion nodes to have the same number of values also seems to strong, requiring careful sizing of all expansion inputs lest the region not be able to fire. Instead, the size of the smallest input collection could be used to govern the number of executions of the body of the expansion region, to insure there are parallel inputs available from each input expansion node for each body execution. 

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclause: 8.5.3.2.3 LoopNodeActivation

 

If an activity final node directly owned by a loop node fires, then the loop node should terminate. However, the loop node should still produce values on its output pins based on any computations that have happened so far. Currently, when such an activity final node fires, the enclosing loop node is indeed immediately terminated via a call to its terminate(), but this does not actually terminate the loop in LoopNodeActivation::doStructuredActivity(). That loop only terminates once the test part of the loop executes, producing a null value (since all its nodes will no longer be running), which is interpreted as false. Further, the prior call to terminate() removes all tokens from the output pins in the body part of the loop, meaning that they are no longer available to be moved to the output pins of the loop node. As a result, the loop node produces no output, even if outputs have been computed prior to the firing of the final node.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclause: 8.5.2.2.3 ActivityFinalNodeActivation

 

ActivityFinalNodeActivation::fire(incomingTokens) currently terminates the activity node activation group containing the activity final node, even if incomingTokens is empty. This is normally not a problem, since fire is usually only called if at least one token has been offered. However, if the activity final node is in a loop node or a conditional clause with an incoming edge from the body of the loop node or clause, then, when the test for the loop node or clause is being executed, the body part is not yet activated. If the source of the incoming edge to the activity final node is a body part node that is not activated, then the edge will be ignored in determining whether the final node is enabled, resulting in the final node being considered enabled and, unless otherwise prevented, firing  prematurely, terminating the enclosing loop node or conditional node.

If a fork node is identified as initial enabled node in the method ActivityNodeActivationGroup.run(ActivityNodeActivationList), and the method ActivityNodeActivation.receiveOffer() is called for the ForkNodeActivation, the method ForkNodeActivation.fire(TokenList) does not produce any forked tokens (because there is no real incoming token for the fork node) and because of this, the method call this.sendOffers(forkedTokens) (last statement of the method ForkNodeActivationActivation.fire(TokenList)) does not result in offers sent to successor nodes but this should be possible.

In the method DecisionNodeActivation.fire(TokenList), a token offer is sent to each outgoing edge for which the guard evaluates to true resulting in the execution of multiple successor nodes. 
Only one successor node should receive an offer also if the guards of several outgoing edges evaluate to true.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)
Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation, 8.6.4.2.1 AcceptEvent ActionActivation

 

When a structured activity node contains one or more accept even actions, then, when those actions are waiting for the reception of event occurrences, one would expect that the structured activity node as a whole would also be waiting, pending the triggering of the actions. As currently specified, when  accept event action activation registers to wait for event dispatching, it is not considered to be complete. Nevertheless, once all such actions have registered, and all other contained in a structured activity node have completed, the running of the node activations in the activation group for the structured node finishes, and the structured activity node activation completes, allowing execution to continue to subsequent nodes. This is not correct; the structured activity node activation should essentially be suspended until all the accept event actions activations have actually completed.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.3.2.2.11 Link

 

The resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) included the addition of an addTo operation to the Link class. The specification of this new operation contains the statement:

 

FeatureValue otherFeatureValue = featureValues.getValue(j);

 

This should, instead, have been:

 

FeatureValue otherFeatureValue = otherFeatureValues.getValue(j);

 

Also, the resolution didn’t not the need to update Figure 8.12 to reflect the addition to Link of the operations isMatchingLink, getOtherFeatureValues and addTo, and the removal of the operation getFeatureValue.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.6.3.2.9 ReadLinkActionActivation, 8.6.3.2.13 StructuralFeatureActionActivation

 

Read link actions and read structural feature actions do not always return the values for an ordered association end in the correct order. In ReadLinkActionActivation::doAction, after the loop searching for the position at which to insert a featureValue, the statement

 

featureValues.addValue(k-1, featureValue);

 

should be replaced with

 

if (continueSearching) {

    featureValue.addValue(featureValue);

} else {

    featureValue.addValue(k-1, featureValue);

}

 

in order to correctly handle the case in which the featureValue should be added at the end of the list.

 

There is a similar statement in StructuralFeatureActionActivation::getMatchingLinks to insert a link at the correct position in the list of matching links, and it should be replaced in a similar manner to the above.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.6.2.2.2 CallActionActivation

 

At the end of CallActionActivation::doAction, the output parameter values from the call execution are placed on the result output pins of the call action. However, the current specification presumes that the parameter values from the execution will be in the same order as the output parameters (and output pins). But this will not always be the case. 

 

For example, if a parameter is an inout parameter, then it will have a parameter value added to the execution with its input before the execution is executed. It’s output will then be written to this existing output parameter value, while parameter values for out parameters will be created ordered after the one for the inout parameter, even if the out parameters are ordered before the inout parameter. Thus, the wrong values will be copied to the output pins.

 

Instead of relying on ordering, the specification for doAction should us the parameter reference for each output parameter value to identify the correct result output pin to which the parameter value should be written.

 

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.5.2.2.3 ActivityFinalNodeActivation

 

The resolution to Issue 17299 did not take into account, in the revision to ActivityFinalNodeActivation::fire, that the group for the ActivityFinalNodeActivation may be an ExpansionActivationGroup, which has a regionActivation property set instead of containingNodeActivation.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.6.4.2.6 ReduceActionActivation

 

The specification for ReduceActionActivation::doAction has a number of errors.

 

1. The test “input1 != null” should be “input1 == null”.

 

2. The test for “parameter.direction == ParameterDirectionKind.out” should also test for a parameter direction of return.

 

3. After the execution of the reducer behavior, parameterValue1 should not be set to the resulting ParameterValue. Instead, only parameterValue1.values should be set to the resulting values (parameterValue1.parameter should remain unchanged as being equal to input1).

 

4. There is no abstract syntax constraint that the output of the reducer cannot be empty. The semantics for a reduce action should take into account the possibility of the reducer returning no value and not try to feed an empty input into the next reducer call.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
Subclause: 8.5.2.2.15 ObjectNodeActivation

 

When an object node has no tokens, ObjectNodeActivation::sendOffers creates a null token to send. However, the holder attribute of this token is not set. This means that, even though the token gets offered, when a node tries to take it from the offering edge instance, the token is considered to have been withdrawn and is not passed on to the token. The effect of this is, in particular, that control node activations will never pass on null tokens, which is incorrect.

 

To avoid this, sendOffers should set the holder of the null token to be the object node sending it.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

Subclauses: 8.5.3.2.2 ConditionalNodeActivation, 8.5.3.2.3 LoopNodeActivation, 8.5.4.2.3 ExpansionRegionActivation

 

The resolution to Issue 17314 (Structured activity node activations do not wait for contained accept event action activations), on adopted on Ballot 2 of the fUML 1.1 RTF, works for plain structured activity nodes, but it does not work for structured activity nodes that are conditional nodes, loop nodes or expansion regions. For conditional nodes, the resumption of suspension of the node must take place in the context of a specific conditional clause. For loop nodes, resumption must allow continued iteration of the loop, rather than just completion of the node activation. For expansion regions, resumption must take place in the context of a specific expansion activation group.

Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

Subclause: 8.4.3.2.1 ClassifierBehaviorExecution, 8.4.3.2.5 ObjectActivation

 

Subclause A.3.7 establishes the Java notation “_startObjectBehavior();” as mapping to a start object behavior action, not an operation call, and it also states that “A class may not define a user operation called ‘_startObjectBehavior.’” However, in Subclause 8.4.3.1, Figure 8.17, _startObjectBehavior is shown as an operation on both ClassifierBehaviorExecution and ObjectActivation, and it is specified in as an operation for these classes in Subclauses 8.4.3.2.1 and 8.4.3.2.5. 

 

Subclause A.3.8 establishes the Java notation “_send(new <signal>());” as mapping to a send signal action, not an operation call. However, in Figure 8.17, _send is shown as an operation of ObjectActivation, and it is specified as an operation in Subclause 8.4.3.2.5.

 

The resolution to Issue 15987 (The fUML Foundational Model Library should support the new UML 2.4 Real primitive type) adds LiteralReal and LiteralRealEvaluations class, but neglects to update the ExecutionFactoryL1::instantiateVisitor operation to instatiate an instance of the latter class when given an instance of the former.

 

The resolution to Issue 17203 (Bug in ForkedToken::withdraw when the baseToken is a ForkedToken) adds a Boolean baseTokenIsWithdrawn attribute to the ForkedToken class. However, since bUML (like fUML) does not support default values on attributes, this attribute needs to be explicitly set to false when a ForkedToken is created in ForkedNodeActivation::fire(). The resolution neglects to include this revision.

 

The Revised Text instructions in the resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) includes the statement “Remove the (overriding) operation getFeatureValue.” However, Link does not have an overriding getFeatureValue operation. The correct instruction is to remove the setFeatureValue operation.

 

The resolution to Issue 17499 (Conditional node and loop node activations do not wait for contained accept event action activations) removes some lines from the specification for the operation ConditionalNodeActivation::doStructuredActivity. However, it neglects to state to remove the final line “this.activationGroup.terminateAll();”, which also needs to be removed.