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

fUML 1.2 RTF — All Issues

  • Key: FUML12
  • Issues Count: 38
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
FUML12-8 LoopNodeActivation does not correctly handle the firing of a contained activity final node FUML 1.0 FUML 1.2 Resolved closed
FUML12-35 Initial execution of an activity is not run-to-completion FUML 1.1 FUML 1.2 Resolved closed
FUML12-33 Extensional values should have an unique identifier FUML 1.1 FUML 1.2 Resolved closed
FUML12-20 Feature values need to be created for private structural features of parent classifiers FUML 1.1 FUML 1.2 Resolved closed
FUML12-23 RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value FUML 1.1 FUML 1.2 Resolved closed
FUML12-10 Certain Boolean flags are not properly initialized in some cases FUML 1.0 FUML 1.2 Resolved closed
FUML12-60 The OCL for CallBehaviorAction::proper_context has an error FUML 1.1 FUML 1.2 Resolved closed
FUML12-36 Problem with CallActionActivation: possible infinite loop in removeCallExecution() FUML 1.1 FUML 1.2 Resolved closed
FUML12-2 7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance FUML 1.0b1 FUML 1.2 Closed; Out Of Scope closed
FUML12-34 AcceptEventActionActivation::match should match instances of descendants of a trigger's signal FUML 1.1 FUML 1.2 Resolved closed
FUML12-21 ReclassifyObjectAction handles removal of structural features incorrect FUML 1.0 FUML 1.2 Resolved closed
FUML12-19 The types of the ReadLine::errorStatus and WriteLine::errorStatus parameters should be Status FUML 1.1 FUML 1.2 Resolved closed
FUML12-24 RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly FUML 1.1 FUML 1.2 Resolved closed
FUML12-32 ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06) FUML 1.1 FUML 1.2 Closed; No Change closed
FUML12-31 Correction of method UnlimitedNaturalValue.equals FUML 1.1 FUML 1.2 Resolved closed
FUML12-15 ListFunctions should have a ListConcat behavior FUML 1.1 FUML 1.2 Resolved closed
FUML12-14 FoundationModelLibrary, UnlimitedNaturalFunctions: inconsistencies between the spec and the normative xmi FUML 1.1 FUML 1.2 Resolved closed
FUML12-18 The Listener reception of Notification should have a name FUML 1.1 FUML 1.2 Resolved closed
FUML12-17 FoundationalModelLibrary::Common::Notification should be public FUML 1.1 FUML 1.2 Resolved closed
FUML12-16 The ReadLine::result parameter should have direction "return" FUML 1.1 FUML 1.2 Resolved closed
FUML12-57 List parameters of ListFunctions should be non-unique. FUML 1.1 FUML 1.2 Resolved closed
FUML12-5 The fUML subset should include central buffer nodes and data stores FUML 1.0 FUML 1.2 Deferred closed
FUML12-4 fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2 FUML 1.0 FUML 1.2 Deferred closed
FUML12-3 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.2 Deferred closed
FUML12-1 Section: Base Semantics FUML 1.0b1 FUML 1.2 Deferred closed
FUML12-7 ReclassifyObjectAction does not preserve structural feature values FUML 1.0 FUML 1.2 Resolved closed
FUML12-22 RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop FUML 1.1 FUML 1.2 Resolved closed
FUML12-9 The bodyOutputLists for a loop node need to be cleared when the node fires again FUML 1.0 FUML 1.2 Resolved closed
FUML12-13 Objects with cyclic references cannot be converted to string representations FUML 1.1 FUML 1.2 Resolved closed
FUML12-26 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.2 Deferred closed
FUML12-25 Defects in Base Semantics from fUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-12 RealValue::toString puts too many digits in the mantissa FUML 1.1 FUML 1.2 Resolved closed
FUML12-11 Problem with ActivityExecution::terminate FUML 1.1 FUML 1.2 Resolved closed
FUML12-6 The fUML subset shuold support the raising and handling of exceptions FUML 1.0 FUML 1.2 Deferred closed
FUML12-30 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.2 Deferred closed
FUML12-29 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-28 Actions outside the bUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-27 Base Semantics PSL version FUML 1.1 FUML 1.2 Deferred closed

Issues Descriptions

LoopNodeActivation does not correctly handle the firing of a contained activity final node

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 RTF Beta (ptc/2012-10-18)

    Subclause: 8.5.3.2.3 LoopNodeActivation

    When an ActivityFinalNode fires within a StructuredActivityNode (other than an ExpansionRegion), the ActivityFinalNodeActivation terminates the containing node activation by calling the terminateAll operation. This operation is specified in StructuredActivityNodeActivation to terminate all activations in the activation group for the structured node activation. As a result, none of these activations can fire any more, and the structured node activation as a whole eventually completes its firing. Note that the structured node itself does not terminate, since it can still fire again.

    For a LoopNodeActivation, the call to TerminateAll will happen within a loop iteration. Terminating all activations in the loop node activation group will result in the body of the loop completing, resulting in the runBody operation to return from its call within the LoopNodeActivation::fire operation. The fire operation then checks whether the loop should continue. However, this only includes checking whether the loop node as a whole has terminated or been suspended. Neither of these will be the case if the firing of the loop was terminated due to an activity final node. As a result, the loop may be determined to continue, even though it should not.

    What is necessary is to set a flag when LoopNodeActivation::terminateAll is called and to check this flag in the same conditionals in the fire that check isRunning and isSuspended. This flag also needs to be checked in the LoopNodeActivation::resume operation to prevent the loop from continuing on resumption if the firing has been terminated by an activity final node.

    (Note also that there are two conditionals at the end of the fire operation as currently specified that use the “&&” operator, which is not allowed by the bUML subset as specified in Annex A.)

  • Reported: FUML 1.0 — Fri, 23 Nov 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update LoopNodeActivation

    Agreed.

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

