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

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

  • Acronym: FUML
  • Issues Count: 15
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Annex on normative XMI for fUML

  • Key: FUML15-1
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

    The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.

  • Reported: FUML 1.0b2 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Closed; No Change — FUML 1.5
  • Disposition Summary:

    Annex is no longer necessary

    At the time this issue was submitted, the fUML abstract syntax metamodel was technically distinct from the UML abstract syntax. However, the intent was that fUML models would still be serialized using UML XMI. So some further explanation would have been useful.

    However, as of fUML 1.4, the fUML abstract syntax is now formally a true subset of the UML 2.5.1 abstract syntax. So there is no question that a conforming fUML 1.4 model can be serialized using corresponding UML 2.5.1 XMI – since an fUML 1.4 model is a UML 2.5.1 model. So no further explanation is really necessary now.

  • Updated: Fri, 18 Sep 2020 17:03 GMT

Annex on normative XMI for fUML

  • Key: FUML14-1
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

    The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.

  • Reported: FUML 1.0b2 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Deferred — FUML 1.4
  • Disposition Summary:

    Defer

    Resolution of this issue is deferred, because the focus of the fUML 1.4 RTF is on migrating fUML to UML 2.5.1.

  • Updated: Fri, 5 Oct 2018 19:13 GMT

Annex on normative XMI for fUML

  • Key: FUML13-2
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

    The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.

  • Reported: FUML 1.0b2 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

    The RTF agrees this issue needs resolution but, due to lack of time, is deferring its resolution to the next RTF.

  • Updated: Thu, 22 Jun 2017 16:38 GMT

Annex on normative XMI for fUML

  • Key: FUML12-3
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 2 (ptc/09-10-05)

    The specification should have an annex describing the normative serialization of the fUML syntax, semantics and foundational library models, similar to Annexes G and H of the UML 2.3 superstructure specification.

  • Reported: FUML 1.0b2 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

    The RTF agrees this issue needs resolution but, due to lack of time, is deferring its resolution to the next RTF.

  • Updated: Tue, 22 Dec 2015 15:09 GMT

Corrections to previous resolutions

  • Key: FUML_-8
  • Legacy Issue Number: 15127
  • Status: closed  
  • Source: Model Driven Solutions ( 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

Error in ObjectActivation::dispatchNextEvent

  • Key: FUML_-6
  • Legacy Issue Number: 15090
  • Status: closed  
  • Source: Model Driven Solutions ( 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

Additional changes required for action firing semantics

  • Key: FUML_-7
  • Legacy Issue Number: 15094
  • Status: closed  
  • Source: Model Driven Solutions ( 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

Modification to AcceptEventActionActivation

  • Key: FUML_-5
  • Legacy Issue Number: 15089
  • Status: closed  
  • Source: Model Driven Solutions ( 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

Values passed out to pins from empty parameter nodes

  • Key: FUML_-1
  • Legacy Issue Number: 14990
  • Status: closed  
  • Source: NIST ( 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

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

Additional changes required for structured activity node execution

  • Key: FUML_-4
  • Legacy Issue Number: 15088
  • Status: closed  
  • Source: Model Driven Solutions ( 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 ( 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

TestIdentityAction for datatypes

  • Key: UML25-674
  • Legacy Issue Number: 14989
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In UML, TestIdentityAction does not currently apply to datatypes. The
    introduction and description of TestIdentityAction say
    "TestIdentifyAction is an action that tests if two values are identical
    objects. This action returns true if the two input values are the same
    identity, false if they are not." Data type values are not objects and
    do not have identity (that is, you cannot tell one data type value from
    another).

    If it is decided that the execution engine should not reflect the above
    semantics, the semantics of TestIdentityAction needs to be extended for
    unstructured datatype values to test whether the values are the same.
    For structured values, such as strings, the values and their contents
    would need to be the same, recursively if they contain more datatype
    values.

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

    This issue is obsolete. The specification of the semantics of TestIdentityAction in the UML 2.5 beta specification, in
    Subclause 16.4.3, under “Test Identity Actions”, covers the testing of instances of data types.
    Disposition: Closed - No Change

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

Expansion nodes using all the tokens in them as a single collection

  • Key: UML24-33
  • Legacy Issue Number: 14991
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    UML expansion regions currently treat each input as a collection, rather
    than all the inputs as members of a single collection, as the execution
    engine currently assumes. The description of Expansion Region says
    "Each input is a collection of values. If there are multiple inputs,
    each of them must hold the same kind of collection, although the types
    of the elements in the different collections may vary. The expansion
    region is executed once for each element (or position) in the input
    collection."

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on ExpansionRegion to
    indicate whether the individual tokens of the input and out expansion
    nodes are taken as collections, or whether all the tokens in the nodes
    are taken as one collection. 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 — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of ExpansionRegions in the UML 2.5 beta specification, in
    Subclause 16.12.3, covers this.
    Disposition: Closed - No Change

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

An action may not stop firing again

  • Key: FUML11-3
  • Legacy Issue Number: 15130
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

  • Reported: FUML 1.0b2 — Sun, 21 Mar 2010 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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