Semantics of a Foundational Subset for Executable UML Models Avatar
  1. OMG Specification

Semantics of a Foundational Subset for Executable UML Models — Closed Issues

  • Acronym: FUML
  • Issues Count: 63
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
FUML-55 Reference Menzel in Section 10 FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML_-6 Error in ObjectActivation::dispatchNextEvent FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-5 Modification to AcceptEventActionActivation FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-8 Corrections to previous resolutions FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-7 Additional changes required for action firing semantics FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-4 Additional changes required for structured activity node execution FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-3 Diagram graphics in the fUML specification FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-2 UML input pins do not accept more tokens than their actions can immediately consume FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-1 Values passed out to pins from empty parameter nodes FUML 1.0b2 FUML 1.0 Resolved closed
FUML-51 Revise fUML to be based on UML 2.3 FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-50 Structured activity node execution model needs to be corrected FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-49 Variable needs initialization in InputPinActivation::receiveOffer FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-48 Include activity diagrams for classifier behaviors FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-47 References to uml::Class in OCL FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-46 Problems with OCL for AcceptEventAction::fUML_active_context FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-54 ObjectNodeActivation::unofferedTokens is spurious FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-53 Attributes introduced in CompleteActivities should not be included in the fUML subset FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-45 OCL for SendSignalAction::target_signal_reception is incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-44 OCL incomplete for CallBehaviorAction::proper_context FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-41 InstanceValue constraint is redundant FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-40 Incorrect generalizations in Kernel FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-43 Pin should be abstract FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-42 The composition from ObjectNode to TypedElement is incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-52 ObjectNodeOrderingKind should be in Activities::IntermediateActivities FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-37 A data type should not be allowed to have operations FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-36 A passive class should not be able to specialize an active class FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-31 Only abstract classes should be able to have abstract behavioral features FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-34 Base Semantics FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-33 The superclass of ActvityNode and ActivityEdge should be RedefinableElement FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-39 Items excluded from Kernel FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-38 OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-35 Active class should not have to have classifier behaviors FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-32 Receptions should never be abstract FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-4 An action can consume more tokens from a pin than the allowed multiplicity upper bound FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-3 Issue: InitialNodeActivation::fire should use sendOffers FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-7 Issue: CallActionActivation cannot handle more than one concurrent call FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-6 Issue: ObjectNodeActivation::offeredTokenCount is not initialized FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-5 The call to receiveOffer at the end of ActionActivation::fire could can cause an infinite recursion FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-10 Error in return value of ActivityNodeActivation::removeToken FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-9 Issue: Bug in ReclassifyObjectActionActivation::doAction FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-8 Issue: The result pin of clear and write structural feature actions can be optional FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-2 Issue: ActivityNodeActivation::clearTokens incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-1 Issue: Sending offers from ForkNodeActivation::fire FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-29 8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-28 Error in ReadLinkActionActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-27 8.6.4.2.1 [5]AcceptEventActionActivation::accept(in signalInstance:SignalInstance) FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-26 [FUML] 8.6.3.2.4 CreateLinkActionActivation.doAction() FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-25 7.5.2.2.9 SendSignalAction FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-30 Subclause: 8.5.2.2.6 ActivityParameterNodeActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-11 ExecutionFactory::instantiateVisitor should not use Java reflection FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-22 LoopNodeActivation::doStructuredActivity uses a Java array FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-21 ActionActivation::isSourceFor does not initialize a local variable FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-19 Link::getTypes does not initialize a local variable FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-18 IntegerValue::toString uses Java String.valueOf FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-24 [FUML] 7.4.2.2.14 ObjectFlow FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-23 Event should be a specialization of PackageableElement FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-14 CompoundValue::equals does not conform to Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-13 BooleanValue::toString uses Java String.valueOf FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-12 ExecutionFactory::getStrategy doesn't follow conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-16 FeatureValue::hasEqualValues does not follow Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-15 EnumerationValue::specify missing a "this" FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-20 UnlimitedNaturalValue::toString does not follow Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-17 InstanceValueEvaluation::evaluate does not initialize local variables FUML 1.0b1 FUML 1.0b2 Resolved closed

Issues Descriptions


Error in ObjectActivation::dispatchNextEvent

  • Key: FUML_-6
  • Legacy Issue Number: 15090
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.4.3.2.5 ObjectActivation

    In the operation ObjectActivation::dispatchNextEvent, the line

    EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(j-1);

    should be:

    EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(matchingEventAccepterIndexes.getValue(j-1));

  • Reported: FUML 1.0b2 — Thu, 25 Feb 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Modification to AcceptEventActionActivation

  • Key: FUML_-5
  • Legacy Issue Number: 15089
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.6.4.2.1 AcceptEventActionActivation

    The revisions adopted to resolve Issue 14550 (Revise fUML to be based on UML 2.3) necessitate a change to AcceptEventActionActivation that was not included in the adopted resolution. The resolution to 14550 adds a “firing” attribute to ActionActivation, which is set to false at the end of the “fire” operation. However, AcceptEventActionActivation is a special case among the subclasses of ActionActivation in that it does not call its superclass “fire” operation. Therefore, the “firing” attribute also needs to be explicitly set to false at the end of AcceptEventActionActivation::fire. Otherwise, if an accept event action is not locally reentrant (which is the default), it will never be able to fire more than once.

  • Reported: FUML 1.0b2 — Thu, 25 Feb 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Corrections to previous resolutions

  • Key: FUML_-8
  • Legacy Issue Number: 15127
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The resolution text for the following fUML issues had minor errors and inconsistencies. The following points reflect the correct interpretation for changes to be made to the specification according to these resolutions.

    Issue 13435: Type "instanceVistor" for "instanceVisitor" occurs in a number of places, but not in any of the revised code snippets. The correct spelling is “instanceVisitor”.
    Issue 14545: The revised code includes "super.isReady" instead of "super.isReady()", which is clearly a syntax error. The correct code is “super.isReady()”.
    Issue 14550: The resolution refers to changing "Behavior::isReentrant" in Subclause 7.3.2.2.4, while the correct Behavior subclause is actually 7.3.2.2.1.
    Issue 14550: The resolution says to add an operation "countOfferedValues" to the class ObjectNodeActivation, but then refers to this operation in one place later as "countTotalValues". The correct operation name is “countOfferedValues”.
    Issue 14618: The revised text section of the resolution refers to “Subclause 8.6.2.2.15, ObjectNodeActivation”, whereas the ccorrect ObjectNodeActivation subclause is 8.5.2.2.15 (as given in the issue summary).

  • Reported: FUML 1.0b2 — Wed, 17 Mar 2010 04:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Additional changes required for action firing semantics

  • Key: FUML_-7
  • Legacy Issue Number: 15094
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.6.2.2.1 ActionActivation

    Before the adoption of the resolution to Issue 14550 (Revise fUML to be based on UML 2.3), when an action fired it accepted all tokens offered to its input pins, even if this was more than the multiplicity upper bound of a pin. However, on any one firing, it would only consume at most a number of tokens equal to the multiplicity upper bound on each pin. If tokens were left on pins greater than the multiplicity lower bounds, then it would fire again.

    UML 2.3 clarified that an action never accepts offers for tokens above the multiplicity upper bounds of its pins. The semantics of actions were changed in the resolution of 14550 to be consistent with this. However, the semantics for firing the again were not properly changed to reflect the fact that, if the action is, indeed, ready to fire again, the tokens it needs will not actually be on its input pins yet. The semantics for firing again needs to be updated to explicitly accept the pending offers for incoming tokens when the action fires again.

  • Reported: FUML 1.0b2 — Sat, 27 Feb 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Additional changes required for structured activity node execution

  • Key: FUML_-4
  • Legacy Issue Number: 15088
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.5.2.2.5 ActivityNodeActivationGroup

    Some necessary changes to the specification for ActivityNodeActivationGroup were inadvertently left out of the revised text for the resolution to Issue 14547 approved by the FTF. The additional changes are:

    Added the operation checkIncomingEdges ( in incomingEdges : ActivityEdgeInstance [0..*], in activations : ActivityNodeActivation [0..*] ) : Boolean with the code:

    // Check if any incoming edges have a source in a given set of activations.

    int j = 1;

    boolean notFound = true;

    while (j <= incomingEdges.size() & notFound) {

    int k = 1;

    while (k <= activations.size() & notFound) {

    if (activations.getValue(k-1).isSourceFor(incomingEdges.getValue(j-1)))

    { notFound = false; }

    k = k + 1;

    }

    j = j + 1;

    }

    return notFound;

    In the operation Run, replace the code:

    ActivityEdgeInstanceList incomingEdges = activation.incomingEdges;

    boolean isEnabled;

    if (activation instanceof ActionActivation)

    { isEnabled = ((Action)activation.node).input.size() == 0; }

    else

    { isEnabled = (activation instanceof ControlNodeActivation) | (activation instanceof ActivityParameterNodeActivation); }

    int j = 1;

    while (j <= incomingEdges.size() & isEnabled) {

    int k = 1;

    while (k <= activations.size() & isEnabled) {

    if (activations.getValue(k-1).isSourceFor(incomingEdges.getValue(j-1)))

    { isEnabled = false; }

    k = k + 1;

    }

    j = j + 1;

    }

    if (isEnabled)

    { Debug.println("[run] Node " + activation.node.name + " is enabled."); enabledActivations.addValue(activation); }

    }

    With:

    if (activation instanceof ActionActivation |

    activation instanceof ControlNodeActivation |

    activation instanceof ActivityParameterNodeActivation) {

    boolean isEnabled = this.checkIncomingEdges(activation.incomingEdges, activations);

    // For an action activation, also consider incoming edges to input pins

    if (isEnabled & activation instanceof ActionActivation) {

    InputPinList inputPins = ((Action)activation.node).input;

    int j = 1;

    while (j <= inputPins.size() & isEnabled)

    { InputPin inputPin = inputPins.getValue(j-1); ActivityEdgeInstanceList inputEdges = ((ActionActivation)activation).getPinActivation(inputPin).incomingEdges; isEnabled = this.checkIncomingEdges(inputEdges, activations); j = j + 1; }

    }

    if (isEnabled)

    { Debug.println("[run] Node " + activation.node.name + " is enabled."); enabledActivations.addValue(activation); }

    }

    }

  • Reported: FUML 1.0b2 — Thu, 25 Feb 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Diagram graphics in the fUML specification

  • Key: FUML_-3
  • Legacy Issue Number: 15004
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, v1.0 Beta 2 (ptc/2009-10-05)

    All the abstract syntax diagrams in the spec should:

    1. Use the “dot notation” to show which association ends are owned by classes rather than by the associations. Even though the fUML subset diagrams follow the same convention as in the UML Superstructure spec that all navigable ends are class owned and all non-navigable ends are association owned, it is still better make this explicitly clear. This is especially so for fUML, since, when the abstract syntax interpreted as an fUML model itself when referenced from the execution model, the navigable ends are a always accessed as class-owned structural features and the associations themselves are ignored (since they don’t meet the fUML constraint of owning all their ends).

    2. Show subsetting and redefinition annotations, consistent (for the fUML subset) with the similar annotations in the UML superstructure abstract syntax. Even though subsetting and redefinition are not in the fUML feature subset, the fUML abstract syntax model is supposed to itself be a proper subset of the UML abstract syntax model and, therefore, needs to include subsetting and redefinition consistent with the full model. Indeed, these relationships are in the fUML abstract syntax model as serialized in the normative XMI, they are just currently not shown on the diagrams. (Note also that Subclause 8.1 discusses the conventions on derivation and redefinition for fUML.)

  • Reported: FUML 1.0b2 — Fri, 22 Jan 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Agreed. see pages 50 - 66 of OMG document ptc/2010-03-12 for details

  • Updated: Sat, 7 Mar 2015 08:56 GMT