Initial execution of an activity is not run-to-completion

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

    When an activity accepts an event, its execution proceeds as a “run-to-completion step”, and any new event occurrences (signal instances) are saved in the event pool and not dispatched until after the completion of the step. However, when an activity first starts executing (asynchronously), it is NOT in a run-to-completion step before it waits for the first time at an accept event action. This means that, during this time, any event occurrences that arrive could potentially be dispatched immediately and lost. Further, even if the first action to be executed in an activity is an accept event action, the specification would allow an execution trace in which all event occurrences happened before the action fired for the first time, meaning that, currently, it can never be ensured that an activity will be able to accept any event occurrences at all.

    Recommended solution:

    Rather than having the ClassifierBehaviorExecutionActivity start asynchronously from the EventDispatchLoop of the object activation for the context object, the EventDispatchLoop should make a synchronous call to execute the initial classifier behavior execution, and then only start looping once the initial execution completes. Note that the equivalent behavior should also be specified for bUML, so that the ArrivalSignal instances sent to an object activation are properly queued while the EventDispatchLoop is waiting for the initial classifier behavior execution to complete.

  • Reported: FUML 1.1 — Fri, 12 Dec 2014 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Invoke classifier behaviors from the event dispatch loop

    The UML 2.5 specification calls the initial event that starts the execution of a behavior the "event of its invocation". Essentially, what is required to resolve this issue is for such an invocation event occurrence to be handled as a run-to-completion step in the behavior execution, just as signal event occurrences are currently handled. A particularly direct way to do this would be to explicitly model invocation event occurrences, place them in the event pool for the context object of the behavior being (asynchronously) invoked and then having them dispatched and accepted using the current event loop and run-to-completion mechanisms.

    Doing this would also manage the case of a context object with multiple classifier behavior executions that don't all start at the same time. This can happen if the object has multiple types with classifier behaviors. If the object is the target value for a start object behavior action whose object input pin is explicitly typed by one of the relevant classes, than only the classifier behavior associated with that class is started, even if the object has other types with classifier behaviors (in contrast, if the object pin is untyped, then classifier behaviors are started for all the object's types that have them; see the definition of the ObjectActivation::startBehavior operation in 8.4.3.2.5 of the fUML 1.1 specification).

    This means that, when a classifier behavior execution is started, this may happen after other classifier behavior executions have already started and are already handling incoming (signal) event occurrences. Thus, the new invocation could happen when there are already event occurrences in the event pool waiting to happen and even possibly when there is already an ongoing run-to-completion step happening for a previously dispatched event occurrence. By explicitly modeling the invocation event occurrence for the new classifier behavior, the invocation can be managed in the same way as other event occurrences, by being placed in the event pool and eventually dispatched and handled in a run-to-completion step for the initial execution of the classifier behavior.

    Finally, this approach provides an opportunity to generalize the model of the event pool to contain event occurrences other than signal instances. This will likely be eventually necessary anyway, in order to allow future specifications to incorporate the handling of other kinds of events into the fUML Common Behaviors framework (such as call events for state machines).

    So, the proposal to resolve this issue is as follows:

    1. Create a new abstract EventOccurrence class, with a concrete SignalEventOccurrence subclass that has a reference to a SignalInstance.
    2. Generalize the eventPool to contain EventOccurrences instead of just SignalInstances.
    3. Create a new InvocationEventOccurrence subclass of EventOccurrence with a reference to an Execution being invoked.
    4. Change the ObjectActivation::startObjectBehavior operation to create an InvocationEventOccurrence and place it into the eventPool, rather than directly initiating the asynchronous execution of a behavior.
    5. Change the ClassifierBehaviorExecution class to ClassifierBehaviorInvocationEventAccepter, an EventAccepter that registers itself to match the InvocationEventOccurrence for a specific behavior Execution and, when it accepts a matching InvocationEventOccurrence, runs that Execution as a run-to-completion step.
  • Updated: Tue, 22 Dec 2015 15:09 GMT
  • Attachments:

