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.

Agreed.

In order to simplify the resolution, it seems unnecessary to allow accept event actions within the test parts of conditional node clauses or loop nodes. Such tests are supposed to be “side effect free” and waiting for an external event to happen is essentially a non-functional side effect. If accept event actions are not allowed in tests, then, for a conditional node, suspension and resumptiuon can only happen in the body of a selected clause with a true test and, for a loop node, it can only happen in the body of the loop.

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.

agreed

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)

else

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.

agreed

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.

agreed

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.

agreed

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.

Agreed. A reasonable approach for dealing with the reducer returning an empty value is to simply start the reduction computation over with the remaining values in the list.

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.

Agreed. In addition to modifying ActivityFinalNodeActivation, to call the terminate operation on an enclosing expansion region, it is necessary to modify the ExpansionRegionActivation to fire the outputs of the expansion region before it terminates (which is the problem identified in Issue 17299).

(Note that the resolution to Issue 17300 also modified the ActivityFinalNodeActivation::fire operation.)

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.

agreed

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.

In Subclause 12.3.22 DecisionNode of the UML Superstructure specification, it says:
“Notice that the semantics only requires that the token [offered to a decision node] traverse one edge, rather than be offered to only one edge. Multiple edges may be offered the token, but if only one of them has a target that accepts the token, then that edge is traversed. If multiple edges accept the token and have approval from their targets for traversal at the same time, then the semantics is not defined.”
Thus, it is correct that an incoming token to a decision node is offered on all outgoing edges for which the guard is satisfied. In fUML, if multiple downstream targets then try to accept the offered token at the same time, the semantics is the same as in any case of contention for a token. Only one of the targets can actually accept the token – since a decision node does not duplicate tokens, there is only one token to be accepted. Which of the targets actually gets the token is indeterminate, however.
Revised Text:
None.
Disposition: Closed, No Change

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.

A fork node is required to have a single incoming edge (this is Constraint [1] under Subclause 12.3.30 ForkNode in the UML Superstructure spec, constraints from which also apply to fUML). The intent is that a fork node only generates forked tokens based on tokens offered to it on that one incoming edge.

More specifically, consider that the only way a fork node can be initially enabled (in fUML) is if the source for its one incoming edge is either outside the activity node activation group containing the fork node activation or it is in the same activation group but not yet activated.

The first case occurs when the fork node is contained a structured node but is the target of an edge crossing into the structured node from a source outside it. In this case, receiveOffer is called on the (enabled) fork node activation when the structured node fires, and this operation in turn calls takeOfferedTokens, which accepts any tokens offered on the incoming edge into the fork node. If tokens have been offered on that edge previously to the structured node firing, then the fork node activation will create forked tokens for them and offer them on the outgoing edges from the fork node. On the other hand, if no tokens have been offered, then the fork node activation does nothing further, which is correct.

The second case occurs when the fork node is part of a conditional node or a loop node and the source of the incoming edge is an action or pin within the same node. The executable nodes for a conditional or loop node are divided up into test and body parts, which are activated incrementally per the semantics of the containing nodes. Contained control nodes, however, are always activated unconditionally (or, in the case of a loop, on each iteration). If a fork node is thus activated before the source of its incoming edge is, then it is not possible for anything to have been offered on that edge yet and, therefore, it is correct that the fork node should not offer anything on its outgoing edges. If that source node is later activated and does eventually offer something on the edge to the fork node, then that will trigger another call to receiveOffer on the fork node activation, which will result in forked nodes being offered on outgoing edges as appropriate.

So, the current semantics for fork nodes are actually correct.

Revised Text:
None.
Disposition: Closed, No Change

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.

Agreed. Note that the revised text below also includes a check for the final node having no incoming edges at all (which is valid), so that, in this case, it will fire when enabled, even though it will have no incoming tokens.

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.

agreed

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.

Agreed. Note also that the activity shown in Figure 8.18 has a call to _startObjectBehaviorAction and the activity shown in Figure 8.19 has a call to _send.

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.

agreed

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.

agreed

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.

Agreed. In addition, the selectedClause attribute needs to be set to null before the if statement that tests if there are any clauses to select, since this is tested in the new completeBody operation. Otherwise, selectedClause could contain a spurious value from a previous activation of the conditional node, causing completeBody to try to copy outputs from that clause, rather than just doing the terminateAll call.

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.

agreed

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

Agreed.

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

.

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

7.4.2.2.4 ActivityNode::incoming

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))

else

}

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))

else

}

This issue seems to be a problem with a specific implementation of fUML, not with the fUML specification itself. The uniqueness of association ends is essentially a constraint that there are no duplicate values on that end. fUML only gives semantics to syntactically valide models for which all well-formedness constraints are satisfied, including implicit constraints like multiplicity and uniqueness, as well as constraints given explicitly in OCL. Any implementation that violates syntactic constraints when loading a model is simply an incorrect implementation. It is not necessary to further complicate the fUML semantic specification or the Java=>bUML mapping to account for this.
Revised Text: None
Disposition: Closed, No Change

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.

