${taskforce.name} Avatar
  1. OMG Task Force

2nd Semantics of a Foundational Subset of Executable UML Models FTF — Closed Issues

  • Key: FUML_
  • Issues Count: 8
Open Closed All
Issues resolved by a task force and approved by Board

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