Extensional values should have an unique identifier

  • Key: FUML12-33
  • Legacy Issue Number: 19008
  • Status: closed  
  • Source: PhD Student ( Alessandro Gerlinger Romero)
  • Summary:

    Locus has a "set" for all extensional values, however, there is no unique identifier in the ExtensionalValue to support the uniqueness.

    It should be defined an attribute objectId as "isID" (from UML 2.4.1, isID, indicates this property can be used to uniquely identify an instance of the containing class.) in the class ExtensionalValue.

    The only mention to an object identifier is a reference marked as non-normative, which uses Java to define an object identifier.

    8.2.2.2.6 Locus pg. 103
    extensionalValues : ExtensionalValue [0..*]
    The set of values that are members of classifier extents at this locus.

    8.3.2.2.27 Value pg. 159
    [6] objectId ( ) : String
    // Return an identifier for this object.
    // [Non-normative.]

    return super.toString();

  • Reported: FUML 1.1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Normatively define IDs for extensional values

    In general, it is not necessary in UML to model an explicit ID attribute in order to enforce uniqueness of a property with multiple values. Objects (instances of classes) are automatically distinguishable and unique under UML semantics. Identifying a property typed by a class as isUnique (the default) then means directly that no instance of that class (note that ExtensionalValue is a class in the Execution Model) can appear more than once in the set of values for the property.

    Nevertheless, the issue does make a reasonable point that a Value::objectId operation is provided, but that its specification is non-normative. However, this operation is, in fact, used normatively in CompoundValue::toString.

    Indeed, while it is unclear how to assign unique IDs to all values within the context of the Execution Model, it is certainly reasonable to assign IDs to the extensional values at a locus, as the issue requests. This ID could be assigned when the extensional value is added to the extent at a certain locus. To make the ID unique across multiple loci then requires that each locus also have an ID that can be used to further qualify the IDs of extensional values at that locus. Such an ID could be assigned when the locus is created, as part of the initialization of the execution environment.

    Finally, note that the isID meta-attribute is not given any semantics in bUML, so it is not used in the Execution Model.

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

Feature values need to be created for private structural features of parent classifiers

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 8.3.2.2.25 StructuredValue

    The StructuredValue::createFeatureValues operation is described to “Create empty feature values for all structural features, direct and inherited, of the types of this structured value.” It does this by iterating through the members of all types of the given structured value, which includes inherited members. Unfortunately, structural values that are private members of parent classifiers are not inherited, but they also need to have feature values created in the structured value.

  • Reported: FUML 1.1 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update StructuredValue

    Agreed.

    However, in an AcceptEventAction, if isUnmarshall = true, then there are output pins only for the visible members (owned and inherited) of the accepted Signal. Currently, AcceptEventActionActivation places values from all the featureValues of a signal onto the output pins. This needs to be changed to only place the values of visible features onto the output pins.

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

RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value

  • Key: FUML12-23
  • Legacy Issue Number: 18721
  • Status: closed  
  • Source: LieberLieber Software ( Mrs. Tanja Mayerhofer)
  • Summary:

    In the case a RemoveStructuralFeatureValueAction is used to remove a link, the provided input value is not taken into account but only the object owning the defined association end. However, the UML standard states: “If the feature is an association end, the semantics are the same as for destroying links, the participants of which are the object owning the structural feature and the value being removed.” Thus, only links between the provided object (object pin) and value (value pin) should be considered.

    The following code could be a resolution to this issue:

    public class RemoveStructuralFeatureValueActionActivation
    extends
    fUML.Semantics.Actions.IntermediateActions.WriteStructuralFeatureActionActivation {

    public void doAction() {
    ...
    if (association != null) {
    LinkList links = this.getMatchingLinks(association, feature, value);

    >>> if(inputValue != null)

    { >>> Property oppositeEnd = this.getOppositeEnd(association, feature); >>> LinkList linksMatchingInputValue = this.getMatchingLinks(association, oppositeEnd, inputValue); >>> links = linksMatchingInputValue; }

    ...
    }
    }

  • Reported: FUML 1.1 — Thu, 16 May 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update RemoveStructuralFeatureValueActionActivation

    The issue is correct about the problem. However, the suggested solution would not work properly. As suggested, in the case that inputValue != null, the set of matching links previously found is replaced by a list of links that have the correct value for the action's structural feature. But these links will no longer necessarily have the action's object value as their opposite end value. What is needed is for matching links to have both the current opposite end value and, if inputValue != null, the correct near end value.

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

Certain Boolean flags are not properly initialized in some cases

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)

    Subclauses: 8.5.2.2.4 ActivityNodeActivation, 8.6.2.2.1 ActionActivation and 8.6.4.2.1 AcceptEventActionActivation

    The Boolean attributes ActivityNodeActivation::running, ActionActivation::firing and AcceptEventActionActivation::waiting are presumed to be initialized when instances of the respective classes are created. However, since fUML (and hence bUML) does not support default values, such initialization needs to be done explicitly. Unfortunately, there are times when this is not happening properly.

    ActivityNodeActivation::running is set to false when an activity node activation is created by ActivityNodeActivationGroup::createNodeActivation. However, there are a couple of cases when activity node activations are created other than by using this operation:

    1. When an action has outgoing edges, an anonymous fork node activation is created for the corresponding action activation, to handle the implicit fork semantics for tokens offered on the outgoing edges. The running attribute of this fork node activation is not initialized when it is created. (The run operation is called on the fork node activation when it's corresponding action activation is run, but until then the running attribute of the fork node action is unitialized.)

    2. Output pin activations are created in ExpansionRegionActivation::doStructuredActivity for the expansion activation groups of an expansion region activation. The ActivityNodeActivation::run operation is immediately called on each of these output pin activations, so that running is initialized to true in this case. Unfortunately, the call to add an output pin activation to the groupOutputs of an expansion activation group (the third set of such pin activations in an expansion activation group) erroneously constructs a new output pin activation, rather than adding the one that has been properly initialized.

    The attributes ActionActivation::firing and AcceptEventActionActivation::waiting are both set to false in the run operation of their respective classes. However, when an action is in the body of a loop node or conditional node clause, it is possible for isReady operation on the action activation to be called before the action activation is actually run. Since the isReady check for an action, in general, checks the firing attribute, and the isReady check for an accept event action checks the waiting attribute, if isReady is called before run, these attributes will not have been properly initialized. In addition, AcceptEventActionActivation::waiting is checked in AcceptEventActionActivation::terminate, and it will not have been initialized if an accept event action activation is terminated without ever having been run.

  • Reported: FUML 1.0 — Mon, 17 Dec 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Add attribute initializations

    Agreed.

    The first two points in the issue can be handled by small updates to ActionActivation and ExpansionRegionActivation. The remaining points, however, require more extensive updates, to ensure that all activations are properly initialized when they are added to an activity node activation group, even before they are run.

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

The OCL for CallBehaviorAction::proper_context has an error

  • Key: FUML12-60
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The current OCL for the proper_context constraint on CallBehaviorAction is

    [3] proper_context
    If the behavior has a context, it must be the same as the context of the enclosing activity or a (direct or indirect) superclass of it.

    self.behavior.context->notEmpty() implies 
      union(self.context.allParents())->includes(self.behavior.context)
    

    However, not source collection is provided for the union operation. I believe that the source should be self.context, so that, if this is non-empty, it is included in the set of possible context classifiers allowed for the called behavior.

  • Reported: FUML 1.1 — Wed, 22 Jul 2015 14:03 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Correct the OCL

    Agreed.

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

Problem with CallActionActivation: possible infinite loop in removeCallExecution()

  • Key: FUML12-36
  • Legacy Issue Number: 19130
  • Status: closed  
  • Source: LieberLieber Software ( Mrs. Tanja Mayerhofer)
  • Summary:

    The loop variable 'i' is never incremented, which might lead to an infinite loop.

  • Reported: FUML 1.1 — Sun, 1 Dec 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update CallActionActivation::removeCallExecution

    Agreed.

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

7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance

  • Key: FUML12-2
  • Legacy Issue Number: 13510
  • 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: 2 (Conformance)

    Since fUML is a subset of the UML, there are two possible kinds of syntactic conformance issues:

    a) Checking whether an M1 model written in a superset of fUML (e.g., the UML) conforms to the fUML subset.

    b) Checking whether an M2 extension of fUML (e.g., SysML, UML) complies with the fUML subset

    Proposed resolution:

    1) Clarify the meaning of the confusing terminology:

    • Syntactic conformance is a criteria for M1 models, i.e., (a) above.
    • Syntactic compliance is a criteria relative to a compliance level of an M2 metamodel, i.e. (b) above or to a package unit defined in an M2 metamodel.

    This proposed resolution is consistent with the current terminology of compliance levels for metamodels including fUML, UML, UML4SysML, etcÂ…

    2) Distinguish in the specification document conformance vs. compliance constraints.

    For example, per 12.3.34 of the UML 2.2, a JoinNode as a required ValueSpecification:

    JointNode::joinSpec : ValueSpecification[1..1] with a default value: “and”

    Clearly, the fUML subset does not support M1 models with a JointNode whose joinSpec is anything except the default “and” value specification. This is an M1 conformance constraint that can be specified in OCL.

    Extensions of fUML such as the UML itself should not have this constraint because it is not a compliance requirement for any extension of fUML such as the UML which specifically allows join specification values other than “and”.

    Compliance constraints should be constraints that fUML and any M2 extension of fUML satisfy.

    Conformance constraints are more restrictive; they specify how to verify that an M1 model written in a given superset of fUML (e.g., UML) is still within the fUML subset.

    7.4.2.2.12 JoinNode

    Add a comformance constraint:

    [1] conformance relative to UML::Activities::CompleteActivities (unmerged) or to UML L3 (merged)

    – The join specification must be “and”

    self.joinSpec.oclIsTypeOf(LiteralString) and self.joinSpec.oclAsType(LiteralString).value = 'and'

  • Reported: FUML 1.0b1 — Wed, 18 Feb 2009 05:00 GMT
  • Disposition: Closed; Out Of Scope — FUML 1.2
  • Disposition Summary:

    Out of scope

    This is an important issue. However. It is more than can be dealt with in the context of the fUML RTF. A general strategy is needed in the context of other standards extending fUML, which are now already emerging (such as PSCS and PSSM). Perhaps this can be done as part of the transition of fUML to UML 2,5, which is also beyond the scope of this issue.

    In addition, the proposed conformance/compliance terminology is probably not consistent with ISO practice.

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

AcceptEventActionActivation::match should match instances of descendants of a trigger's signal

  • Key: FUML12-34
  • Legacy Issue Number: 19528
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (FUML), v1.1 (formal-13-08-06)
    Subclause: 8.6.4.2.1 AcceptEventActionActivation

    The AcceptEventActionActivation::match operation should not require equality of Signals to match a signal instance to the Signal of a trigger of the AcceptEventAction. Rather, it should allow the Signal of the signal instance to be a descendant of the Signal of a trigger SignalEvent.

  • Reported: FUML 1.1 — Fri, 18 Jul 2014 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Change AcceptEventActionActivation::match

    The UML 2.4.1 specification is not explicit on how the receipt of a signal is matched to a signal event. The UML 2.5 specification, however, in 13.3.3, states that "A SignalEvent is a MessageEvent for messages requesting the reception of an instance of a specific Signal." Since an instance of a specialization of a signal is also an instance of the general signal, the statement in the UML 2.5 specification supports the view that the intent is that instances of specialized signals also match a signal event for the general signal.

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

ReclassifyObjectAction handles removal of structural features incorrect

  • Key: FUML12-21
  • Legacy Issue Number: 18693
  • Status: closed  
  • Source: Vienna University of Technology ( Tanja Mayerhofer)
  • Summary:

    The ReclassifyObjectActionActivation class implements as a behavior that the newClassifiers are added to the type list of an object and the oldClassifiers are removed. But for the removed oldClassifiers, not the structural features of the oldClassifiers are removed but structural features which have as type set the oldClassifier (which is implemented in the operation CompoundValue.removeFeatureValues(Classifier)).
    However, all structural features owned by the removed oldClassifier should be removed regardless of the type of the structural feature itself.

  • Reported: FUML 1.0 — Thu, 2 May 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Remove CompoundValue::removeFeatureValue

    Agreed. However, with the resolution to issue FUML12-7, ReclassifyObjectActionActivation no longer uses removeFeatureValue, and the new specification of the action functionality correctly handles the removal of attributes from the old classifiers. Since CompoundValue::removeFeatureValue is not used by anything else, it can be removed.

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

The types of the ReadLine::errorStatus and WriteLine::errorStatus parameters should be Status

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 9.4.2 Pre-defined ReadLine and WriteLine Behaviors

    Figures 9.5 and 9.6 in Subclause 9.4.2 show that the type of the errorStatus parameter of the ReadLine and WriteLine activities should be Status. However, in the normative fUML_Library.xmi, these parameters have no type.

  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Give the parameters type Status

    Agreed that the parameters should have type Status.

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

RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly

  • Key: FUML12-24
  • Legacy Issue Number: 18722
  • Status: closed  
  • Source: LieberLieber Software ( Mrs. Tanja Mayerhofer)
  • Summary:

    RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly

    The while loop for finding the link with the position defined with the removeAt pin is implemented incorrectly. The loop variable is not correctly incremented.

    The following code would be the resolution for this bug:

    >>> while (notFound & i <= links.size()) {
    Link link = links.getValue(i - 1);
    if (link.getFeatureValue(feature).position == removeAt)

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

    >>> ++i;
    }

  • Reported: FUML 1.1 — Thu, 16 May 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update RemoveStructuralFeatureValueActionActivation

    Agreed.

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

ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06)

  • Key: FUML12-32
  • Legacy Issue Number: 19007
  • Status: closed  
  • Source: PhD Student ( Alessandro Gerlinger Romero)
  • Summary:

    ReadSelfAction issue - in a scenario where an activity with a context (classifier) calls (CallBehaviorAction) an activity owned by other classifier, the ReadSelfAction (from fUML execution model) violates the constraint defined in UML superstructure 2.4.1 because it returns the context from the caller activity (not necessary the same classifier).

    8.6.3.2.10 ReadSelfActionActivation
    Reference context = new Reference();
    context.referent = his.getExecutionContext();

    11.3.36 ReadSelfAction (from IntermediateActions), pg. 280 - UML 2.4.1
    [3] The type of the result output pin is the host classifier.
    self.result.type = self.context

  • Reported: FUML 1.1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Closed; No Change — FUML 1.2
  • Disposition Summary:

    fUML constrains calls to behaviors with contexts

    The semantics of ReadSelfAction is exactly as called for by the UML standard: it retrieves the context object for an execution. The issue raised is really a question about the propagation of the dynamic context object specified as part of the semantics of CallBehaviorAction.

    But note that, in 7.5.2.2.3 CallBehaviorAction, the following constraint is included on the fUML subset of the UML abstract syntax:

    [3] proper_context
    If the behavior has a context, it must be the same as the context of the enclosing activity or a (direct or indirect) superclass of it.

    self.behavior.context->notEmpty() implies
      union(self.context.allParents())->includes(self.behavior.context)
    

    [Actually, the OCL here has an error. The call to {{union}} should be {{self.context->union}}. This will be submitted as a separate issue.]

    If this constraint is satisfied, then the propagation of the context object in 8.6.2.2.3 CallBehaviorActionActivation is consistent, as noted in the following comment on the doAction operation: [Note that this requires the behavior context to be compatible with the type of the current contect object.]. If the above constraint is violated, then the model is outside the fUML subset, and fUML does not provide semantics for it.

    This constraint was added to the abstract syntax in order to be able to provide reasonable semantics at all for making a call to a behavior with a context. Unless one can propagate the caller's context, it is not clear what context object one would give to the new execution of the called behavior. Unlike the case of an operation call, in which the target object of the call becomes the context for the execution of the operation method, no target object is specified for a behavior call. However, if the above constraint holds, then the called behavior's context is guaranteed to be consistent with the caller's context, and it is then valid to propagate the dynamic context object at runtime. (This might be useful, e.g., for doing a functional decomposition of a behavior that is the method of an operation.)

    And, in this case, the current semantics for ReadSelfAction is then completely consistent. While a called behavior may have a different context classifier than the calling behavior, the constraint ensures that it will at least be a generalization of the context classifier of the calling behavior, so the runtime context object from the calling execution will conform to the caller's context classifier. On the other hand, if the called behavior does not have a context classifier, then an execution of the called behavior will have itself as its context object, which will then be (correctly) what is returned by a ReadSelfAction.

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