UML input pins do not accept more tokens than their actions can immediately consume

  • Key: FUML_-2
  • Legacy Issue Number: 14992
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML input pins do not accept more tokens than their actions can
    immediately consume. The execution engine should reflect this.

    The Activities, Action, Semantics, item 1, says "The object flow
    prerequisite is satisfied when all of the input pins are offered all
    necessary tokens and accept them all at once, precluding them from being
    consumed by any other actions. This ensures that multiple action
    executions competing for tokens do not accept only some of the tokens
    they need to begin, causing deadlock as each execution waits for tokens
    that are already taken by others."

    The "necessary tokens" in the first sentence above are the ones needed
    to execute the actions (meeting the minimum multiplicity), but should
    include any additional ones offered up the maximum multiplicity. Only
    these are accepted by the input pins, then immediately consumed by the
    action. The second sentence gives the motivation, which is to avoid
    having tokens in input pins that are not immediately consumed. This
    would prevent those tokens from being used to execute other actions,
    potentially creating deadlock or starvation. Deadlock is discussed more
    in issue 7221 of the UML 2.0 FTF report
    (http://doc.omg.org/ptc/04-10-01).

    This is also clarified in the revised text for UML RTF issue 13914.

  • Reported: FUML 1.0b2 — Sun, 10 Jan 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Resolution:
    The resolution to Issue 14550, in response to UML Issue 13914, changes the fUML semantics so that the fUML semantics reflect the constraint discussed in the issue.
    Revised Text:
    None.
    Disposition: Duplicate/Merged

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Values passed out to pins from empty parameter nodes

  • Key: FUML_-1
  • Legacy Issue Number: 14990
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In UML empty parameter nodes are currently given the null value when an
    activity terminates. The semantics of ActivityParameterNode says: "If
    some output parameter nodes are empty at that time [when the activity is
    finished], they are assigned the null token, and the activity
    terminates.

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on
    ActivityParameterNode to indicate whether null tokens are passed out to
    pins when the activity is finished executing and the activity parameter
    node is empty, or whether nothing is passed out. In ExecUML this
    attribute value would always be for the second option.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — FUML 1.0
  • Disposition Summary:

    Resolution:
    The resolution to Issue 14550, in response to UML Issue 9863 on the output of read actions for no values, changes the fUML semantics so that the discrepancy described in this issue no longer exists.
    Revised Text:
    None.
    Disposition: Duplicate/Merged

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Revise fUML to be based on UML 2.3

  • Key: FUML-51
  • Legacy Issue Number: 14550
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The fUML syntax subset and its semantics are currently based on UML 2.2. The UML 2.3 resolved a number of issues relevant to execution semantics. The fUML specification should be updated so it is based on UML 2.3 rather than UML 2.2.

    Relevant semantic issues include, in particular:

    • 6111 Reentrancy 1
    • 9863 Section: Actions – Output of read actions for no values
    • 9870 Actions on non-unique properties with location specified
    • 9858 Default weight
    • 9873 Section: Common Behavior – isReentrant should default to true
    • 10045 11.3.47 on StructuralFeatureAction (and related sections on subclasses)
    • 11646 StructuredActivityNode
    • 13898 what's the difference > between weight=1 and weight=*?
    • 13914 Clarify that input pins do not accept more tokens than their actions can immediately consume
  • Reported: FUML 1.0b1 — Thu, 18 Dec 2008 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    In addition to the issues noted above, the following UML RTF Issues resolved in UML 2.3 make abstract syntax changes within the fUML subset. While these do not result in any semantic changes, they should be made in the fUML abstract syntax to ensure that it remains a proper subset of the UML 2.3 abstract syntax.

    · 8682 A test case cannot be empty
    · 10081 Section 13.2 (body property of OpaqueBehavior)
    · 10515 Section 7 (property isLeaf inherited by Class)
    · 12558 Section 13.3 (multiplicity of Reception::signal)

    For the issues identified in the issue, which do have semantic effect, the following summarizes the changes needed in the fUML Execution Model.

    · 6111 - The resolution to this issue adds the attribute isLocallyReentrant to Action. The default is false, meaning that an action cannot fire more than once concurrently within the same activity execution. The current fUML behavior effectively presumes isLocallyReentrant=true, that is, that all actions can fire multiple times concurrently. The fUML semantics should be updated to support isLocallyReentrant=false as the default, as well as isLocallyReentrant=true. This requires adding an attribute to the ActionActivation class to record that the action is firing and checking this in the isReady operation. The check at the end of an action firing for whether an action should fire again should trigger any firing that is still pending after being delayed by a lack of local reentrancy.
    · 9863 - The resolution of this issue clarifies that a read structural feature action will offer a null token if it reads an empty structural feature and that a read link action will offer a null token if there are no matching links. Currently, the fUML semantics are that no offers are made from an object node that contains no tokens, including the output pins of actions. This should be changed in general so that an object node offers a null token when it fires and holds no tokens. This can be done by overriding the sendOffers operation in ObjectNodeActivation.
    · 9858 - This issue suggested that the default activity edge weight should be * rather than 1. However, the resolution clarified that weight=1 actually does have the behavior the issue writer desired, so the issue was closed with no change. ActivityEdge::weight is defined in the CompleteActivities package, so it is not actually included in the fUML subset. However, this issue resolution means that the current fUML semantics are, in fact, consistent with the default weight=1, rather than weight=*, as previously thought.
    · 9870 - The resolution of this issue changes remove structural feature value actions so that they do not have a value pin if they have a removeAt pin. This requires an update to the RemoveStructuralFeatureValueActionActivation::doAction operation.
    · 9873 - The resolution of this issue changes the default to true for Behavior::isReentrant. However, the fUML subset already requires this, so no change is necessary. The fUML semantics are now consistent with the UML default, however.
    · 10045 - The resolution of this issue clarifies that a structural feature action can be used to read and write an association end of a binary association as if it was a feature of the opposite classifier, even if the end is not actually owned by that classifier. This requires updating the doAction operations of the various structural feature action activation classes so that the actions behave like the corresponding link action if their structural feature is an association end. (Note that association ends are never classifier-owned in fUML.)
    · 11646 - The resolution of this issue adds structuredNodeInput and structuredNodeOutput properties to StructuredActivityNode, subsetting the input and output properties of Action. This allows structured activity nodes to properly own input and output pins. However, this actually has no direct effect on the fUML Execution Model, which already presumed that structured activity nodes could own pins, but referenced them using the inherited Action::input and output properties.
    · 13898 - The resolution to this issue clarifies that the weight on an activity edge only specifies the minimum number of tokens that must be accepted for tokens to flow, not the maximum number that can flow. The fUML semantics are consistent with the default of weight=1. (See also the discussion of Issue 9858 above.)
    · 13914 - The resolution to this issue clarifies that an input pin cannot accept more tokens than their actions can immediately consume. Currently, fUML semantics allows an input pin to accept all tokens offered to it, which then can be consumed by its action over multiple firings. This can be corrected by overriding the takeOfferedTokens operation in PinActivation to take no more tokens than the multiplicity upper bound of the pin. (Note that by doing this in PinActivation rather than InputPinActivation, an output pin of a structured activity node is also restricted to not take more tokens than its multiplicity upper bound from its incoming flows - which is correct per UML Superstructure Subclause 11.3.27.) This also requires updating the takeOfferedTokens operation on ActivityEdgeInstance to allow taking a specific number of tokens, rather than just the next group of tokens offered together.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Structured activity node execution model needs to be corrected

  • Key: FUML-50
  • Legacy Issue Number: 14547
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)
    Subclause: 8.5.3 Complete Structured Activities, 8.5.4 Extra Structured Activities

    The execution model for structured activity nodes has never been tested and thus likely contains errors. At the very least, the specifications for ConditionalNodeActivation and LoopNodeActivation need to be corrected to reflect the fact that the test and body properties only reference executable nodes, not all the nodes that might be contained in the structured activity node and the specification for StructuredActivityNode needs to handle input and output pins.

  • Reported: FUML 1.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    The execution model for structured activity nodes, conditional nodes, loop nodes and expansion regions has now been updated and tested, per the proposed revisions to the specification text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Variable needs initialization in InputPinActivation::receiveOffer

  • Key: FUML-49
  • Legacy Issue Number: 14545
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    In the method for InputPinActivation::receiveOffer, the declaration “boolean ready;” should have an initialization, per the requirements of Annex A.

  • Reported: FUML 1.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Actually, the offending declaration is in the method for isReady, not receiveOffer. It should have an initialization.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Include activity diagrams for classifier behaviors

  • Key: FUML-48
  • Legacy Issue Number: 14533
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)
    Subclauses: 8.4.3.2.2 ClassifierBehaviorExecutionActivity, 8.4.3.2.4 EventDispatchLoop

    These are activities that should be the classifier behaviors for ClassifierBehaviorExecution and ObjectActivation and activity diagrams should be included in the specification document for them, rather than class descriptions.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