The UML 2.4.1 Infrastructure specification states that “A real is a primitive type representing the mathematical concept of real” and that “An instance of Real is an element in the infinite set of real numbers.” However, some care needs to be taken in defining the fUML execution semantics of the Real type and supporting primitive functions, so that it is possible for a real implementation to conform to those semantics.
The UML specification also says that “An instance of Integer is an element in the (infinite) set of integers…”. And the base semantics for buml:Integer in Subclause 10.3.1.2 of the fUML 1.0 specification does, indeed, include the mathematical axioms necessary to define this infinite set. However, Subclause 9.1 includes the permission that “…a conforming implementation may limit the supported values [of Integer] to a finite set.”
Similarly, fUML should allow conforming implementations to limit the supported values of Real to a finite set. However, for Real numbers, this means more than just limiting the upper and lower bounds of the supported range of Real numbers. It also means dealing with the fact that Real numbers can only be represented to finite precision in an actual implementation.
Generally, programming languages provide floating-point representations that approximate Real numbers. However, this is an implementation representation, and the most commonly used standard reference on floating-point numbers, IEEE 754, is a standard for the implementation of floating-point computation.
For fUML, it is necessary to provide a precise semantic specification for Real numbers that is implementation independent but that provides clear criteria for the conformance of actual implementations. This should allow implementations based on a floating-point standard such as IEEE 754 but also allow implementations using, e.g., fixed-point computation or exact rational number computation.
This can be achieved in three steps.
1. Axioms for the Real type need to be added to the fUML base semantics in Clause 10.
2. Criteria are needed in Clause 9 for conformance to the Real type as it is to be provided in the fUML Foundational Model Library. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). So, some permission is needed to allow for the conformance of implementations using, e.g., finite-precision floating-point representations. In addition, IEEE 754 requires some additional special values be represented in the floating-point formats it defines. Since it is expected that it will be common that the fUML Real type will be implemented using a floating-point representation based on IEEE 754, it is necessary to allow for the inclusion of such values in an implementation of Real.
3. Criteria are needed in Clause 9 for conformance to the semantics of the primitive functions for Real to be provided in the Foundational Model Library. The specification of the primitive functions for Real in the Foundational Model Library will define the exact real number result of applying those functions. It is then necessary to define how these exact results may be represented in a conforming implementation that takes advantage of some or all of the permissions allowed relative to the representation of Real numbers.
This resolution also presumes the resolution of Issue 15986, “fUML 1.1 should be based on UML 2.4”. For simplicity, all revisions related to the new Real type have been included here. This includes changes to Clause 7 Abstract Syntax, Clause 8 Execution Model and Annex A Java to UML Activity Mapping, as well as the changes to Clauses 9 and 10 discussed above.

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.

The following issues resolved in UML 2.4 and UML 2.4.1 have an impact on the fUML subset.
• Issue 10831: “PackageableElement::visibility” uses “false” as default value
• Issue 12583: OCL 2.0 8.2 Real
• Issue 13718: Section 12.3.48 on page 412
• Issue 13993: UML 2.2 Issue - availability of PrimitiveTypes for UML models
• Issue 14631: All enumeration literals in the model have their "classifier" collections empty
• Issue 14632: Associations with same name that live in different packages violate unique name constraint
• Issue 14926: is composite, but does not subset ownedElement
• Issue 14931: remove BehavioredClassifier::ownedTrigger
• Issue 14977: Matching subsettting across association ends
• Issue 15369: UML 2.4: Add Property::isId
• Issue 15370: UML 2.4: Add Package::URI
• Issue 15526: Missing subsetting of redefinitionContext by Property::owningAssociation
• Issue 15664: Property::isID should not be optional
• Issue 16232: No unambiguous way in UML 2.4 to serialize StructuredActivityNode
Further, comparison if the fUML 1.0 abstract syntax model with that of UML 2.4.1 identifies the following additional corrections need to fUML.
• Remove Class::isAbstract attribute (this is already inherited from Classifier).
• Add default of true for Generalization::isSubstitutable.
• Note exclusion of Parameter::defaultValue, Parameter::default and Property::default.
• Add default of “in” for Parameter::direction.
See also the resolution to Issue 15987 “The fUML Foundational Model Library should support the new UML 2.4 Real primitive type”. For simplicity, all revisions related to the new Real type are handled in that resolution.

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.

agreed

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.

agreed

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.

Agreed. Note that the modification of ActivityFinalNodeActivation in the revised text below to use a terminateAll operation from StructuredActivityNodeActivation allows this new operation to be overridden in LoopNodeActivation to specify “last wishes before termination” functionality.

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.

agreed

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()

// terminate

agreed

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.

agreed

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.

agreed

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.

agreed

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.

agreed

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)

i = i + 1;
}

agreed

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.

Agreed. Actually it is OK to always create a new link, as long as a link with all matching ends is destroyed first in the case of an association with all ends unique, since links with matching ends are not distinguishable

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.

agreed

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.

Agreed, with the understanding that the term “data value” means specifically an instance of a data type, not an object, which is an instance of a class. Only objects are passed as references, which allows them to be updated mutably. Any value that is not a reference is to be considered an immutable data value.

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()

agreed

: 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).

agreed

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.

agreed

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)

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

agreed

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.”

agreed