Correction of method UnlimitedNaturalValue.equals

  • Key: FUML12-31
  • Legacy Issue Number: 18800
  • Status: closed  
  • Source: LieberLieber Software ( Mrs. Tanja Mayerhofer)
  • Summary:

    The method UnlimitedNaturalValue.equals compares if the two compared UnlimitedNaturalValue instances refer to the same instance of UnlimitedNatural:

    isEqual = ((UnlimitedNaturalValue) otherValue).value.naturalValue == this.value.naturalValue;

    Instead the integer values of the attribute "naturalValue" of the referenced UnlimitedNatural instances should be compared:

    isEqual = ((UnlimitedNaturalValue) otherValue).value.naturalValue == this.value.naturalValue;

    Alternatively the equals method could be overriden in the class UnlimitedNatural and called by the method UnlimitedNaturalValue.equals

  • Reported: FUML 1.1 — Wed, 3 Jul 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update UnlimitedNaturalValue::equals

    The two code snippets given in the issue description are identical. However, the actual statement in the current specification is

    isEqual = ((UnlimitedNaturalValue) otherValue).value == this.value;
    

    which, as stated in the issue, incorrectly compares the UnlimitedNatural objects, not their natural values. The correction is as given in the issue.

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

ListFunctions should have a ListConcat behavior

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 9.2.6 List Functions

    The FoundationalModelLibrary::PrimitiveBehaviors::ListFunctions currently includes only ListGet and ListSize behaviors. However, given only these functions and the other capabilities in fUML, it is very difficult (if not impossible) to concatenate two arbitrary lists. The ListFunctions package should have a primitive ListConcat behavior to perform this function.

  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Add ListFunctions::ListConcat

    It actually is possible to implement a ListConcat activity, using two "pass-through" structured activity nodes connected by a control flow, which sequentially feed the two lists to be concatenated to a merge node. However, this is certainly not a particularly natural construction. ListSize and ListGet could also actually be implemented using expansion regions/loop nodes (as currently noted in the spec), but it is still more useful to have them as primitive functions. The same is true of ListConcat.

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

FoundationModelLibrary, UnlimitedNaturalFunctions: inconsistencies between the spec and the normative xmi

  • Key: FUML12-14
  • Legacy Issue Number: 18508
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Foundational Model Library: There are inconsistencies between the fuml spec and the normative xmi regarding the two following opaque behaviors from the PrimitiveBehaviors::UnlimitedNaturalFunctions:

    • ToInteger: the spec provides the following signature ‘ToInteger(x: UnlimitedNatural): Integer[0..1]’ (which is correct) while in the normative xmi (ptc/2012-10-21), the return type is UnlimitedNatural
    • ToUnlimitedNatural: in the normative xmi, the type of the return parameter is UnlimitedNatural (which is correct), while the spec provides the following signature ‘ToUnlimitedNatural(x: String): Integer[0..1], Converts x to an Integer value.’
  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Fix discrepencies

    The issue description is correct.

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

The Listener reception of Notification should have a name

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 9.3 Common

    The class FoundationalModelLibrary::Common::Listener has a reception for the signal Notification. However, in the normative fUML_Library.xmi, this reception has no name. It should have a name (preferably the same name as the signal), so it can be referenced as a behavioral feature.

  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Give the reception a name

    Agreed that it would be better if the reception had a name. For example, this is required in order to send a signal via the reception in Alf.

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

FoundationalModelLibrary::Common::Notification should be public

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 9.3 Common

    As shown in Figure 9.3 of Subclause 9.3, the FoundationalModelLibrary::Common package includes a Notification signal used by the Listener active class. In the normative fUML_Library.xmi, Notification has a visibility of private. It should be public.

  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Make Notification public

    Agreed that Notification should be public.

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

The ReadLine::result parameter should have direction "return"

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 9.4.2 Pre-defined ReadLine and WriteLine Behaviors

    The definitions for ReadLine and WriteLine in Subclause 9.4.2 do not give the multiplicity and direction for the parameters of those activities. However, one would expect them to be consistent with the multiplicity and direction for the corresponding parameters of the TextInputChannel::readLine and TextOutputChannel::writeLine operations. This is indeed the case as given in the normative fUML_Library.xmi, except for the result parameter of the ReadLine, which has direction “out”, while the readLine operation result parameter has direction “return”.

  • Reported: FUML 1.1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Change the result parameter direction to return

    Agreed that the ReadLine::result parameter should have direction "return".

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

List parameters of ListFunctions should be non-unique.

  • Key: FUML12-57
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 9.3.6 ListFunctions, the list arguments to both ListSize and ListGet should be non-unique. Otherwise duplicate values in the input "lists" will be removed when those list are passed into the functions, resulting in unintended results. This update should be made in both Table 9.7 and the normative XMI.

    Further, in Table 9.7, the list input parameter to for ListGet is shown as being "ordered". However, the normative XMI in fUML_Library does have it as being ordered. This should be corrected in the XMI.

  • Reported: FUML 1.1 — Wed, 15 Jul 2015 14:56 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Make list parameters non-unique

    Agreed that the list parameters of the list functions should non-unique, and the normative XMI should be properly updated/corrected.

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

The fUML subset should include central buffer nodes and data stores

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

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

    Unlike pins, the tokens in central buffer nodes and data stores (which are kind of central buffer node) are not consumed when they are accessed. This allows a value to be, e.g., stored in a data store and used repeatedly in a loop that is modeled directly using flows rather than using a loop node. It is more common to create loops using flows than structured nodes when drawing graphical activity diagrams, and fUML should provide reasonable execution semantics for such models using central buffer nodes and data stores.

  • Reported: FUML 1.0 — Wed, 26 Jan 2011 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

fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2

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

    In the fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2, it states that:

    The empty-output-parameter-node relation ensures executions of expansion region action (the xac variable) transfer values from an output parameter node of the executions of the constructed activity (xcall) to the corresponding output pin of the expansion region (op). It assumes output pin multiplicity upper (opmax) is one or unlimited. This does not put null tokens in output pins when output parameter nodes are empty, as in UML.

    The final sentence is no longer consistent with the fUML operational semantics given in the execution model, which was updated by the resolution of Issue 14550 to offer a null token from an output pin if it holds no values when it fires.

  • Reported: FUML 1.0 — Tue, 27 Jul 2010 04: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

Annex on normative XMI for fUML

  • Key: FUML12-3
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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

Section: Base Semantics

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

    SendSignalAction completion semantics. SendSignalAction shouldn't require the event pool to be updated before the action completes.

  • Reported: FUML 1.0b1 — Thu, 18 Dec 2008 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

ReclassifyObjectAction does not preserve structural feature values

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 (ptc/2012-10-18)

    Subclause: 8.6.4.2.5 ReclassifyObjectActionActivation

    The UML 2.4.1 specification says, in Subclause 11.3.39, under the Semantics for ReclassifyObjectAction, that "'New' classifiers replace existing classifiers in an atomic step, so that structural feature values and links are not lost during the reclassification, when the 'old' and 'new' classifiers have structural features and associations in common." However, the behavior specified in ReclassifyObjectActionActivation does not act this way. Instead, all feature values for old classifiers are removed before the feature values for new classifiers are added, so any values for common structural features are lost.

  • Reported: FUML 1.0 — Fri, 23 Nov 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update ReclassifyObjectActionActivation

    Agreed. In addition, the semantics for a reclassify object action should ensure that private superclass attributes are removed or initialized as appropriate, consistent with the resolution to issue FUML12-20.

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

RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop

  • Key: FUML12-22
  • Legacy Issue Number: 18714
  • Status: closed  
  • Source: LieberLieber Software ( Mrs. Tanja Mayerhofer)
  • Summary:

    If a value of a structured value shall be removed and the isRemoveDuplicates flag of the RemoveStruturalFeatureValueAction is set to true or if the removeAt pin was null, the position(s) of the value to be removed are determined by calling the operation int WriteStructuralFeatureActionActivation.position(Value, ValueList, int). The problem is that the last found position is provided as startPosition for the next call of the position operation. Therefore this found position is found again and again in each call of the operation resulting in an infinite loop.

    Resolution:
    Replace the following operation call
    j = this.position(inputValue, featureValue.values, j);
    with
    >>> j = this.position(inputValue, featureValue.values, j+1);
    In line 113 (last statement in while loop of if (action.isRemoveDuplicates) clause) and 121 (last statement in while loop of else if (action.removeAt == null) clause).

  • Reported: FUML 1.1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update RemoveStructuralFeatureValueActionActivation

    In the case of action.isRemoveDuplicates = false and action.removeAt = null, the issue is correct that the current specification will result in an infinite loop if the given structural feature holds any instances of the given value.

    However, the issue is not correct for the case action.isRemoveDuplicates = true. In that case, instance of the given value found at position j is removed before the search for the position of the next instance, so beginning the search at position j is correct. Indeed, starting the next search at position j+1 could cause an instance of the value to be skipped, if it happened to come right after the instance that had just been removed.

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

The bodyOutputLists for a loop node need to be cleared when the node fires again

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1 RTF Beta (ptc/2012-10-18)

    Subclause: 8.5.3.2.3 LoopNodeActivation

    The beginning of LoopNodeActivation::doStructuredActivity creates the bodyOutputLists for the firing of a loop node. However, it does not first clear any bodyOutputLists that may have been created on a previous firing of the loop node. This can result in an exception if a loop node fires repeatedly (for instance, if it is nested in another loop node), because there will be more body output lists than there are result pins.

    (Also, the variables loopVariables and resultPins are no longer used within doStructuredActivity.)

  • Reported: FUML 1.0 — Mon, 26 Nov 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update LoopNodeActivation::doStructuredActivity

    Agreed.

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

Objects with cyclic references cannot be converted to string representations

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 8.3.2.2.2 CompundValue

    The CompoundValue::toString operation calls toString on each value of each featureValue of a compound value. If one of these values is a reference then Reference::toString operation calls toString on the referenced object. Thus, if two or more objects cyclically reference each other, calling toString on any one of them will result in an infinite recursion.

  • Reported: FUML 1.1 — Sat, 5 Jan 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update CompoundValue::toString

    Agreed. If the feature value is a reference, then it is sufficient to show the object ID and list the names of the types of the object.

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

Computer-readable version of the Base Semantics

  • Key: FUML12-26
  • Legacy Issue Number: 18795
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It should be made available a computer-readable version of the Base Semantics, as a CLF file. The place would be the OMG site where other files defined by this specification were available, such as, XML Metadata Interchange (XMI).

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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

Defects in Base Semantics from fUML

  • Key: FUML12-25
  • Legacy Issue Number: 18794
  • Status: closed  
  • Source: PhD Student ( Alessandro Gerlinger Romero)
  • Summary:

    There were found 42 issues, 5 of them were enhancements proposals, and 37 were defects.

    The main issues concerning defects were:
    1. The Base Semantics had a defect in the section 10.4.8.3 (pg. 383). There was missing a forall construction, which did not allow to parse entire definition.
    2. After applied the necessary remedy actions to the definition, a model finder (EPROVER) was used to check if the fUML definition together with PSL definition - psl_outer_core - was satisfiable. The fUML Base Semantics together with PSL was unsatisfiable.
    3. A model finder (EPROVER) also was used to check if the Base Semantics alone (without PSL) was satisfiable. The fUML Base Semantics was unsatisfiable.

    I have been made available a file with all analyzed files at the following address:

    http://es.cs.uni-kl.de/people/romero/fUMLOMGIssue20130630.zip

    This file can help to recognize the defects.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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

RealValue::toString puts too many digits in the mantissa

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)
    Subclause: 8.3.2.2.21 RealValue

    The toString operation for RealValue is specified to determine the mantissa of a real number to 10 significant digits. It does this by scaling the (absolute value of) the real number and then converting it to an integer. Per the bUML representation in Annex B, the integer value is denoted as a Java int. Unfortunately, the upper bound of a Java int is 2,147,483,647, so some ten digit integers will overflow this value. While it is technically the UML semantics that apply to the specification here, via the Annex B mapping, not the Java semantics, it is still convenient (and intended) for the execution model operations to be able to run as Java methods, too. Therefore, it would be better to limit the mantissa to 9 digits rather than 10, so that the Java int representation of the mantissa never overflows.

  • Reported: FUML 1.1 — Sat, 5 Jan 2013 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update RealValue::toString

    Agreed.

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

Problem with ActivityExecution::terminate

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

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.1, RTF Beta (ptc/2012-10-18)

    Subclauses: 8.5.2.2.2 ActivityExecution

    The ActivityExecution::terminate operation calls terminateAll on the activationGroup for the activity execution. However, the activationGroup attribute is not set unless the execute operation has been called. If an activity is started asynchronously, then it will be instantiated as an activity execution within a classifier behavior execution, but, since this execution is asynchronous to the invoker of the activity, it is possible for the invoker to destroy (and so terminate) the activity instance before the activity execution is actually executed. That is, it is, in fact, possible for the terminate operation to be called on an activity execution without the execute operation ever having been called.

    In order to avoid a possible error, the terminate operation should check that the activationGroup is not null before calling terminateAll on it.

  • Reported: FUML 1.1 — Sun, 30 Dec 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.2
  • Disposition Summary:

    Update ActivityExecution::terminate

    Agreed.

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

The fUML subset shuold support the raising and handling of exceptions

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

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

    The submission team for the Alf action language felt that is was important that the action language be able to support exceptions, since existing class models in UML may include operations that raise exceptions and it should be possible to use the action language to specify methods for such operations without having to change how errors are reported. However, without exceptions being included in the fUML subset, the mapping of the raising and handling of exceptions in the action language to fUML was too complicated and probably semantically questionable.

    Therefore, support for the raising and handling of exceptions should be included in the fUML subset so that it can properly be included in the surface action language notation.

  • Reported: FUML 1.0 — Wed, 26 Jan 2011 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

Remove unneeded inference rules from Base Semantics

  • Key: FUML12-30
  • Legacy Issue Number: 18799
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Inference rules not used, and not needed for completeness, should be removed

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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

Cover all ActivityNodes used in bUML

  • Key: FUML12-29
  • Legacy Issue Number: 18798
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The specification should cover all ActivityNodes used in bUML. It should be added declarative definition for ActivityFinalNode because it is used in annex A.3.1, and A.3.2, pages 401, and 402. However, it should be evaluated the replacement of this node to FlowFinalNode. For the last, a proposal is defined

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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

Actions outside the bUML

  • Key: FUML12-28
  • Legacy Issue Number: 18797
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It should not define constraints for Actions outside the bUML: AcceptEventAction and ReadIsClassifiedObjectAction. In the other way around, it should be evaluated if these actions should be included in bUML. The java statement instanceof is used from page 98 to page 328, therefore the ReadIsClassifiedObjectAction should be added to bUML.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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

Base Semantics PSL version

  • Key: FUML12-27
  • Legacy Issue Number: 18796
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Base Semantics should declare the PSL version used to define it.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04: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