References to uml::Class in OCL

  • Key: FUML-47
  • Legacy Issue Number: 14532
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)
    Subclauses: 7.5.4.2.1 AcceptEventAction, 7.5.4.2.2 ReadExtentAction, 7.5.4.2.4 ReclassifyObjectAction

    The OCL for constraint [3] of AcceptEventAction, constraint [1] of ReadExtentAction and constraint [1] of ReclassifyObjectAction reference “uml::Class”. These references should be changed to just “Class” (i.e., Class from the fUML abstract syntax model).

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems with OCL for AcceptEventAction::fUML_active_context

  • Key: FUML-46
  • Legacy Issue Number: 14531
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The OCL for constraint [1] of AcceptEventAction (fUML_active_context) uses “self.activity” to get the activity for the accept event action. However, the activity property of an action is only non-empty if the action is directly owned by the activity, not nested in a structured activity node. Also, the OCL uses the getContext() operation, which does not seem to be defined in the UML Superstructure or the fUML specification.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Note that the subclause for AcceptEventAction is actually 7.5.4.2.1.

    Action has an attribute "context" that gives "the classifier that owns the behavior of which this action is a part". This should be used instead of the "getContext()" operation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNodeActivation::unofferedTokens is spurious

  • Key: FUML-54
  • Legacy Issue Number: 14618
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    ObjectNodeActivation has an unofferedTokens association listed in 8.5.2.2.15 that is never used in any operation method and is not shown in Figure 69.

  • Reported: FUML 1.0b1 — Tue, 10 Nov 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    The association should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes introduced in CompleteActivities should not be included in the fUML subset

  • Key: FUML-53
  • Legacy Issue Number: 14561
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    In Subclause 7.4.1, it says that “The UML 2 Superstructure package CompleteActivities is excluded in its entirety from fUML”. However, there are several Activities metaclasses in the fUML subset that currently include attributes that are only introduced in CompleteActivities. These are:

    Activity::isSingleExecution

    ObjectFlow::isMulticast

    ObjectFlow::isMultiReceive

    ObjectNode::ordering

    ObjectNode::isControlType

    Pin::isControl

    JoinNode::isCombineDuplicate

    Parameter::isException

    Parameter::isStream

    Parameter::effect

    These attributes should be removed from the fUML abstract syntax, along with any constraints that currently reference them. Note that metaclass properties that are the ends of associations introduced in CompleteActivities have already been excluded from the fUML subset.

  • Reported: FUML 1.0b1 — Wed, 14 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed. This is consistent with exclusions made in other areas of the fUML subset.
    In addition, once the attributes ObjectNode::ordering and Parameter::effect are removed, it is no longer necessary to include the enumerations ObjectNodeOrderingKind and ParameterEffectKind in the fUML subset.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL for SendSignalAction::target_signal_reception is incorrect

  • Key: FUML-45
  • Legacy Issue Number: 14530
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    In the OCL for constraint [1] of SendSignalAction (target_signal_reception), “self.target.activity” should be “self.target.type”.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    This is a (partial) duplicate of Issue 13511, which is already resolved.
    Revised Text:
    None.
    Disposition: Duplicate/merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL incomplete for CallBehaviorAction::proper_context

  • Key: FUML-44
  • Legacy Issue Number: 14529
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The OCL for constraint [3] of CallBehaviorAction (propert_context) is incomplete.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceValue constraint is redundant

  • Key: FUML-41
  • Legacy Issue Number: 14525
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The allowedClassifiers constraint on InstanceValue is redundant with the possible_classifiers constraint on InstanceSpecification.

    Recommendation: Remove the constraint on InstanceValue.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed. In addition, simplify the possible_classifiers constraint on InstanceSpecification by removing the specific check that the instance classifier is an enumeration, since enumerations are kinds of data types.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect generalizations in Kernel

  • Key: FUML-40
  • Legacy Issue Number: 14524
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    During work on the fUML submission, the abstract syntax generalization hierarchy was altered to collapse a number of cases of multiple inheritance to single inheritance, in order to allow a mapping to Java for bootstrap execution purposes. Unfortunately, some of these alterations remain in the spec, even though this violates the intended strict subsetting of the full UML Superstructure abstract syntax. The specific cases include:

    • Type -> Namespace -> PackageableElement in Figure 15
    • Namespace -> PackageableElement in Figure 16

    Recommendation:

    The normative fUML abstract syntax should be updated so its generalization hierarchy is a strict subset of that in the full UML superstructure abstract syntax.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin should be abstract

  • Key: FUML-43
  • Legacy Issue Number: 14528
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    In Figure 39, Pin should be shown as abstract.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The composition from ObjectNode to TypedElement is incorrect

  • Key: FUML-42
  • Legacy Issue Number: 14527
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The composition association from ObjectNode to TypedElement (see also Figure 31) should be a generalization, consistent with the UML Superstructure abstract syntax.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNodeOrderingKind should be in Activities::IntermediateActivities

  • Key: FUML-52
  • Legacy Issue Number: 14556
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models Syntax CMOF (ad/2008-08-05)

    While it is not apparent in the spec document, in the normative Syntax CMOF, the enumeration ObjectOrderingKind is in the package Actions::BasicActions when it should be in Activities::IntermediateActivities (consistent with the UML Superstructure).

  • Reported: FUML 1.0b1 — Mon, 12 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Per the resolution for Issue 14561, the enumeration ObjectOrderingKind is no longer needed in the fUML subset. Therefore, this issue is effectively handled by that resolution.

    Revised Text:
    None.
    Disposition: Duplicate/merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A data type should not be allowed to have operations

  • Key: FUML-37
  • Legacy Issue Number: 14521
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    A data type should not be allowed to have operations. A data type is not a behaviored classifier, so it cannot own behaviors and so cannot provide methods to actually implement any operations.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A passive class should not be able to specialize an active class

  • Key: FUML-36
  • Legacy Issue Number: 14520
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    If a class has any parents that are active, then the class should be active, since it effectively “inherits” the classifier behaviors from its active parents. (This would still allow an active class to have passive parents, though.)

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Only abstract classes should be able to have abstract behavioral features

  • Key: FUML-31
  • Legacy Issue Number: 13882
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 7.2.2.2.3 Class

    The UML superstructure does not restrict abstract behavioral features to only be members of abstract classes. However, trying to invoke an abstract operation on an object instantiated from a non abstract will result in an execution error. Therefore, fUML should add a constraint on Class that none of its behavioral features are abstract unless the class is abstract. That is:

    self.members->select(oclIsKindOf(BehavioralFeature))->exists(isAbstract) implies self.isAbstract

  • Reported: FUML 1.0b1 — Thu, 23 Apr 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Add the constraint as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Base Semantics

  • Key: FUML-34
  • Legacy Issue Number: 14193
  • Status: closed  
  • Source: Watt Systems Technologies Inc. ( Kenneth A. Lloyd, Jr.)
  • Summary:

    Base Semantics A definition of the execution semantics of those UML constructs [is] used in the execution model, using some formalism other than the execution model itself. Since the execution model is a UML model, the base semantics are necessary in order to provide non-circular grounding for the execution semantics defined by the execution model." Either a verb such as the word [is] needs to be inserted, otherwise a sentence fragment results with uncertain meaning. Furthermore, the challenge expressed in the statement, it seems, is trying to avoid a self-referential, therefore a potentially inconsistent model.

  • Reported: FUML 1.0b1 — Mon, 17 Aug 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    All the definitions in Clause 4 are in the form of (or begin with) a noun phrase sentence fragment, so the style for Base Semantics is consistent. The definition is taken directly from the glossary of the original RFP, and is considered to be the required definition of base semantics for the purpose of this specification.
    Revised Text:
    None.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The superclass of ActvityNode and ActivityEdge should be RedefinableElement

  • Key: FUML-33
  • Legacy Issue Number: 13921
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (ptc/2008-11-03)
    Subclause: 7.4.2.2.2 ActivityEdge, 7.4.2.2.7 ControlNode

    The fUML abstract syntax currently has NamedElement as the immediate superclass of ActivityNode and ActivityEdge. However, in UML, at the level of IntermediateActivities included in the fUML subset, ActivityNode and ActivityEdge are subclasses of RedefinableElement. They should be in the fUML abstract syntax, too.

  • Reported: FUML 1.0b1 — Wed, 6 May 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Items excluded from Kernel

  • Key: FUML-39
  • Legacy Issue Number: 14523
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    There are some things excluded from the Kernel in the fUML subset that would probably be better to include.

    • ElementImport and PackageImport: While these are irrelevant to execution, they will often be used in models with elements that are otherwise executable. It seems unnecessary to force these to be stripped out in order to not have the model rejected by an execution tool.
    • Class::nestedClassifier: It is sometimes useful to nest one classifier in another, and this would have no effect on the execution semantics. So it also seems unnecessary to force a model to be re-organized to remove such nesting just in order to not have the model rejected by an execution tool.
    • Package::ownedType and Package::nestedPackage: These derived properties are not needed for fUML, but they really should be included in the fUML subset in order to make it a well formed subset of UML L3 and to ensure that constraints in the UML spec involving these properties an be carried over without change into fUML.
  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language

  • Key: FUML-38
  • Legacy Issue Number: 14522
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    The OpaqueBehavior::opaqueBehavior attribute should instead be “language”, consistent with the UML 2.2 specification.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Active class should not have to have classifier behaviors

  • Key: FUML-35
  • Legacy Issue Number: 14519
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Constraint [1] “If isActive is true, then the class must be a behavior or have a classifier behavior” is too strong. It should at least be possible to have an abstract active class that does not have a classifier behavior. Indeed, the execution model for an active class still works even if concrete classes are allowed to have no classifier behavior (instances just don’t do anything once started), so perhaps the constraint is not necessary at all.

  • Reported: FUML 1.0b1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    It is agreed that it is not necessary to require that an active class have a classifier behavior. However, it is still necessary to have a constraint requiring a class to be active if it has a classifier behavior.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Receptions should never be abstract

  • Key: FUML-32
  • Legacy Issue Number: 13883
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Subclause: 7.3.3.2.3 Reception

    A Reception is a kind of BehavioralFeature and therefore inherits the isAbstract attribute. However, it doesn't really make sense for receptions to be abstract, since fUML doesn't allow them to have methods anyway. Further, since UML does not seem to provide any way to redefine a reception, it would be impossible to ever redefine it in a subclass to be non-abstract.

    The constraint "not isAbstract" should be added to Reception.

  • Reported: FUML 1.0b1 — Thu, 23 Apr 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Add the constraint as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An action can consume more tokens from a pin than the allowed multiplicity upper bound

  • Key: FUML-4
  • Legacy Issue Number: 13310
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Sections: 8.5.2.2.15 (ObjectNodeActivation), 8.6.2.2.1 (ActionActivation), 8.6.2.2.7 (OutputPinActivation), 8.6.2.2.8 (PinActivation)

    Summary:

    When an action fires, all offered tokens are accepted on all input pins (because the default object flow weight for fUML is “*”). However, an action cannot consume more tokens from an input pin than the multiplicity upper bound for that pin. Any additional tokens remain on the pin, the intent being that they can be consumed if and when the action fires again.

    However, currently the ActionActivation::getTokens operation (used to get values from the tokens on an input pin) uses the ActivityNodeActivation::takeTokens operation inherited by InputPin. This operation returns all the tokens on the pin and clears them from the pin, without respecting the multiplicity upper bound. As a result, the ActionActivation::getTokens operation does not respect this upper bound either.

    Proposed resolution:

    Add the following operation to ObjectNodeActivation:

    ObjectNodeActivation::takeUnofferedTokens(): Token[*]

    // Take the next set of unoffered tokens to be offered from this node activation and return them.

    TokenList tokens = this.getUnofferedTokens();

    for (int i = 0; i < tokens.size(); i++)

    { Token token = tokens.getValue(i); token.withdraw(); }

    return tokens;

    (Note: The getUnofferedTokens operation returns a number of tokens equal to the result of the countUnofferedTokens operation. This is overridden in InputPin to limit the count to at most the multiplicity upper bound.)

    In ActionActivation::getTokens, replace the call to getTokens with a call to getUnofferedTokens.

    Add the following operation to OutputPinActivation (overriding the inherited operation):

    OutputPinActivation::fire(incomingTokens: Token[*])

    // Add incoming tokens and send offers on outgoing edges.

    super.fire(incomingTokens);

    this.sendUnofferedTokens();

    In PinActivation::fire, remove the call to this.sendUnofferedTokens.

    (Note: The change to not automatically send the tokens from an input pin is necessary to avoid having the tokens marked as sent before they are read by an action that is not a structured activity node. An input pin can only have outgoing flows if it is an input pin of a structured activity node anyway, so the sending of offers from input pins should be handled in the semantics of structured activity nodes. This will be addressed in a separate, related issue on structured activity node activations.)

  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: InitialNodeActivation::fire should use sendOffers

  • Key: FUML-3
  • Legacy Issue Number: 13309
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Section: 8.5.2.2.12 (InitialNodeActivation)

    Summary:

    The InitialNodeActivation::fire operation is documented as “Create a single token and send offers for it.” However, this operation ends by calling super.fire, which only happens by default to just send offers for the given tokens. The initial node activation semantics should not depend on this default, but should explicitly call this.sendOffers, so that the semantics is clear.

    Proposed resolution:

    Replace:

    super.fire(tokens);

    with:

    this.sendOffers(tokens);

  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: CallActionActivation cannot handle more than one concurrent call

  • Key: FUML-7
  • Legacy Issue Number: 13313
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Section: 8.6.2.2.2 (CallActionActivation)

    Summary:

    A call action may fire multiple times concurrently. A call action activation needs to keep track of currently ongoing call executions, so that they can all be terminated if the call action activation is terminated. However, CallActionActivation::callExecution currently has a multiplicity upper bound of 1. Therefore, if a call action fires more than once concurrently, subsequent firings will incorrectly overwrite the reference to the callExecution from the first firing.

    Proposed resolution:

    Under associations, replace CallActionActivation::callExecution with:

    callExecutions: Execution [*] The set of execution objects for currently ongoing calls made through this call action activation.

    At the beginning of CallActionActivation::doAction, replace:

    this.callExecution = this.getCallExecution();

    if (this.callExecution != null) {

    with:

    Execution callExecution = this.getCallExecution();

    if (callExecution != null) {

    this.callExecutions.addValue(callExecution);

    Throughout CallActionActivation::doAction, replace with this.callExecution with callExection. At the end of CallActionActivation::doAction, replace:

    this.callExecution = null;

    with:

    this.removeCallExecution(callExecution);

    Replace the body of CallActionActivation::terminate with:

    // Terminate all call executions (if any), then terminate the call action activation (self).

    for (int i = 0; i < this.callExecutions.size(); i++)

    { Execution execution = this.callExecutions.getValue(i); execution.terminate(); }

    super.terminate();

    Add the following operation:

    CallActionActivation::removeCallExecution(execution: Execution)

    // Remove the given execution from the current list of call executions.

    boolean notFound = true;

    int i = 1;

    while (notFound & i <= this.callExecutions.size()) {

    if (this.callExecutions.getValue(i-1) == execution)

    { this.callExecutions.removeValue(i-1); notFound = false; }

    }

  • Reported: FUML 1.0b1 — Wed, 21 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: ObjectNodeActivation::offeredTokenCount is not initialized

  • Key: FUML-6
  • Legacy Issue Number: 13312
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Section: 8.5.2.2.15 (ObjectNodeActivation)

    Summary:

    The ObjectNodeActivation::offeredTokenCount attribute is never initialized. This is not a problem for Java execution, since Java semantics initializes integer variables to zero by default. But this is not correct per UML execution semantics.

    Proposed resolution:

    Add an ObjectNodeActivation::run() operation that overrides the inherited operation with the following body:

    super.run();

    this.offeredTokenCount = 0;

  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The call to receiveOffer at the end of ActionActivation::fire could can cause an infinite recursion

  • Key: FUML-5
  • Legacy Issue Number: 13311
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Section: 8.6.2.2.1 (ActionActivation)

    Summary:

    At the end of ActionActivation::fire, a check is made to see if the action should fire again. The intent is that this should happen if the action has input pins and there are still tokens left on one or more pins after the previous firing (because there were more tokens on the pins than the multiplicity upper bound). Currently, this check is made by first checking that the action has input pins and then calling receiveOffer, so that the isReady test can check for inputs.

    However, if the action input pins, but they are all optional (i.e., multiplicity lower bound of 0), and no incoming control flows, then the action will be ready to fire whether or not there are any inputs on the pins. This will result in an infinite recursion of the action continually firing.

    Proposed resolution:

    Replace:

    // Activate the action again, if prerequisites are still satisfied (i.e., when tokens have been left on input pins).

    Debug.println("[fire] Checking if " + this.node.name + " should fire again...");

    if (((Action)(this.node)).input.size() > 0)

    { this.receiveOffer(); }

    with:

    // Activate the action again, if tokens have been left on input pins and the action has no incoming control flows.

    Debug.println("[fire] Checking if " + this.node.name + " should fire again...");

    if (((Action)(this.node)).input.size() > 0 & this.node.incoming.size() == 0) {

    boolean fireAgain = true;

    InputPinList inputPins = ((Action)(this.node)).input;

    int j = 1;

    while (fireAgain & j <= inputPins.size())

    { PinActivation inputPinActivation = this.getPinActivation(inputPins.getValue(j-1)); fireAgain = inputPinActivation.isReady() & inputPinActivation.countUnofferedTokens() > 0; j = j + 1; }

    if (fireAgain)

    { this.fire(new TokenList()); }

    }

    (Note: This code does not check for incoming control tokens, but, rather, only fires the action again if it has no incoming control flows. If an action has incoming control flows and inputs left on its input pins, then an offer on a control flow will trigger the action to fire again.)

  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in return value of ActivityNodeActivation::removeToken

  • Key: FUML-10
  • Legacy Issue Number: 13450
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The ActivityNodeActivation::removeToken operation is documented as returning 0 if no token is removed. However, the code does not currently do this.

    Proposed Resolution:

    At the end of the operation replace:

    return i -1;

    with:

    if (notFound)

    { i = 0; }

    else

    { i = i – 1; return i; }
  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Bug in ReclassifyObjectActionActivation::doAction

  • Key: FUML-9
  • Legacy Issue Number: 13315
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    In ReclassifyObjectActionActivation::doAction, there is a for loop with loop variable “n”. However, the loop test uses “i” instead of “n”.

    Proposed resolution:

    Replace:

    for (int n = 0; i < newClassifiers.size(); n++) {

    with:

    for (int n = 0; n < newClassifiers.size(); n++) {

  • Reported: FUML 1.0b1 — Wed, 21 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: The result pin of clear and write structural feature actions can be optional

  • Key: FUML-8
  • Legacy Issue Number: 13314
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundation Subset for Executable UML Models, FTF – Beta 1 (ptc/08-11-03)
    Sections: 8.6.3.2.1 (AddStructuralFeatureValueActionActivation), 8.6.3.2.3 (ClearStructuralFeatureActionActivation), 8.6.3.2.12 (RemoveStructuralFeatureValueActionActivation)

    Summary:

    UML 2.2 added an optional result pin to clear and write structural feature actions. However, the corresponding activation doAction operations assume the result pins are mandatory. If an action does not have a result pin, an error results.

    Proposed resolution:

    At the end of the doAction operations for AddStructuralFeatureValueActionActivation, ClearStructuralFeatureActionActivation and RemoveStructuralFeatureValueActionActivation, replace:

    this.putToken(action.result, value);

    with:

    if (action.result != null)

    { this.putToken(action.result, value); }
  • Reported: FUML 1.0b1 — Wed, 21 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: ActivityNodeActivation::clearTokens incorrect

  • Key: FUML-2
  • Legacy Issue Number: 13308
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Section: 8.5.2.2.3 (ActivityNodeActivation)

    Summary:

    The logic for the ActivityNodeActivation::clearTokens operation is incorrect. As coded, this operation withdraws each token held by an activity node activation. However, as each token is withdrawn, it gets removed from the activity node. This means that the indexing of the getValue used to get the next held token will be incorrect.

    Proposed resolution:

    Replace the current code with the following:

    while (this.heldTokens.size() > 0)

    { this.heldTokens.getValue(0).withdraw(); }
  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Sending offers from ForkNodeActivation::fire

  • Key: FUML-1
  • Legacy Issue Number: 13307
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    At the end of the ForkNodeActivation::fire operation, offers are sent on all outgoing edges. However, the loop used to do this repeats the logic already in the inherited sendOffers operation, except that the sending is not indicated to be done concurrently, as it should be.

    Proposed resolution:

    Replace the loop:

    for (int i = 0; i < outgoingEdges.size(); i++)

    { ActivityEdgeInstance outgoingEdge = outgoingEdges.getValue(i); outgoingEdge.sendOffer(forkedTokens); }

    with:

    this.sendOffers(forkedTokens);

  • Reported: FUML 1.0b1 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Replace the offending loop as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation

  • Key: FUML-29
  • Legacy Issue Number: 13873
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

    Section: 8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation

    Depends on: http://www.omg.org/issues/fuml-ftf.html#Issue13544

    Summary:

    Part of CreateLinkActionActivation.doAction() entails destroying all links that have a value for any end for which isReplaceAll is true. (see fUML 1.0, page 238). This involves the following chain of invocations:

    • fUML.Semantics.Actions.IntermediateActions.LinkActionActivation.endMatchesEndData(Link, LinkEndData) – see fUML 1.0, page 238;
    • fUML.Semantics.Actions.BasicActions.ActionActivation.getTokens(InputPin) – see fUML 1.0, page 233;
    • fUML.Semantics.Activities.IntermediateActivities.ActivityNodeActivation.takeTokens() – see fUML 1.0, p. 215

    By taking the tokens from the pin activation corresponding to the input pin, LinkActionActivation.endMatchesEndData() induces side effects on the state of the execution engine each time it is called.

    Proposed Resolution:

    Resolving this issue entails 3 things:

    a) Defining a read-only operation to read the tokens available on an input pin:

    fUML.Semantics.Actions.BasicActions.ActionActivation.readTokens(InputPin)

    /**

    • NFR 04/16/2009 For LinkActionActivation.endMatchesEndData(Link, LinkEndData),
    • we need a mechanism to test whether the available tokens match the link end data
    • and if they do, then actually remove them.
    • readTokens() is the same as getTokens() except that:
    • getTokens() removes the tokens on the pin activation, i.e, pinActivation.takeTokens()
    • readTokens() leaves the tokens on the pin activation, i.e., pinActivation.getTokens()
    • @param pin
    • @return

    */

    public fUML.Semantics.Classes.Kernel.ValueList readTokens(

    fUML.Syntax.Actions.BasicActions.InputPin pin) {

    // Precondition: The action execution has fired and the given pin is

    // owned by the action of the action execution.

    // Take any tokens held by the pin activation corresponding to the given

    // input pin and return them.

    // NFR 04/16/2009

    Debug.println("[readTokens] node = " + this.node.name + " (pin: " + pin.name + ")");

    PinActivation pinActivation = this.getPinActivation(pin);

    TokenList tokens = pinActivation.getTokens();

    ValueList values = new ValueList();

    for (int i = 0; i < tokens.size(); i++) {

    Token token = tokens.getValue;

    Value value = ((ObjectToken) token).value;

    if (value != null)

    { values.addValue(value); }

    }

    return values;

    }

    b) With the above operation, LinkActionActivation.endMatchesEndData() can be fixed as follows:

    public boolean endMatchesEndData(fUML.Semantics.Classes.Kernel.Link link,

    fUML.Syntax.Actions.IntermediateActions.LinkEndData endData) {

    // Test whether the appropriate end of the given link matches the given

    // end data.

    boolean matches = false;

    if (endData.value == null)

    { matches = true; }

    else {

    Property end = endData.end;

    FeatureValue linkFeatureValue = link.getFeatureValue(end);

    Value endValue = this.readTokens(endData.value).getValue(0);

    if (endData instanceof LinkEndDestructionData) {

    if (!((LinkEndDestructionData) endData).isDestroyDuplicates

    & !end.multiplicityElement.isUnique & end.multiplicityElement.isOrdered)

    { int destroyAt = ((UnlimitedNaturalValue) (this .readTokens(((LinkEndDestructionData) endData).destroyAt).getValue(0))).value.naturalValue; matches = linkFeatureValue.values.getValue(0).equals(endValue) && linkFeatureValue.position == destroyAt; }

    else

    { matches = linkFeatureValue.values.getValue(0).equals(endValue); }

    } else

    { matches = linkFeatureValue.values.getValue(0).equals(endValue); }

    }

    return matches;

    }

    c) All other actions/activity behaviors which directly or indirectly invoked LinkActionActivation.endMatchesEndData() need to be reviewed to make sure that the tokens will be consumed. There are only 3 cases to consider:

    fUML.Semantics.Actions.IntermediateActions.CreateLinkActionActivation.doAction()

    fUML.Semantics.Actions.IntermediateActions.DestroyLinkActionActivation.doAction()

    fUML.Semantics.Actions.IntermediateActions.ReadLinkActionActivation.doAction()

    CreateLinkActionActivation.doAction() already consumes the tokens when creating the new link instance.

    DestroyLinkActionActivation.doAction() needs extra logic to delete the tokens from the input pins after determining the matching links to destroy, if any. This requires modifying this operation as follows:

    public void doAction() {

    // Get the extent, at the current execution locus, of the association

    // for which links are being destroyed.

    // Destroy all links that match the given link end destruction data.

    // For unique ends, or non-unique ends for which isDestroyDuplicates is

    // true, match links with a matching value for that end.

    // For non-unique, ordered ends for which isDestroyDuplicates is false,

    // match links with an end value at the given destroyAt position. [Must

    // a value be given, too, in this case?]

    // For non-unique, non-ordered ends for which isDestroyDuplicates is

    // false, pick one matching link (if any) non-deterministically. [The

    // semantics of this case is not clear from the current spec.]

    DestroyLinkAction action = (DestroyLinkAction) (this.node);

    LinkEndDestructionDataList destructionDataList = action.endData;

    boolean destroyOnlyOne = false;

    int j = 1;

    while (!destroyOnlyOne & j <= destructionDataList.size())

    { LinkEndDestructionData endData = destructionDataList.getValue(j - 1); destroyOnlyOne = !endData.end.multiplicityElement.isUnique & !endData.end.multiplicityElement.isOrdered & !endData.isDestroyDuplicates; j = j + 1; }

    LinkEndDataList endDataList = new LinkEndDataList();

    for (int i = 0; i < destructionDataList.size(); i++)

    { LinkEndDestructionData endData = destructionDataList.getValue(i); endDataList.addValue(endData); }

    ExtensionalValueList extent = this.getExecutionLocus().getExtent(this.getAssociation());

    ExtensionalValueList matchingLinks = new ExtensionalValueList();

    for (int i = 0; i < extent.size(); i++) {

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;

    if (this.linkMatchesEndData(link, endDataList))

    { matchingLinks.addValue(link); }

    }

    /*

    • NFR 04/16/2009
    • Now that we know which matching links to destroy,
    • we need to ensure all of the tokens on the input pins
    • of this action are consumed.

    */

    for (int i = 0; i < destructionDataList.size(); i++) {

    LinkEndDestructionData endData = destructionDataList.getValue;

    Property end = endData.end;

    if (!endData.isDestroyDuplicates

    & !end.multiplicityElement.isUnique & end.multiplicityElement.isOrdered)

    { this.getTokens(endData.destroyAt); }

    this.getTokens(endData.value);

    }

    if (destroyOnlyOne) {

    // *** If there is more than one matching link,

    // non-deterministically choose one. ***

    if (matchingLinks.size() > 0)

    { int i = ((ChoiceStrategy) this.getExecutionLocus().factory.getStrategy("choice")) .choose(matchingLinks.size()); matchingLinks.getValue(i - 1).destroy(); }

    } else {

    for (int i = 0; i < matchingLinks.size(); i++)

    { ExtensionalValue matchingLink = matchingLinks.getValue(i); matchingLink.destroy(); }

    }

    }

    ReadLinkActionActivation.doAction() needs extra logic to consume the tokens after matching the data against all of the links in the extension.

    public void doAction() {

    // Get the extent, at the current execution locus, of the association to

    // which the action applies.

    // For all links that match the link end data, place the value of the

    // remaining "open" end on the result pin.

    ReadLinkAction action = (ReadLinkAction) (this.node);

    LinkEndDataList endDataList = action.endData;

    LinkEndData openEnd = null;

    int i = 1;

    while ((openEnd == null) & i <= endDataList.size()) {

    if (endDataList.getValue(i-1).value == null)

    { openEnd = endDataList.getValue(i-1); }

    i = i + 1;

    }

    ExtensionalValueList extent = this.getExecutionLocus().getExtent(this.getAssociation());

    for (int j = 0; j < extent.size(); j++) {

    ExtensionalValue value = extent.getValue(j);

    Link link = (Link) value;

    if (this.linkMatchesEndData(link, endDataList))

    { Value resultValue = link.getFeatureValue(openEnd.end).values.getValue(0); this.putToken(action.result, resultValue); }

    }

    /*

    • NFR 04/16/2009
    • Now that we have checked all links for possible matches,
    • we have to consume the tokens on the input pins corresponding to the non-open link ends.

    */

    for (int k=0; k<endDataList.size(); k++) {

    LinkEndData endData = endDataList.getValue(k);

    if (endData.value != null)

    { this.getTokens(endData.value); }

    }

    }

  • Reported: FUML 1.0b1 — Thu, 16 Apr 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Part of the problem is that the name for ActionActivation::getTokens is inconsistent with the names of other operations in the execution model, where “get” is used for operations that do not consume tokens while “take” is used for operations that do. Therefore, it makes sense to change the name of the current “getTokens” operation to “takeTokens” and use the name “getTokens” for the new operation (rather than “readTokens”, as proposed). Also, to be consistent with the resolution to issue 13310, the new operation should call pinActivation.getUnofferedTokens(), rather than pinActivation.getTokens().
    Other than this, the rest of the proposed resolution is accepted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in ReadLinkActionActivation

  • Key: FUML-28
  • Legacy Issue Number: 13869
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, Beta 1 (ptc/2008-11-03)

    Section: 8.6.3.2.9 ReadLinkActionActivation

    In ReadLinkActionActivation::doAction, the code:

    if (endDataList.getValue.value == null)

    { openEnd = endDataList.getValue(i); }

    Should be changed to:

    if (endDataList.getValue(i-1).value == null)

    { openEnd = endDataList.getValue(i-1); }
  • Reported: FUML 1.0b1 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

8.6.4.2.1 [5]AcceptEventActionActivation::accept(in signalInstance:SignalInstance)

  • Key: FUML-27
  • Legacy Issue Number: 13546
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

    Summary:

    The AcceptEventActionActivation::accept() unconditionally places values on output pins even if the action does not have any output pin.

    Proposed resolution:

    Change the operation from:

    // Accept a signal occurance for the given signal instance.

    // If the action does not unmarshall, then place the signal instance on

    // the result pin.

    // If the action does unmarshall, then get the feature values of the

    // signal instance, and place the values for each feature on the

    // corresponding output pin.

    // Concurrently fire all output pins while offering a single control

    // token.

    // If there are no incoming edges, then re-register this accept event

    // action execution with the context object.

    AcceptEventAction action = (AcceptEventAction) (this.node);

    OutputPinList resultPins = action.result;

    Debug.println("[accept] action = " + action.name + ", signalinstance = " + signalInstance);

    if (this.running) {

    if (!action.isUnmarshall)

    { ValueList result = new ValueList(); result.addValue(signalInstance); this.putTokens(resultPins.getValue(0), result); }

    else {

    FeatureValueList featureValues = signalInstance.getFeatureValues();

    for (int i = 0; i < featureValues.size(); i++)

    { FeatureValue featureValue = featureValues.getValue(i); OutputPin resultPin = resultPins.getValue(i); this.putTokens(resultPin, featureValue.values); }

    }

    this.sendOffers();

    this.waiting = false;

    Debug.println("[fire] Checking if " + this.node.name + " should fire again...");

    // if (this.isReady())

    { // this.fire(); // }

    this.receiveOffer();

    }



    }



    To:



    // Accept a signal occurance for the given signal instance.

    // If the action does not unmarshall, then place the signal instance on

    // the result pin, if any.

    // If the action does unmarshall, then get the feature values of the

    // signal instance, and place the values for each feature on the

    // corresponding output pin, if any.

    // Concurrently fire all output pins, if any, while offering a single control

    // token.

    // If there are no incoming edges, then re-register this accept event

    // action execution with the context object.



    AcceptEventAction action = (AcceptEventAction) (this.node);

    OutputPinList resultPins = action.result;



    Debug.println("[accept] action = " + action.name + ", signalinstance = " + signalInstance);



    if (this.running) {

    if (resultPins.size() > 0) {

    if (!action.isUnmarshall) { ValueList result = new ValueList(); result.addValue(signalInstance); this.putTokens(resultPins.getValue(0), result); } else {

    FeatureValueList featureValues = signalInstance.getFeatureValues();

    for (int i = 0; i < featureValues.size(); i++) { FeatureValue featureValue = featureValues.getValue(i); OutputPin resultPin = resultPins.getValue(i); this.putTokens(resultPin, featureValue.values); }

    }

    }

    this.sendOffers();



    this.waiting = false;



    Debug.println("[fire] Checking if " + this.node.name + " should fire again...");

    // if (this.isReady()) { // this.fire(); // }

    this.receiveOffer();

    }

    }

  • Reported: FUML 1.0b1 — Wed, 25 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    If isUnmarshall is true, then the action is required to have output pins corresponding to any signal attributes, and the specification is already correct in this case. It is only in the case that isUnmarshall is false that the specification is incorrect in assuming that there must be an output pin.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[FUML] 8.6.3.2.4 CreateLinkActionActivation.doAction()

  • Key: FUML-26
  • Legacy Issue Number: 13544
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

    Section: 8.6.3.2.4 CreateLinkActionActivation

    Summary:

    CreateLinkActionActivation.doAction() creates a Link object and sets its features according to the link end data specified in the CreateLinkAction; however, the link type is not set to the association.

    Proposed resolution:

    Change the end of the CreateLinkActionActivation.doAction() method from:

    ExtensionalValueList extent = this.getExecutionLocus().getExtent(this.getAssociation());

    for (int i = 0; i < extent.size(); i++) {

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;

    boolean noMatch = true;

    int j = 1;

    while (noMatch & j <= endDataList.size()) {

    LinkEndCreationData endData = endDataList.getValue(j - 1);

    if (endData.isReplaceAll & this.endMatchesEndData(link, endData))

    { link.destroy(); noMatch = false; }

    j = j + 1;

    }

    }



    Link newLink = new Link();



    for (int i = 0; i < endDataList.size(); i++) {

    LinkEndCreationData endData = endDataList.getValue;



    int insertAt = 0;

    if (endData.insertAt != null) { insertAt = ((UnlimitedNaturalValue) (this.getTokens(endData.insertAt).getValue(0))).value.naturalValue; }

    newLink.setFeatureValue(endData.end, this.getTokens(endData.value), insertAt);

    }



    this.getExecutionLocus().add(newLink);



    To:



    Association linkAssociation = this.getAssociation();

    ExtensionalValueList extent = this.getExecutionLocus().getExtent(linkAssociation);



    for (int i = 0; i < extent.size(); i++) {

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;



    boolean noMatch = true;

    int j = 1;

    while (noMatch & j <= endDataList.size()) {

    LinkEndCreationData endData = endDataList.getValue(j - 1);

    if (endData.isReplaceAll & this.endMatchesEndData(link, endData)) { link.destroy(); noMatch = false; }

    j = j + 1;

    }

    }

    Link newLink = new Link();

    for (int i = 0; i < endDataList.size(); i++) {

    LinkEndCreationData endData = endDataList.getValue;

    int insertAt = 0;

    if (endData.insertAt != null)

    { insertAt = ((UnlimitedNaturalValue) (this.getTokens(endData.insertAt).getValue(0))).value.naturalValue; }

    newLink.setFeatureValue(endData.end, this.getTokens(endData.value), insertAt);

    }

    newLink.type = linkAssociation;

    this.getExecutionLocus().add(newLink);

  • Reported: FUML 1.0b1 — Sun, 22 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as (essentially) as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.5.2.2.9 SendSignalAction

  • Key: FUML-25
  • Legacy Issue Number: 13511
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

    Section: 7.5.2.2.9 SendSignalAction

    Summary:

    The description of the constraint states:

    The target input pin must have a type that has a reception for the signal

    The OCL constraint is invalid:

    self.target.activity.allFeatures()>select(oclIsKindOf(Reception))>collect(oclAsType(Reception).signal)-

    >includes(self.signal)

    Proposed resolution:

    Change:

    self.target.activity.allFeatures()>select(oclIsKindOf(Reception))>collect(oclAsType(Reception).signal)-

    >includes(self.signal)

    To:

    self.target.type.oclAsType(Classifier).allFeatures()->select(oclIsKindOf(Reception))

    ->exists(f:Feature|self.signal.conformsTo(f.oclAsType(Reception).signal))

  • Reported: FUML 1.0b1 — Wed, 18 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the constraint as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Subclause: 8.5.2.2.6 ActivityParameterNodeActivation

  • Key: FUML-30
  • Legacy Issue Number: 13881
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    When an activity execution is terminated (e.g., by an activity final node), tokens are cleared from all object nodes (see the ObjectNode::terminate operation). However, this means that output activity parameter nodes (which are object nodes) get their tokens cleared. As a result, the tokens meant to be placed on the output parameters of the activity are lost.

    The ActivityParameterNodeActivation class should override the terminate operation and, if for an output activity parameter node, not clear the tokens in the node.

  • Reported: FUML 1.0b1 — Sun, 19 Apr 2009 04:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    The ObjectNode::terminate operation uses the clearToken operation to clear the tokens from the node activation. However, ActivityParameterNodeActivation already overrides this operation to only clear tokens if the node is an input parameter node. So no change is needed.
    Revised Text:
    None
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutionFactory::instantiateVisitor should not use Java reflection

  • Key: FUML-11
  • Legacy Issue Number: 13453
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The ExecutionFactory::instantiateVisitor operation currently uses Java reflection to instantiate an appropriate visitor class. However, there is no Annex A mapping for this.

    Proposed Resolution:

    Remove the “suffix” parameter from the signature for instantiateVisitor and update the calls in ExecutionFactory::createExecution, ExecutionFactory::createEvaluation and ActivityNodeActivationGroup::createNodeActivation to remove the corresponding second argument. Replace the body of instantiateVistor with:

    // Instantiate a visitor object for the given element.

    SemanticVisitor visitor = null;

    if (element instanceof fUML.Syntax.Classes.Kernel.LiteralBoolean)

    { visitor = new fUML.Semantics.Classes.Kernel.LiteralBooleanEvaluation(); }

    if (element instanceof fUML.Syntax.Classes.Kernel.LiteralString)

    { visitor = new fUML.Semantics.Classes.Kernel.LiteralStringEvaluation(); }

    if (element instanceof fUML.Syntax.Classes.Kernel.LiteralNull)

    { visitor = new fUML.Semantics.Classes.Kernel.LiteralNullEvaluation(); }

    if (element instanceof fUML.Syntax.Classes.Kernel.InstanceValue)

    { visitor = new fUML.Semantics.Classes.Kernel.InstanceValueEvaluation(); }

    if (element instanceof fUML.Syntax.Classes.Kernel.LiteralUnlimitedNatural)

    { visitor = new fUML.Semantics.Classes.Kernel.LiteralUnlimitedNaturalEvaluation(); }

    if (element instanceof fUML.Syntax.Classes.Kernel.LiteralInteger)

    { visitor = new fUML.Semantics.Classes.Kernel.LiteralIntegerEvaluation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.Activity)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.ActivityExecution(); }

    if (element instanceof fUML.Syntax.Actions.BasicActions.OutputPin)

    { visitor = new fUML.Semantics.Actions.BasicActions.OutputPinActivation(); }

    if (element instanceof fUML.Syntax.Actions.BasicActions.InputPin)

    { visitor = new fUML.Semantics.Actions.BasicActions.InputPinActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.StartClassifierBehaviorAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.StartClassifierBehaviorActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ReadStructuralFeatureAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ReadStructuralFeatureActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.CompleteStructuredActivities.ConditionalNode)

    { visitor = new fUML.Semantics.Activities.CompleteStructuredActivities.ConditionalNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ReadSelfAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ReadSelfActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.DestroyLinkAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.DestroyLinkActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.CompleteStructuredActivities.StructuredActivityNode)

    { visitor = new fUML.Semantics.Activities.CompleteStructuredActivities.StructuredActivityNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.BasicActions.SendSignalAction)

    { visitor = new fUML.Semantics.Actions.BasicActions.SendSignalActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.ExtraStructuredActivities.ExpansionNode)

    { visitor = new fUML.Semantics.Activities.ExtraStructuredActivities.ExpansionNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.CreateObjectAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.CreateObjectActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ReadLinkAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ReadLinkActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ClearAssociationAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ClearAssociationActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.JoinNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.JoinNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.ReclassifyObjectAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.ReclassifyObjectActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.InitialNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.InitialNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.StartObjectBehaviorAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.StartObjectBehaviorActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.ReadIsClassifiedObjectAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.ReadIsClassifiedObjectActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.BasicActions.CallOperationAction)

    { visitor = new fUML.Semantics.Actions.BasicActions.CallOperationActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.BasicActions.CallBehaviorAction)

    { visitor = new fUML.Semantics.Actions.BasicActions.CallBehaviorActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.ExtraStructuredActivities.ExpansionRegion)

    { visitor = new fUML.Semantics.Activities.ExtraStructuredActivities.ExpansionRegionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.AddStructuralFeatureValueAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.AddStructuralFeatureValueActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.ActivityParameterNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.ActivityParameterNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ValueSpecificationAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ValueSpecificationActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.ActivityFinalNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.ActivityFinalNodeActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.ForkNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.ForkNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.AcceptEventAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.AcceptEventActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.CompleteStructuredActivities.LoopNode)

    { visitor = new fUML.Semantics.Activities.CompleteStructuredActivities.LoopNodeActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.DecisionNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.DecisionNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.ReduceAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.ReduceActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.DestroyObjectAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.DestroyObjectActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.ClearStructuralFeatureAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.ClearStructuralFeatureActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.TestIdentityAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.TestIdentityActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.CreateLinkAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.CreateLinkActionActivation(); }

    if (element instanceof fUML.Syntax.Actions.IntermediateActions.RemoveStructuralFeatureValueAction)

    { visitor = new fUML.Semantics.Actions.IntermediateActions.RemoveStructuralFeatureValueActionActivation(); }

    if (element instanceof fUML.Syntax.Activities.IntermediateActivities.MergeNode)

    { visitor = new fUML.Semantics.Activities.IntermediateActivities.MergeNodeActivation(); }

    if (element instanceof fUML.Syntax.Actions.CompleteActions.ReadExtentAction)

    { visitor = new fUML.Semantics.Actions.CompleteActions.ReadExtentActionActivation(); }

    return visitor;

  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    The proposed resolution will only work at conformance level 3 (L3). That is because it references classes that are not available at lower conformance levels.
    Accommodating all three conformance levels requires having a different instantiateVistor implementation for each level. This can be achieved by making ExecutionFactory abstract and added three concrete subclasses, one for each conformance level, each of which appropriately overrides instantiateVisitor. Then an execution environment can be set up for the appropriate conformance level by using an instance of the correct ExecutionFactory subclass for that level.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LoopNodeActivation::doStructuredActivity uses a Java array

  • Key: FUML-22
  • Legacy Issue Number: 13464
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The operation LoopNodeActivation::doStructuredActivity uses a Java array, which has no mapping in Annex A.

    Proposed Resolution:

    Add a class Values to the package Semantics::Activities::CompleteStructuredActivities that has a property values: Semantics::Classes::Kernel::Value[*]. Then add a property bodyValueLists: Values[*] to LoopNodeActivation, which can be used in place of the local array variable.

    In the body of doStructuredActivity, within the statement “if (continuing)

    { … }

    ”, replace the code with:

    this.activationGroup.terminateAll();

    this.bodyOutputLists.clear();

    OutputPinList bodyOutputs = loopNode.bodyOutput;

    for (int i = 0; i < bodyOutputs.size(); i++)

    { OutputPin bodyOutput = bodyOutputs.getValue(i); Values bodyOutputList = new Values(); bodyOutputList.values = this.getPinValues(bodyOutput); this.bodyOutputLists.addValue(bodyOutputList); }

    this.runLoopVariables();

    for (int i = 0; i < loopVariables.size(); i++)

    { OutputPin loopVariable = loopVariables.getValue(i); Values bodyOutputList = this.bodyOutputLists.getValue(i); ValueList values = bodyOutputList.values; this.putPinValues(loopVariable, values); }
  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ActionActivation::isSourceFor does not initialize a local variable

  • Key: FUML-21
  • Legacy Issue Number: 13463
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The operation ActionActivation::isSourceFor does not initialize the local variable isSource, as required by the conventions of Annex A.

    Proposed Resolution:

    Replace the body of isSourceFor with:

    // If this action has an outgoing fork node, check that the fork node is the source of the given edge instance.

    boolean isSource = false;

    if (this.outgoingEdges.size() > 0)

    { isSource = this.outgoingEdges.getValue(0).target.isSourceFor(edgeInstance); }

    return isSource;

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Link::getTypes does not initialize a local variable

  • Key: FUML-19
  • Legacy Issue Number: 13461
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The operation Link::getTypes does not initialize the local variable types, as required by the conventions of Annex A.

    Proposed Resolution:

    In the declaration for typest, add the initialization code “= null”.

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IntegerValue::toString uses Java String.valueOf

  • Key: FUML-18
  • Legacy Issue Number: 13460
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The IntegerValue::toString operation uses the Java String.valueOf operation, which has no Annex A mapping.

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "";

    if (this.value == 0)

    { stringValue = "0"; }

    else {

    int positiveValue = this.value;

    if (positiveValue < 0)

    { positiveValue = -positiveValue; }

    do {

    int digit = positiveValue % 10;

    if (digit == 0)

    { stringValue = "0" + stringValue; }

    else if (digit == 1)

    { stringValue = "1" + stringValue; }

    else if (digit == 2)

    { stringValue = "2" + stringValue; }

    else if (digit == 3)

    { stringValue = "3" + stringValue; }

    else if (digit == 4)

    { stringValue = "4" + stringValue; }

    else if (digit == 5)

    { stringValue = "5" + stringValue; }

    else if (digit == 6)

    { stringValue = "6" + stringValue; }

    else if (digit == 7)

    { stringValue = "7" + stringValue; }

    else if (digit == 8)

    { stringValue = "8" + stringValue; }

    else if (digit == 9)

    { stringValue = "9" + stringValue; }

    positiveValue = positiveValue / 10;

    } while (positiveValue > 0);

    if (this.value < 0)

    { stringValue = "-" + stringValue; }

    }

    return stringValue;

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[FUML] 7.4.2.2.14 ObjectFlow

  • Key: FUML-24
  • Legacy Issue Number: 13509
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

    Section: 7.4.2.2.14 (ObjectFlow)

    Summary:

    As shown in Fig. 12.14 of the UML 2.2 Beta1 specification, an ObjectFlow can have two optional behaviors,

    a transformation and a selection. No such behaviors are supported in the fUML subset.

    Proposed resolution:

    Add a second OCL constraint on ObjectFlow:

    [2] ObjectFlow::no_transformation_or_selection_behavior()

    – An ObjectFlow cannot have a transformation or a selection behavior in the fUML subset.

    self.transformation->isEmpty() and self.selection->isEmpty()

  • Reported: FUML 1.0b1 — Wed, 18 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    The transformation and selection properties of ObjectFlow are only introduced at the level of CompleteActivities. And, per Subclause 7.4.1 of the fUML spec, “The UML 2 Superstructure package CompleteActivities is excluded in its entirety from fUML”. Since transformation and selection are association ends, their associations simply do not appear in the fUML subset, so no constraints are necessary.

    Of course, the isMulticase and isMultireceive attributes on ObjectFlow are also only in CompleteActivities, but they still appear in the fUML subset (with constraints). However, these and other similar attributes should actually be removed from the fUML subset abstract syntax (see Issue 14561).

    Revised Text:
    None.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Event should be a specialization of PackageableElement

  • Key: FUML-23
  • Legacy Issue Number: 13504
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    Event should have PackageableElement as a generalization (as it does in the full UML2 specification). Otherwise, it is not possible to contain an event anywhere within a model.

  • Reported: FUML 1.0b1 — Mon, 16 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Event should, indeed, have PackageableElement as a generalization

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CompoundValue::equals does not conform to Annex A conventions

  • Key: FUML-14
  • Legacy Issue Number: 13456
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The CompoundValue::equals operation has more than one return statement and uses the “&&”. These are not allowed by the conventions of Annex A.

    Proposed Resolution:

    Replace the body of the equals operation with:

    boolean isEqual = otherValue instanceof CompoundValue;

    if (isEqual) {

    CompoundValue otherCompoundValue = (CompoundValue)otherValue;

    // Debug.println("[equals] " + this.featureValues.size() + " feature(s).");

    isEqual = super.equals(otherValue) & otherCompoundValue.featureValues.size() == this.featureValues.size();

    int i = 1;

    while (isEqual & i <= this.featureValues.size()) {

    FeatureValue thisFeatureValue = this.featureValues.getValue(i-1);

    boolean matched = false;

    int j = 1;

    while (!matched & j <= otherCompoundValue.featureValues.size()) {

    FeatureValue otherFeatureValue = otherCompoundValue.featureValues.getValue(j-1);

    if (thisFeatureValue.feature == otherFeatureValue.feature)

    { matched = thisFeatureValue.hasEqualValues(otherFeatureValue); }

    j = j + 1;

    }

    isEqual = matched;

    i = i + 1;

    }

    }

    return isEqual;

  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BooleanValue::toString uses Java String.valueOf

  • Key: FUML-13
  • Legacy Issue Number: 13455
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The BooleanValue::toString operation uses the Java String.valueOf operation, which has no Annex A mapping.

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "false";

    if (this.value)

    { stringValue = "true"; }

    return stringValue;

  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutionFactory::getStrategy doesn't follow conventions

  • Key: FUML-12
  • Legacy Issue Number: 13454
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The ExecutionFactory::getStrategy operation does not initialize the strategy variable, as required by Annex A.3.3.

    Proposed Resolution:

    Replace the body of getStrategy with:

    // Get the strategy with the given name.

    int i = this.getStrategyIndex(name);

    SemanticStrategy strategy = null;

    if (i <= this.strategies.size())

    { strategy = this.strategies.getValue(i-1); }

    return strategy;

  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FeatureValue::hasEqualValues does not follow Annex A conventions

  • Key: FUML-16
  • Legacy Issue Number: 13458
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The operation FeatureValue::hasEqualValues uses the remove operation on a local list variable. This is not allowed by the conventions of Annex A.

    Proposed Resolution:

    Rather than introducing a special class as a “ValueList holder”, a local instance of FeatureValue can be used for this purpose.

    Replace:

    ValueList otherValues = new ValueList();

    with:

    FeatureValue otherFeatureValues = new FeatureValue();

    In subsequent code, replace all references to “otherValues” with “otherFeatureValues.values”.

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EnumerationValue::specify missing a "this"

  • Key: FUML-15
  • Legacy Issue Number: 13457
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The EnumerationValue::specify operation includes a reference to the “literal” field without prefacing it with “this”. This is not allowed by the conventions of Annex A.

    Proposed Resolution:

    Replace the reference to “literal” with “this.literal”.

  • Reported: FUML 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UnlimitedNaturalValue::toString does not follow Annex A conventions

  • Key: FUML-20
  • Legacy Issue Number: 13462
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The UnlimitedNaturalValue::toString operation has multiple return statements and uses the Java String.valueOf operation, which do not follow Annex A conventions.

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "*";

    if (this.value.naturalValue >= 0)

    { IntegerValue integerValue = new IntegerValue(); integerValue.value = this.value.naturalValue; stringValue = integerValue.toString(); }

    return stringValue;

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceValueEvaluation::evaluate does not initialize local variables

  • Key: FUML-17
  • Legacy Issue Number: 13459
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Summary:

    The operation InstanceValueEvaluation::evaluate does not initialize the local variables structuredValue and object, as required by the conventions of Annex A.

    Proposed Resolution:

    In the declarations for structuredValue and object, add the initialization code “= null”.

  • Reported: FUML 1.0b1 — Sat, 7 Feb 2009 05:00 GMT
  • Disposition: Resolved — FUML 1.0b2
  • Disposition Summary:

    Change the code as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT