1. OMG Mailing List
  2. Semantics of a Foundational Subset for Executable UML Models 1.3 (fUML) RTF

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: fuml-rtf
  • Issues Count: 107

Issues Summary

Key Issue Reported Fixed Disposition Status
FUML13-60 Simplification to the resolution of Issue FUML13-1 FUML 1.2 FUML 1.3 Resolved closed
FUML13-25 Refactor EventOccurrence to provide useful operations FUML 1.2 FUML 1.3 Resolved closed
FUML13-4 The fUML subset should include central buffer nodes and data stores FUML 1.0 FUML 1.3 Resolved closed
FUML13-23 EventOccurrence should be used instead of SignalInstance in execution model operation parameters FUML 1.2 FUML 1.3 Resolved closed
FUML13-1 SendSignalAction completion semantics FUML 1.0b1 FUML 1.3 Resolved closed
FUML13-26 Reference::equal should use Object::equals FUML 1.2 FUML 1.3 Resolved closed
FUML13-49 Correction to the resolution to issue FUML13-25 FUML 1.2 FUML 1.3 Resolved closed
FUML13-24 Return type of getNextEvent is wrong in Figure 8.17 FUML 1.2 FUML 1.3 Resolved closed
FUML13-22 Association Roles in Figure 7.3 Flipped FUML 1.2 FUML 1.3 Resolved closed
FUML13-16 Introduce CallEvent, AcceptCallAction and ReplyAction to keep consistency with PSSM FUML 1.2 FUML 1.3 Resolved closed
FUML13-12 Bad event accepter removed from the waitingEventAccepter list FUML 1.2 FUML 1.3 Resolved closed
FUML13-19 The fUML spec uses "new" in diagrams and text in a specialized manner that is not defined. FUML 1.2 FUML 1.3 Resolved closed
FUML13-17 Stand-alone owned behavior of BehavioredClassifier shall be possible FUML 1.2 FUML 1.3 Resolved closed
FUML13-27 Input parameter activity nodes should fire first FUML 1.2 FUML 1.3 Resolved closed
FUML13-21 BasicInputOutput operations for reading and writing reals are missing FUML 1.2 FUML 1.3 Resolved closed
FUML13-32 There is an incorrect note about navigating links using structural feature actions FUML 1.2 FUML 1.3 Resolved closed
FUML13-18 Prose for semantics of AddStructuralFeatureValueAction required FUML 1.2 FUML 1.3 Resolved closed
FUML13-14 Incomplete update to ClassifierBehaviorInvocationEventAccepter::invokeBehavior FUML 1.2 FUML 1.3 Resolved closed
FUML13-28 The specification of IntegerFunctions::Div is incorrect FUML 1.2 FUML 1.3 Resolved closed
FUML13-20 Error in RealValue::toString FUML 1.2 FUML 1.3 Resolved closed
FUML13-29 "Debug" statements should be removed FUML 1.2 FUML 1.3 Resolved closed
FUML13-3 Base semantics: incorrect description of empty-output-parameter-node FUML 1.0 FUML 1.3 Resolved closed
FUML13-10 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-6 Defects in Base Semantics from fUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-5 The fUML subset should support the raising and handling of exceptions FUML 1.0 FUML 1.3 Deferred closed
FUML13-2 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.3 Deferred closed
FUML13-9 Actions outside the bUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-7 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.3 Deferred closed
FUML13-11 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.3 Deferred closed
FUML13-8 Base Semantics PSL version FUML 1.1 FUML 1.3 Deferred 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-23 RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value 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-10 Certain Boolean flags are not properly initialized in some cases FUML 1.0 FUML 1.2 Resolved closed
FUML12-8 LoopNodeActivation does not correctly handle the firing of a contained activity final node 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-34 AcceptEventActionActivation::match should match instances of descendants of a trigger's signal 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-24 RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly 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-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-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-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-36 Problem with CallActionActivation: possible infinite loop in removeCallExecution() 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-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-22 RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop FUML 1.1 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-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-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-7 ReclassifyObjectAction does not preserve structural feature values FUML 1.0 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-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
FUML12-6 The fUML subset shuold support the raising and handling of exceptions FUML 1.0 FUML 1.2 Deferred closed
FUML11-22 ExpansionRegionActivation isReady condition is too strong FUML 1.0 FUML 1.1 Resolved closed
FUML11-21 ForkNodeActivation does not clear its tokens on termination FUML 1.0 FUML 1.1 Resolved closed
FUML11-20 ExpansionRegionActivation does not reset its activationGroups FUML 1.0 FUML 1.1 Resolved closed
FUML11-19 Error in check for enable nodes FUML 1.0 FUML 1.1 Resolved closed
FUML11-18 Structural Feature Actions on Data Values Need to Create a new Result Value FUML 1.0 FUML 1.1 Resolved closed
FUML11-17 ActionActivation.sendOffers(): Missing sending of offers on outgoing control flows? FUML 1.0 FUML 1.1 Resolved closed
FUML11-16 ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor FUML 1.0 FUML 1.1 Resolved closed
FUML11-15 Error handling creation and destruction of links of associations with ordered ends FUML 1.0 FUML 1.1 Resolved closed
FUML11-14 Error in ActivityNodeActivationGroup::getOutputParameterNodeActivations FUML 1.0 FUML 1.1 Resolved closed
FUML11-13 Bug in ForkedToken::withdraw when the baseToken is a ForkedToken FUML 1.0 FUML 1.1 Resolved closed
FUML11-12 Bug in DestroyObjectActivation::objectIsComposite FUML 1.0 FUML 1.1 Resolved closed
FUML11-11 Error in RemoveStructuralFeatureVauleActionActivation::doAction FUML 1.0 FUML 1.1 Resolved closed
FUML11-10 Spurious comment on operation PinActivation::fire FUML 1.0 FUML 1.1 Resolved closed
FUML11-9 Error in DecisionNodeActivation semantics FUML 1.0 FUML 1.1 Resolved closed
FUML11-8 Duplicate code for ActionActivation::putToken FUML 1.0 FUML 1.1 Resolved closed
FUML11-7 Error in CreateLinkAction semantics FUML 1.0 FUML 1.1 Resolved closed
FUML11-6 Error in ExpansionRegionActivation::takeOfferedTokens FUML 1.0 FUML 1.1 Resolved closed
FUML11-5 The fUML Foundational Model Library should support the new UML 2.4 Real primitive type FUML 1.0 FUML 1.1 Resolved closed
FUML11-39 Addition to the resolution to fUML Issue 17499 FUML 1.0 FUML 1.1 Resolved closed
FUML11-38 Correction to the resolution to fUML Issue 17209 FUML 1.0 FUML 1.1 Resolved closed
FUML11-37 Addition to the resolution of fUML Issue 17203 FUML 1.0 FUML 1.1 Resolved closed
FUML11-36 Addition to the resolution to fUML Issue 15987 FUML 1.0 FUML 1.1 Resolved closed
FUML11-35 Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A FUML 1.0 FUML 1.1 Resolved closed
FUML11-34 Conditional node and loop node activations do not wait for contained accept event action activations FUML 1.0 FUML 1.1 Resolved closed
FUML11-33 Null tokens are not sent on by control nodes FUML 1.0 FUML 1.1 Resolved closed
FUML11-32 Errors in ReduceActionActivation::doAction FUML 1.0 FUML 1.1 Resolved closed
FUML11-31 Addition to resolution to Issue 17299 FUML 1.0 FUML 1.1 Resolved closed
FUML11-30 Error in setting result pin values for CallActions FUML 1.0 FUML 1.1 Resolved closed
FUML11-29 Read link actions and read structural feature actions do not handle ordered ends correctly FUML 1.0 FUML 1.1 Resolved closed
FUML11-28 Correction to the resolution of Issue 17209 FUML 1.0 FUML 1.1 Resolved closed
FUML11-27 Structured activity node activations do not wait for contained accept event action activations FUML 1.0 FUML 1.1 Resolved closed
FUML11-26 DecisionNodeActivation can send offers to multiple outgoing edges FUML 1.0 FUML 1.1 Resolved closed
FUML11-25 Having a fork node as initial enabled node does not work FUML 1.0 FUML 1.1 Resolved closed
FUML11-24 An activity final node should not fire if it is not offered any tokens FUML 1.0 FUML 1.1 Resolved closed
FUML11-23 LoopNodeActivation does not properly handle termination due to an activity final node FUML 1.0 FUML 1.1 Resolved closed
FUML11-4 fUML 1.1 should be based on UML 2.4 FUML 1.0 FUML 1.1 Resolved closed
FUML11-3 An action may not stop firing again FUML 1.0b2 FUML 1.1 Resolved closed
FUML11-2 Flow final nodes should be included FUML 1.0b1 FUML 1.1 Resolved closed
FUML11-1 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add FUML 1.0b1 FUML 1.1 Resolved closed

Issues Descriptions

Simplification to the resolution of Issue FUML13-1

  • Key: FUML13-60
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Work on the PSCS 1.1 revision has indicated that the resolution to FUML13-1 could be simplified.

    1. There is no need to for the SendSignal signal. It is enough for the EventOccurrence classifier behavior to start asynchronously.

    2. The call to Reference::send can be moved into a EventOccurrence::doSend operation, simplifying the EventOccurrence SendingBehavior activity and also allowing doSend to be overridden in subclasses of EventOccurrence.

  • Reported: FUML 1.2 — Fri, 10 Feb 2017 18:52 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Update EventOccurrence::SendBehavior

    Agreed that the resolution to FUML13-1 can be simplified as suggested.

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

Refactor EventOccurrence to provide useful operations

  • Key: FUML13-25
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The EventOccurrence class was introduced in fUML 1.2 as the parent of SignalEventOccurrence and InvocationEventOccurrence. However, as introduced, it has no operations. This means that, to operate on any EventOccurrence instance, it is necessary to check what the actual type of the instance is and then cast it to the appropriate subclass. This becomes increasingly cumbersome as additional subclasses are added in other specifications built on fUML (such as CallEventOccurrence for PSSM). It would be clearer and more extensible to have certain general operations defined abstractly for EventOccurrence, which could then have proper implementations in appropriate subclasses. Useful such operations would include at least one to match an EventOccurrence against a Trigger and one to extract any event data from an EventOccurrence.

  • Reported: FUML 1.2 — Thu, 8 Dec 2016 19:46 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Add operations to EventOccurrence

    Other than for invocation event occurrences, the acceptance of an event occurrence is constrained to the case when they match a trigger. In fUML only accept event actions have triggers, and only for signal events, but specifications built on fUML (such as PSSM) may allow other model elements to have triggers (such as transitions in state machines) and allow other kinds of events on triggers (such as call events). Each kind of event occurrence has specific logic required to determine whether it matches a specific trigger and to extract any data embedded in it. Currently, fUML embeds this logic in classes specific to the handling of signal event occurrences, without providing a common interface for allowing other specifications to provide different logic for different kinds of event occurrences.

    A better approach would be to provide a common interface of abstract operations in EventOccurrence for matching (match) and data extraction (getParameterValues). These operations would have different behaviors in different concrete subclasses of EventOccurrence, but they could be accessed consistently across all kinds of event occurrences. For fUML, this would then require providing such concrete behavior in the SignalEventOccurrence subclass, with corresponding updates to AcceptEventActionActivation and AcceptEventActionEventAccepter to take advantage of the new operations. (The operations would be essentially stubbed out in InvocationEventOccurrence.)

    Note also that the matching of a signal occurrence to a signal event trigger that currently occurs in AcceptEventActionActivation::match uses the checkAllParents helper operation. This helper operations is currently in ActionActivation, since it is also used in ReadIsClassifiedObjectActionActivation::doAction. However, when the signal matching logic is moved to SignalEventOccurrence::match, ActionActivation is no longer a common superclass. In order to avoid repeating the definition of checkAllParents, this helper operation can be moved to the Value class. This allows the definition of a useful Value::isInstanceOf operation, which can be used in both SignalEventOccurrence::match and ReadIsClassifiedObjectActionActivation::doAction instead of calling checkAllParents directly, simplifying both of those operations.

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

The fUML subset should include central buffer nodes and data stores

  • Key: FUML13-4
  • Legacy Issue Number: 15988
  • Status: closed  
  • Source: nMeta ( 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: Resolved — FUML 1.3
  • Disposition Summary:

    Add central buffer nodes and data stores

    Actually, the tokens in a central buffer node are withdrawn from the central buffer node when offers for them are accepted. On the other hand, values on tokens in data store nodes do effectively "persist". This makes data store nodes the important ones to include. However, since data store nodes are kinds of central buffer nodes, including data store nodes implies the need to also include central buffer nodes.

    CentralBufferNode is in the IntermediateActivities package in UML 2.4.1, which is already included in the fUML subset. DataStoreNode, however, is in the CompleteActivities package, which, heretofore, has not been part of the fUML subset. Therefore, in order to add DataStoreNode, it is necessary to add a new subclause for the CompleteActivities package, even though only one metaclass is to be included from that package. Further, this package must be added to the L3 merge for fUML.

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

EventOccurrence should be used instead of SignalInstance in execution model operation parameters

  • Key: FUML13-23
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The EventOccurrence class was introduced in fUML 1.2, with SignalEventOccurrence . However, the execution model classes Object, ObjectActivation and Reference still use SignalInstance as the type of various operations related to sending. These should be changed to EventOccurrence to allow other specifications built on fUML to specify the sending of other types of EventOccurrences (such as CallEventOccurrences in PSSM).

  • Reported: FUML 1.2 — Thu, 8 Dec 2016 19:26 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Change SignalInstance usage to EventOccurrence

    In the current shape of the fUML semantic model, active objects can only perform event based communications using signals. This limitation is introduced by the way that: Reference, Object and ObjectActivation classes are defined. Indeed, these latter all provide a send(in signal: SignalInstance) operation which only enables a signalInstance to be sent to the event pool of an active object.

    However, it became clear that extensions to fUML may need to support event based communications not limited to signal event occurrence. PSSM is good example of this with the introduction of a support for call event occurrence. In order to relax the constraint on the type of event based communications that can be performed between instance of active objects, the signatures and the implementations of the send operations provided by Reference, Object_ and ObjectActivation must be changed. This change consists in using EventOccurrence in place of SignalInstance in the signatures and implementations of the different send operations. Note that the doAction operation of the SendSignalActionActivation class will have to be updated to account for changes performed in Reference class.

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

SendSignalAction completion semantics

  • Key: FUML13-1
  • Legacy Issue Number: 13166
  • Status: closed  
  • Source: NIST ( 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: Resolved — FUML 1.3
  • Disposition Summary:

    Add active behavior to EventOccurrence

    Adding an event occurrence into the event pool of the target should always be done in a separate execution thread than that of the sender of the event occurrence. Not only does this better model the asynchronous nature of signal sends, it also better models the semantics of inter-object communication in general, as discussed in 2.4 Genericity of the Execution Model, even for, say, call event occurrences. That is because the semantics of concurrency in fUML allows for arbitrary sequential or parallel ordering of the execution of concurrent behaviors. Therefore, having concurrent threads for actually sending each event occurrence to the target better models the possibility that concurrent sends may be arbitrarily re-ordered, or even potentially lost (if the execution of a send behavior ends up being postponed, say, until sequentially after its target object has been destroyed).

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

Reference::equal should use Object::equals

  • Key: FUML13-26
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The Reference::equals operation checks that two References are equal if they reference the same Object. This check is done by testing the identity of the two referenced Objects using "==". It would be better if the test on the Objects was done using the Object::equals operation. Even though the Object::equals operation itself simply uses "==", using Object::equals in Reference::equals allows for the possibility of subclasses of Object to redefine equals as used in Reference (this is desirable, for example, for the PSSM DoActivityContextObject class, which should be considered "equal", but not "identical", to the Object that it wraps).

  • Reported: FUML 1.2 — Thu, 8 Dec 2016 19:53 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Update Reference::equals and add Object::equals

    Actually, Object does not currently override the equals operation, so that the CompoundValue::equals operation is inherited, which specifies equality based on value, not identity. However, if an appropriate Object::equals operation is also added, then the Reference::equals operation may be updated as suggested in the issue description.

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

Correction to the resolution to issue FUML13-25

  • Key: FUML13-49
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Jeremie Tatibouet)
  • Summary:

    Resolution of issue FUML 13-25 forgets to mention to remove a small piece of code.

    At the very end of the proposal, when the change required to be applied to ReadIsClassifierObjectActionActivation was explained, it was proposed to:

    ­

    replace the statement int i = 1; and the while loop immediately after that statement with:

    This was not sufficient since the newly proposed if statement implied that it was not required to iterate over the list of types of the input. Hence the above-mentioned change must be replaced with:

    replace statements ClassifierList types = input.getTypes() , int i = 1 as well as the while loop immediately after that statements with:”

  • Reported: FUML 1.2 — Thu, 26 Jan 2017 08:25 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Remove unnecessary statement

    Event though leaving the statement ClassifierList types = input.getTypes(); causes no functional effect, it is, as the issue notes, no longer necessary. Therefore, it is confusing to leave in and should be removed.

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

Return type of getNextEvent is wrong in Figure 8.17

  • Key: FUML13-24
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Figure 8.17 shows the return type of ObjectActivation::getNextEvent as SignalInstance. However, the return type given in 8.4.3.2.7 ObjectActivation is EventOccurrence. The type in Figure 8.17 should be updated to EventOccurrence.

  • Reported: FUML 1.2 — Thu, 8 Dec 2016 19:36 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Fix getNextEvent return type

    Agreed. In addition, the wrong return type is also shown for the getNextEvent operation on the strategy classes. And the return type is wrong in the normative semantic model XMI, too.

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

Association Roles in Figure 7.3 Flipped

  • Key: FUML13-22
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    In figure 7.3 - Root on page 26, the association roles "/owner" and "/ownedElement" on the recursive Association are flipped. Current "/owner" should be "/ownedElement" and current "/ownedElement" should be "/owner".

  • Reported: FUML 1.2 — Tue, 29 Nov 2016 02:01 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Fix Figure 7.3

    Agreed, Figure 7.3 is incorrect as indicated in the issue. However, the corresponding normative XMI is correct. This is entirely a diagrammatic problem.

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

Introduce CallEvent, AcceptCallAction and ReplyAction to keep consistency with PSSM

  • Key: FUML13-16
  • Legacy Issue Number: 19845
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    fUML shall introduce CallEvent, AcceptCallAction and ReplyAction into fUML and harmonize their semantics with the "fragmented method" paradigm of state machines (and PSSM). In fact, the handling of CallEvents should be the same as the handling of SignalEvents in fUML.

    This would mean that CallOperationActions do not any longer result in the execution of the method Behavior of an Operation, but in the generation of a CallEvent that is put into the event pool of the target object of the CallOperationAction. This would also require to not permit Operations to contain method - this would be then in synch with Reception.

    AcceptCallAction should be introduced, or AcceptEventAction should be relaxed to specify Trigger that refer to CallEvents.

    In addition, ReplyActions shall be included in order to finally send the result of the execution of the Operation.

  • Reported: FUML 1.2 — Wed, 4 Nov 2015 05:00 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Add CallEvent, AcceptCallAction and ReplyAction

    To disallow the use of methods to implement operations, as suggested in the issue description, would be a major backward incompatibility with previous versions of fUML and a radical departure from typical object-oriented practice. It would also essentially require all classes to be active, since only active objects have event pools and can react to event occurrences. Finally, it would require that the fUML execution model be completely rewritten, along with its base semantics, since it currently uses an OO style in which (concrete) operations always have methods.

    On the other hand, the Precise Semantics of State Machines (PSSM) specification (as submitted) adds the ability for state machines to handle call events, as an alternative to, not a replacement for, using methods to implement operations. But the generic handling of operations via call events (as described in the UML 2.4.1/2.5 semantics) is not really specific to state machines. So it is reasonable to suggest that this capability would be better incorporated into the common behavior semantics of fUML, rather than only being available when a tool conforms to PSSM.

    Indeed, the PSSM alpha specification gets around the lack of support for call events in the fUML common semantics by introducing a specialization of the RedefinitionBasedDispatchStrategy class that returns a special kind of Execution when a call is to be handled using a call event. However, this means that any tool using an alternative dispatch strategy would also need to have a specialization of that strategy that is similarly modified to be able to handle calls using call events – but only for use when PSSM is supported. It would clearly be better if any properly specified dispatch strategy would automatically work whether a call ended up being handled by a method or by a call event occurrence.

    Further, the PSSM alpha specification uses a "spin loop" (i.e., a loop that continually checks the value of a semaphore, which is expected to be reset by a concurrent process) to specify the blocking of a caller while it waits for a call event occurrence to be handled by the target object. This is problematic, since the fUML concurrency semantics do not guarantee that any one executing process allow any other process to execute, except at a "wait point" (such as an accept event action). This means that, as currently specified in PSSM, it would be a legal execution trace for a "blocked" caller to continually execute its loop, without allowing the target object classifier behavior to ever execute to handle the call event occurrence, so the call would never complete.

    Any alternative to using a "spin loop" blocking approach would need to be incorporated directly into the fUML common behavior semantics. Unfortunately, to do so would require a major change to the handling of synchronous calls in general. This is because, even if a behavior is itself invoked directly, whether via a direct call or as an operation method, it could (directly or indirectly) call an operation that is handled using a call event occurrence. Thus, the execution model would have to take into account that, on any call action or other synchronous behavior execution, the call might have to block for an arbitrarily long amount of time (or forever), waiting while some call event occurrence remains unhandled.

    One way to handle this would be by specifying that output parameter values from any behavior execution be delivered via a "call back" mechanism. A caller would provide a "continuation" object when calling the execute operation on the behavior execution, and output parameter values from the invocation would be delivered by calling an operation on the provided object, rather than being set during the running of execute itself. Thus, if the call gets blocked waiting for the handling of a call event occurrence, the original execute call could return, with the caller only continuing once a call back is made to its continuation object (if ever).

    But this would be a major change to the fundamental approach for handling synchronous invocation in the fUML execution model, all the way up to the event accepter mechanism (since a run-to-completion step is essentially specified in the fUML execution model by making a synchronous call to an event accepter). And this would not only complicate the specification of fUML, it would also make it significantly more complicated to handle, e.g., the invocation of entry, exit and effect behaviors on state machines in PSSM. It is therefore not considered feasible to propose this approach in the context of an RTF issue resolution.

    Another possibility would be to introduce a mechanism into the base semantics, that is, the formal semantics of Base UML (bUML), in which the fUML execution model is written. However, in order to do this, it would be necessary to also extend bUML syntactically with a UML feature that could represent such blocking. For example, an accept event action could be used with a trigger for a change event on a semaphore attribute (which would avoid the need for a spin loop) or for a time event (which would allow a caller to "wait" for some period of time during an iteration of a spin loop, allowing other processes to execute).

    But one of the fundamental tenets of bUML is that it is a syntactic subset of fUML – that is, the fUML execution model is itself a legal fUML model. That means that any new feature introduced into bUML would also need to be introduced into fUML. But both change events and time events have not been incorporated into fUML so far because of the difficulty in specifying their (general) functionality. So, again, it is not considered appropriate to attempt introducing this functionality simply to address an issue that did not even request that functionality specifically.

    Therefore, while this resolution does propose adding CallEvent, AcceptCallAction and ReplyAction to fUML, it specifies their semantics using an approach similar to that in the PSSM alpha specification, using a spin loop. However, a requirement is added, without further formal basis, that an execution trace that consists entirely of a caller executing a spin loop for all time is not allowed, unless no other execution trace is possible (i.e., no other non-blocked concurrent processes are available to execute). It is considered clear that this can be implemented in practice in any execution tool, evn in the absence of further formalization. However, it is also expected that the requirement will be more formally specified in a future major revision of fUML.

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

Bad event accepter removed from the waitingEventAccepter list

  • Key: FUML13-12
  • Legacy Issue Number: 19842
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Jeremie Tatibouet)
  • Summary:

    Consider the case where an active class that has two classifier behaviors is instantiated. Each classifier behavior start on a run-to-completion step to completion step. This step is triggered by the consumption of “InvocationEventOccurrence” that was previously registered into the event pool of the object activation of the instantiated active object.

    When the first classifier behavior executes it suspends on a accept event action “Wait(Start)”. This provokes the registration in the waiting event accepter list of an “accepter” for the signal “Start”.
    The run-to-completion steps completes.

    waitingEventAccepters [ AcceptEventActionEventAccepter ]

    To start the second classifier behavior in a RTC step an “ClassifierBehaviorInvocationEventAccepter” is placed in the list of the waiting event accepters.

    waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ]

    The RTC steps starts when the “InvocationEventOccurrence” placed in the event pool gets consumed.

    The match between the event and the accepter is determined as being at index 1 of the list of waitingEventAccepters.

    matchingEventAccepterIndexes [ 1 ]

    The choice strategy returns 1. Consequently the selected event accepter becomes the one which is at j ­ 1 position the “matchingEventAccepterIndexes” list; so 1.

    waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ]

    However the event accepter that is removed is the one at j-1. Therefore the ClassifierBehaviorInvocationEventAccepter
    remains in the waiting event accepter list while the AcceptEventActionAccepter is removed.

    The assumption is that this.waitingEventAccepters.remove(j - 1); should be replaced by this.waitingEventAccepters.remove(matchingEventAccepterIndexes.get(j - 1));
    to ensure the deletion of the right event accepter.

  • Reported: FUML 1.2 — Thu, 22 Oct 2015 04:00 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Correct dispatchNextEvent

    The issue is indeed a serious bug that has lurked in the specification since version 1.0.

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

The fUML spec uses "new" in diagrams and text in a specialized manner that is not defined.

  • Key: FUML13-19
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This use of "new" is not defined or explained. It is not used in any of the normative references. Though I can guess what it means, it should be formally defined in for fUML to be a formal document.

    If you are using "new" in some sort of Java way, the Java definition needs to be normative, or "new" needs to be defined explicitly.

  • Reported: FUML 1.2 — Thu, 28 Jul 2016 01:04 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Fix incorrect notation for unlimited natural values

    The issue is referring to the notation new UnlimitedNatural(1) used as the default value for the attribute MultiplicityElement::upper in Figure 7.4 and new UnlimitedNatural(0) used as the default value for the attribute LiteralUnlimitedNatural::value in Figure 7.6. This is, indeed, not standard UML notation. The values should be changed to simply 1 and 0, respectively, in the two diagrams. (Note that the default values are already notated correctly in the class descriptions 7.2.2.2.22 MultiplicityElement and 7.2.2.2.21 LiteralUnlimitedNatural.)

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

Stand-alone owned behavior of BehavioredClassifier shall be possible

  • Key: FUML13-17
  • Legacy Issue Number: 19856
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    The constraint [1] UML_allowed_owned_behaviors in section 7.3.2.2.2 prohibits stand-alone owned behaviors of a BehavioredClassifier. This wastes a lot of potential, in particular when CallEvents are finally included into fUML (like in PSSM). Owned behaviors that are not classifier behaviors and not operation methods serve the purpose of tailoring the classifier behavior into smaller scenarios which could even be invoked independently from each other. It further allows the extraction of shared procedures without the need of calling an Operation. It would simply provide higher expressiveness at specification level.

  • Reported: FUML 1.2 — Thu, 12 Nov 2015 05:00 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Remove fUML_allowed_owned_behaviors constraint

    Removing the constraint BehavioredClassifier::fUML_allowed_owned_behaviors might give some benefit, as suggested in the issue description, and would seemingly not cause any problem, at least for calling a non-classifier-behavior owned-behavior synchronously. The constraint CallBehaviorAction::proper_context would still apply, meaning that an owned behavior of a class could only be called from an activity that had the same static context as the target behavior, so that the dynamic context could be properly propagated.

    However, starting such an owned behavior asynchronously would be a problem. Since using a start object behavior action on a non-behavior object always started its classifier behavior (if it has one), the only way to start a non-classifier-behavior owned behavior would be to use it directly as the object of a start object behavior action. But, in this case, there would be no other context object given, so the resulting behavior execution would become its own context – which would not be consistent with the static context of the owned behavior.

    Actually, though, this is already a problem in the current specification, since there currently is no constraint nothing to prevent the method of an operation (or a classifier behavior, for that matter) from being instantiated and a start object behavior action being used on the resulting object. So eliminating fUML_allowed_owned_behaviors does not introduce any new problems. Nevertheless, this problem can be easily fixed by simply disallowing the use of a create object action on an owned behavior. In this way, classifier behaviors could only be started asynchronously by using a start object action on their context object, while other owned behaviors could only be called synchronously.

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

Input parameter activity nodes should fire first

  • Key: FUML13-27
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Consider an activity with one in parameter having multiplicity lower bound of 0. Suppose this activity contains a top-level structured activity node that, in turn, contains an action with an input pin, also having multiplicity lower bound of 0, and an object flow from the activity parameter node for the in parameter to the action input pin. Assume the structured activity node and the action it contains have no other data or control dependencies.

    According to the logic specified in ActivityNodeActivationGroup::run, both the activity parameter node and the structured activity node will be enabled when the enclosing activity is executed (because the structured activity node has no incoming edges, even though the action inside it does). The activity parameter node and the structured activity node therefore fire concurrently. Thus, one allowable execution sequence would be for the structured activity node to fire first, resulting in the firing of its contained action, before the activity parameter node fires. Since the activity parameter node has not fired, it does not yet contain any value that might be on the in parameter, but the action will fire anyway, because its input pin has multiplicity lower bound of 0.

    The fact that it is allowable for the action in this example to fire with no input, even if there is an input available on the in parameter, would seem to not be what most modelers would expect in this situation. To avoid this, it would be better if, when an activity is run, any input activity parameter nodes are fired first, before any other enabled activity nodes. Note that this is parallel to the case of a structured activity node, in which any input pins of the structure activity node fire before any nodes within the structure activity node fire.

  • Reported: FUML 1.2 — Tue, 20 Dec 2016 21:39 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Update ActivityNodeActivationGroup::run

    Agreed.

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

BasicInputOutput operations for reading and writing reals are missing

  • Key: FUML13-21
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    In the FoundationalModelLibrary::BasicInputOutput package, the TextInputChannel and TextOutputChannel classes have specific operations for reading and writing string, integer, boolean and unlimited natural values. However, there are no specific operations for reading or writing real values, which is inconsistent.

    (Note that it is still possible to read and write real values by converting real values to/from strings, so this issue is not absolutely critical.)

  • Reported: FUML 1.2 — Sun, 11 Sep 2016 20:57 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Add readReal and writeReal operations

    Agreed. A readReal operation needs to be added to TextInputCjannel, and a writeReal operation needs to be added to TextOutputChannel. In addition, the discussion of the behavior of the write operation for TextOutputChannel should be updated to mention Real values.

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

There is an incorrect note about navigating links using structural feature actions

  • Key: FUML13-32
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    In 8.6.3.1 Overview, under "Structural Feature Actions", it states in the first note that "In fUML, association ends are always owned by the association and never by the types of the ends (see 7.2.2). Therefore, it is not possible to navigate a link in fUML using a structural feature action." However, as part of the resolution to issue FUML-51 Revise fUML to be based on UML 2.3 (legacy issue number 14550), during fUML 1.0 finalization, the semantics for structural feature actions were change to be in accordance with the resolution to UML22-263 (legacy issue number 10045):

    10045 - The resolution of this issue clarifies that a structural feature action can be used to read and write an association end of a binary association as if it was a feature of the opposite classifier, even if the end is not actually owned by that classifier. This requires updating the doAction operations of the various structural feature action activation classes so that the actions behave like the corresponding link action if their structural feature is an association end. (Note that association ends are never classifier-owned in fUML.)

    Thus, the above quoted note in 8.6.3.1 is not correct, and it should have been removed as part of the resolution of FUML-51.

  • Reported: FUML 1.2 — Fri, 30 Dec 2016 23:42 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Remove identified note

    Agreed.

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

Prose for semantics of AddStructuralFeatureValueAction required

  • Key: FUML13-18
  • Legacy Issue Number: 19866
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    UML 2.5, section 16.8.3.3 Add Structural Feature Value Actions says:

    "The semantics are undefined for adding a value that violates the upper multiplicity of the StructuralFeature, and for
    adding a new value to a StructuralFeature with isReadonly=true after initialization of the object that would have the
    value."

    In fUML, this undefined semantics is resolved. Values are simply added to the StructuralFeature of the target object. This semantics is also described in the implementation of AddStructuralFeatureValueActionActivation.doAction() (section 8.6.3.2.1, pp. 298).

    Since this implementation represents the resolution of an undefined semantics of the UML specification, section 7.5.3.2.1 AddStructuralFeatureValueAction should add a prose description of this resolution to its "semantics" clause. It would increase the readability and comprehensibility of the spec.

  • Reported: FUML 1.2 — Thu, 3 Dec 2015 05:00 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Add note on AddStructuralFeatureValueAction

    Agreed, in principle. However, 7.5.3.2.1 in the fUML specification does not have a "semantics clause", because it is in the clause on abstract syntax, not semantics. Instead, a note should be added under "Structural Feature Actions" in 8.6.3.1, the Overview for Intermediate Actions. Also, currently, the UML specification reference still needs to be to the UML 2.4.1 Superstucture Specification.

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

Incomplete update to ClassifierBehaviorInvocationEventAccepter::invokeBehavior

  • Key: FUML13-14
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The resolution to issue FUML12-35 renames the execution model class ClassifierBehaviorExecution to ClassifierBehaviorInvocationEventAccepter, removes the classifier behavior for this class and renames the "execute" operation to "invokeBehavior". The behavior of this operation is also supposed to change from including the starting of the classifier behavior (which no longer exists) to "register[ing] this event accepter with the object activation." However, the revised text of the resolution does not include the update to the code of invokeBehavior for this change (though the change is made in the code in the corresponding normative XMI).

  • Reported: FUML 1.2 — Fri, 23 Oct 2015 13:39 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Correct ClassifierBehaviorInvocationEventAccepter::invokeBehavior

    Revise the text in the specification document to correspond to the update made in the code for this operation in the normative XMI.

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

The specification of IntegerFunctions::Div is incorrect

  • Key: FUML13-28
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Consider an application of IntegerFunctions::Div(x,y) when x > 0 but y < 0. In this case, the postcondition in the definition of the function (given in 9.3.2, Table 9.3) requires that -Div(x,y) * y <= -x < (-Div(x,y) + 1) * y. But this is impossible, because (-Div(x,y) + 1) * y < -Div(x,y) * y, since y < 0.

    The "else" expression in the postcondition should actually be:
    ((Neg(result) * Abs(y)) <= Abs(x) And ((Neg(result)+1) * Abs(y) > Abs(x)
    This would ensure that Div(x,y) = -Div(-x,y) = -Div(x,-y) = Div(-x,-y), for all values of x and y (with y <> 0).

  • Reported: FUML 1.2 — Tue, 20 Dec 2016 22:31 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Correct postcondition

    Agreed. In fact, the postcondition also doesn't work, for a similar reason, in the case that both operands are less than zero.

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

Error in RealValue::toString

  • Key: FUML13-20
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The RealValue::toString operation does not produce the correct result if the real value is equal to 1 or an exact power of 10. For example, when the value is 1, the result of the operation is 0.1E0, rather than the correct result of 0.1E1, and when the value is 10, the result is 0.1E1, rather than 0.1E2.

    The problem is that the operation is specified so that, if the positive value is greater than 1, it is divided by 10 until it is less than or equal to 1. Instead, the test should be for the positive value being greater than or equal to 1, and division by 10 should continue until the value is less than and not equal to 1.

  • Reported: FUML 1.2 — Mon, 5 Sep 2016 19:30 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Correct RealValue::toString

    Agreed.

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

"Debug" statements should be removed

  • Key: FUML13-29
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The Java code for various operations in the execution model contains at various points statements consisting of invocations of Debug::println. This is a remnant of the fUML implementation from which this code was extracted. However, since no mapping is provided for Debug::println in Annex A, all statements involving it should be removed from the specification.

  • Reported: FUML 1.2 — Tue, 20 Dec 2016 22:35 GMT
  • Disposition: Resolved — FUML 1.3
  • Disposition Summary:

    Remove "Debug" statements

    Agreed.

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

Base semantics: incorrect description of empty-output-parameter-node

  • Key: FUML13-3
  • Legacy Issue Number: 15383
  • Status: closed  
  • Source: nMeta ( 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: Resolved — FUML 1.3
  • Disposition Summary:

    Remove sentence

    Agreed.

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

Cover all ActivityNodes used in bUML

  • Key: FUML13-10
  • 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.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

Defects in Base Semantics from fUML

  • Key: FUML13-6
  • 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.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

The fUML subset should support the raising and handling of exceptions

  • Key: FUML13-5
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: nMeta ( 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 it 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.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: FUML13-2
  • Legacy Issue Number: 14979
  • Status: closed  
  • Source: nMeta ( 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

Actions outside the bUML

  • Key: FUML13-9
  • 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.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

Computer-readable version of the Base Semantics

  • Key: FUML13-7
  • 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.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

Remove unneeded inference rules from Base Semantics

  • Key: FUML13-11
  • 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.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

Base Semantics PSL version

  • Key: FUML13-8
  • 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.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

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

  • Key: FUML12-35
  • Legacy Issue Number: 19679
  • Status: closed  
  • Source: nMeta ( 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

RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value

  • Key: FUML12-23
  • Legacy Issue Number: 18721
  • Status: closed  
  • Source: LieberLieber Software ( 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

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

  • Key: FUML12-20
  • Legacy Issue Number: 18529
  • Status: closed  
  • Source: nMeta ( 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

Certain Boolean flags are not properly initialized in some cases

  • Key: FUML12-10
  • Legacy Issue Number: 18321
  • Status: closed  
  • Source: nMeta ( 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

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

  • Key: FUML12-8
  • Legacy Issue Number: 18280
  • Status: closed  
  • Source: nMeta ( 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

The OCL for CallBehaviorAction::proper_context has an error

  • Key: FUML12-60
  • Status: closed  
  • Source: nMeta ( 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

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

  • Key: FUML12-34
  • Legacy Issue Number: 19528
  • Status: closed  
  • Source: nMeta ( 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

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

RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly

  • Key: FUML12-24
  • Legacy Issue Number: 18722
  • Status: closed  
  • Source: LieberLieber Software ( 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

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

The Listener reception of Notification should have a name

  • Key: FUML12-18
  • Legacy Issue Number: 18513
  • Status: closed  
  • Source: nMeta ( 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: nMeta ( 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: nMeta ( 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

ListFunctions should have a ListConcat behavior

  • Key: FUML12-15
  • Legacy Issue Number: 18510
  • Status: closed  
  • Source: nMeta ( 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 ( 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

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

Problem with CallActionActivation: possible infinite loop in removeCallExecution()

  • Key: FUML12-36
  • Legacy Issue Number: 19130
  • Status: closed  
  • Source: LieberLieber Software ( 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

List parameters of ListFunctions should be non-unique.

  • Key: FUML12-57
  • Status: closed  
  • Source: nMeta ( 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

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

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

Objects with cyclic references cannot be converted to string representations

  • Key: FUML12-13
  • Legacy Issue Number: 18365
  • Status: closed  
  • Source: nMeta ( 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

RealValue::toString puts too many digits in the mantissa

  • Key: FUML12-12
  • Legacy Issue Number: 18364
  • Status: closed  
  • Source: nMeta ( 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: nMeta ( 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 bodyOutputLists for a loop node need to be cleared when the node fires again

  • Key: FUML12-9
  • Legacy Issue Number: 18282
  • Status: closed  
  • Source: nMeta ( 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

ReclassifyObjectAction does not preserve structural feature values

  • Key: FUML12-7
  • Legacy Issue Number: 18279
  • Status: closed  
  • Source: nMeta ( 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

The fUML subset should include central buffer nodes and data stores

  • Key: FUML12-5
  • Legacy Issue Number: 15988
  • Status: closed  
  • Source: nMeta ( 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: nMeta ( 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: nMeta ( 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 ( 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

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

The fUML subset shuold support the raising and handling of exceptions

  • Key: FUML12-6
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: nMeta ( 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

ExpansionRegionActivation isReady condition is too strong

  • Key: FUML11-22
  • Legacy Issue Number: 17298
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.4.2.3 ExpansionRegionActivation

    The specification for ExpansionRegionActivation::isReady() requires that each of the input expansion nodes for an expansion region have the same (non-zero) number of values offered to it before the expansion region can fire. In particular, this means that if an expansion region receives null tokens representing “empty collections”, then the expansion region will not fire. This may seem to be the same as having the expansion region fire and do nothing, except that, if the region does not actually fire, then it does not offer control tokens on any outgoing control flows and any node downstream of those flows will be inhibited from firing. This does not like a reasonable limiting case of expansion region semantics on “empty” collections, and, in fact, it seems to violate what would be expected from the semantics of expansion regions as described in the full UML spec.

    The requirement for all input expansion nodes to have the same number of values also seems to strong, requiring careful sizing of all expansion inputs lest the region not be able to fire. Instead, the size of the smallest input collection could be used to govern the number of executions of the body of the expansion region, to insure there are parallel inputs available from each input expansion node for each body execution.

  • Reported: FUML 1.0 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

ForkNodeActivation does not clear its tokens on termination

  • Key: FUML11-21
  • Legacy Issue Number: 17291
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.2.2.11 ForkNodeActivation

    Unlike other control nodes, a fork node actually holds forked tokens pending their acceptance by downstream nodes. Therefore, when a ForkNodeActivation terminates, it needs to clear its held tokens, similarly to an ObjectNodeActivation. It currently does not do this, which means, if it is fired repeatedly in a loop node, and not all of its held tokens are accepted on previous iterations, it will be spuriously holding extra tokens on subsequent iterations.

    Adding the following overriding method to ForkNodeActivation is sufficient, because ActivityNodeActivation::clearTokens() repeatedly withdraws held tokens until none are left, which will work even for multiply forked tokens.

    public void terminate()

    { // Remove any offered tokens and terminate. this.clearTokens(); super.terminate(); }

    // terminate

  • Reported: FUML 1.0 — Fri, 6 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

ExpansionRegionActivation does not reset its activationGroups

  • Key: FUML11-20
  • Legacy Issue Number: 17288
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)
    Subclause: 8.5.4.2.3 ExpansionRegionActivation

    ExpansionRegionActivation creates a set of activation groups that it uses to run the contents of the expansion region for each input value. However, after an ExpansionRegionActivation fires, it does not clear its activationGroups attribute. This means that, if the same activation fires again (as might happen if it is within a loop), subsequent firings add additional activation groups to the set already created in previous firings. This results in spurious extra executions of the contents of the expansion region.

    To avoid this, the statement “this.activationGroups.clear();” should be added before the loop in ExpansionRegionActivation::doStructuredActivity.

  • Reported: FUML 1.0 — Fri, 30 Mar 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error in check for enable nodes

  • Key: FUML11-19
  • Legacy Issue Number: 17282
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation

    The ActivityNodeActivationGroup::run operation checks which of the node activations in a given set are initially enabled. It does this using the checkIncomingEdges operation to check whether a node has incoming edges with a source within the given set of node activations. The checkIncomingEdges operation in turn uses the ActivityNodeActivation::sourceFor operation to check if an activity node activation is the source for a given activity edge instance. By default, this is true if the activity node activation is the source of the activity edge instance. The sourceFor operation is overridden in ActionActivation to account for the fact that outgoing control flows are attached to an ActionActivation via an anonymous fork node but, otherwise, the default behavior is used.

    With the current specification for sourceFor, if a node activation has an incoming edge instance from within a structured activity node activation, rather than from the structured activity node itself, the structured activity node activation will not be considered the source for the edge instance, and the current specification for checkIncomingEdges does not look for sources inside structured activity nodes. This means that, if an activity node only has incoming edges with sources nested within a structured activity node, it may be spuriously considered to be enabled when it really has predecessor dependencies.

  • Reported: FUML 1.0 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Structural Feature Actions on Data Values Need to Create a new Result Value

  • Key: FUML11-18
  • Legacy Issue Number: 17270
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclauses: 8.6.3.2.1 AddStructuralFeatureValueActionActivation, 8.6.3.2.3 ClearStructuralFeatureActionActivation, 8.6.3.2.12 RemoveStructuralFeatureValueAction

    Data values are not mutable, so, when given a data value, the structural feature actions are supposed to produce a new data value on the result pin, with the same feature values as for the input data value except for the structural feature on which the action acts. However, the current specifications for the activations of these actions do not copy the value before modifying it, resulting in an incorrect “in place” modification of the feature value of the original data value.

  • Reported: FUML 1.0 — Fri, 23 Mar 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

ActionActivation.sendOffers(): Missing sending of offers on outgoing control flows?

  • Key: FUML11-17
  • Legacy Issue Number: 17213
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    It seems that in ActionActivation.sendOffers(), a loop for sending a control token on outgoing edges is missing. The code should probably be completed with something like:

    // *** Send offers on all outgoing edges concurrently. ***

    ActivityEdgeInstanceList outgoingEdges = this.outgoingEdges;

    for (Iterator i = outgoingEdges.iterator(); i.hasNext()

    { ActivityEdgeInstance outgoingEdge = (ActivityEdgeInstance)i.next(); TokenList tokens = new TokenList(); tokens.addValue(new ControlToken()); outgoingEdge.sendOffer(tokens); }
  • Reported: FUML 1.0 — Thu, 8 Mar 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor

  • Key: FUML11-16
  • Legacy Issue Number: 17211
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

    Subclause: 8.2.3.2.1 ExecutionFactoryL2

    The code listed under operation [1] instantiateVisitor for class ExecutionFactoryL2 accidentally duplicates code from ExecutionFactoryL3.instantiateVisitor. The code of ExecutionFactoryL2.instantiateVisitor should be modified to properly cover L2 elements.

  • Reported: FUML 1.0 — Tue, 6 Mar 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error handling creation and destruction of links of associations with ordered ends

  • Key: FUML11-15
  • Legacy Issue Number: 17209
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

    Subclause: 8.3.2.2.11 Link

    The behavior of the Link::setFeatureValue operation results in the FeatureValues for an ordered end to be totally ordered by “position” across all links of an association. However, when a new link is created, the insertAt position for an ordered end isn’t relative to all links but only relative to links for which the other ends have the same values as the link being created. This means that the FeatureValues of the ordered ends of the new link may not be inserted at the correct position.

  • Reported: FUML 1.0 — Sat, 3 Mar 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error in ActivityNodeActivationGroup::getOutputParameterNodeActivations

  • Key: FUML11-14
  • Legacy Issue Number: 17205
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.2.2.5 ActivityNodeActivationGroup

    The ActivityNodeActivationGroup::getOutputParameterNodeActivations operation is supposed to return the output ActivityParameterNodeActivations for an Activity. As currently specified, it finds all the ActivityParameterNodes for parameters with direction inout, out and return. However, inout parameters actually have two ActivityParameterNodes: one for input and one for output. The current specification results in the operation incorrectly returning both the input and output nodes for an inout parameter.

    The UML well-formedness constraints require that an input ActivityParameterNode only have outgoing edges and that and output ActivityParameterNode only have incoming edges. Therefore, instead of checking the parameter to determine output nodes, getOutputParameterNodeActivations should instead check whether the node activation has incoming edges.

  • Reported: FUML 1.0 — Wed, 29 Feb 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Bug in ForkedToken::withdraw when the baseToken is a ForkedToken

  • Key: FUML11-13
  • Legacy Issue Number: 17203
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.2.2.10 ForkedToken

    ForkedToken::withdraw calls isWithdrawn() to check if its baseToken is withdrawn, and then withdraws it if that is false. The intent is that baseToken.withdraw() only be called once. However, if the baseToken is itself a ForkedToken, then calling withdraw() may only decrement the remainingOffersCount of that token, with isWithdrawn() only becoming true if this count goes to zero. This means that additional calls to withdraw() on the first ForkedToken may result in additional calls to withdraw() on its baseToken, prematurely reducing the remainingOffersCount for the baseToken.

    This can be avoided by adding an explicit baseTokenIsWithdrawn flag to ForkedToken that is set when the baseToken is withdrawn and then checked to avoid further withdraws.

  • Reported: FUML 1.0 — Tue, 28 Feb 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Bug in DestroyObjectActivation::objectIsComposite

  • Key: FUML11-12
  • Legacy Issue Number: 17201
  • Status: closed  
  • Source: University of Innsbruck ( Hannes Moesl)
  • Summary:

    Destroying an object (with "isDestroyLinks" = true) can potentially result in an infinite loop, since the loop variable "i" is never incremented.

    Solution:
    while (!isComposite & i <= linkFeatureValues.size()) {
    FeatureValue featureValue = linkFeatureValues.getValue(i-1);
    if (!featureValue.values.getValue(0).equals(reference) &
    ((Property)featureValue.feature).aggregation == AggregationKind.composite)

    { isComposite = true; }

    i = i + 1;
    }

  • Reported: FUML 1.0 — Tue, 28 Feb 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error in RemoveStructuralFeatureVauleActionActivation::doAction

  • Key: FUML11-11
  • Legacy Issue Number: 17200
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0

    Subclause: 8.6.3.2.12 RemoveStructuralFeatureValueActionActivation

    The following conditional appears toward the end of the specification of the RemoveStructuralFeatureValueActionActivation::doAction() operation:

    if (featureValue.values.size() <= removeAt)

    { featureValue.values.remove(removeAt - 1); }

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

  • Reported: FUML 1.0 — Sat, 25 Feb 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Spurious comment on operation PinActivation::fire

  • Key: FUML11-10
  • Legacy Issue Number: 17168
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/11-02-01)

    Subclause: 8.6.2.2.8 PinActivation

    The operation PinActivation::fire includes the comment “[Note that a pin will consume all tokens offered to it, even if this is more than the multiplicity upper bound, but will only offer tokens up to that upper bound.]” However, this is not true in fUML as finalized. The incoming tokens passed to the fire operation are determined using the takeOfferedTokens operation, which is defined to “Take only a number of tokens only up to the limit allowed by the multiplicity upper bound of the pin for this activation.”

  • Reported: FUML 1.0 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error in DecisionNodeActivation semantics

  • Key: FUML11-9
  • Legacy Issue Number: 16948
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    : Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

    Subclause: 8.5.2.2.9 DecisionNodeActivation

    In the method for the DecisionNodeActivation::getDecisionInputFlowValue operation contains the statement:

    value = ((ObjectToken)(tokens.getValue(0))).value;

    Since a decision input flow must be an object flow, it would seem reasonable to be able to assume that this flow would only contain ObjectTokens. However, all tokens offered by ForkNodeActivations are wrapped in ForkTokens, which is directly a subclass of Token. If such a token is offered on a decision input flow, then the above cast will fail.

    To fix this, the above statement should be replaced with:

    value = tokens.getValue(0).getValue();

    The getValue operation is defined for all types of tokens (it returns null for control tokens, but that would not be an issue here).

  • Reported: FUML 1.0 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Duplicate code for ActionActivation::putToken

  • Key: FUML11-8
  • Legacy Issue Number: 16687
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

    Subclause: 8.6.2.2.1 ActionActivation

    The code listed under operation [12] PutToken for class ActionActivation is accidentally duplicated. The lines starting with the second set of comments to the end should be deleted.

  • Reported: FUML 1.0 — Tue, 15 Nov 2011 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Error in CreateLinkAction semantics

  • Key: FUML11-7
  • Legacy Issue Number: 16686
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

    Subclause: 8.6.3.x CreateLinkActionActivation

    In Subclause 8.6.3.1 (Overview), under “Link Actions”, it says for a Create Link Action that “if a link already exists in the association extent with the same tuple of values, and all the ends of the association are specified as unique, then no new link is actually created (though this is not an error).” However, the specification for CreateLinkActionActivation::doAction in Subclause 8.6.3.2.4 always creates a new link even if an identical link already exists (unless isReplaceAll=true for one of the ends), regardless of whether the ends of the association are all unique.

  • Reported: FUML 1.0 — Mon, 14 Nov 2011 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Error in ExpansionRegionActivation::takeOfferedTokens

  • Key: FUML11-6
  • Legacy Issue Number: 16654
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundation Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-01)

    Subclause: 8.5.4.2.3 ExpansionRegionActivation

    In the ExpansionRegionActivation class, operation [8] takeOfferedTokens is missing an initial call to super.takeOfferedTokens(). This means that, when an expansion region activation fires, it does not properly handle tokens on control flows incoming to the expansion region, nor does it fire any input pin activations for the region, both of which should be handled as usual for an action. Because of this, the subsequent copying of input tokens from input pin activations in ExpansionRegionActivation never actually produces any tokens, even though some may have been offered to the input pins.

  • Reported: FUML 1.0 — Mon, 7 Nov 2011 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

The fUML Foundational Model Library should support the new UML 2.4 Real primitive type

  • Key: FUML11-5
  • Legacy Issue Number: 15987
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

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

    UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library.

  • Reported: FUML 1.0 — Wed, 26 Jan 2011 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Addition to the resolution to fUML Issue 17499

  • Key: FUML11-39
  • Legacy Issue Number: 17560
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The resolution to Issue 17499 (Conditional node and loop node activations do not wait for contained accept event action activations) removes some lines from the specification for the operation ConditionalNodeActivation::doStructuredActivity. However, it neglects to state to remove the final line “this.activationGroup.terminateAll();”, which also needs to be removed.

  • Reported: FUML 1.0 — Tue, 21 Aug 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Correction to the resolution to fUML Issue 17209

  • Key: FUML11-38
  • Legacy Issue Number: 17559
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The Revised Text instructions in the resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) includes the statement “Remove the (overriding) operation getFeatureValue.” However, Link does not have an overriding getFeatureValue operation. The correct instruction is to remove the setFeatureValue operation.

  • Reported: FUML 1.0 — Tue, 21 Aug 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Addition to the resolution of fUML Issue 17203

  • Key: FUML11-37
  • Legacy Issue Number: 17558
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The resolution to Issue 17203 (Bug in ForkedToken::withdraw when the baseToken is a ForkedToken) adds a Boolean baseTokenIsWithdrawn attribute to the ForkedToken class. However, since bUML (like fUML) does not support default values on attributes, this attribute needs to be explicitly set to false when a ForkedToken is created in ForkedNodeActivation::fire(). The resolution neglects to include this revision.

  • Reported: FUML 1.0 — Tue, 21 Aug 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Addition to the resolution to fUML Issue 15987

  • Key: FUML11-36
  • Legacy Issue Number: 17557
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The resolution to Issue 15987 (The fUML Foundational Model Library should support the new UML 2.4 Real primitive type) adds LiteralReal and LiteralRealEvaluations class, but neglects to update the ExecutionFactoryL1::instantiateVisitor operation to instatiate an instance of the latter class when given an instance of the former.

  • Reported: FUML 1.0 — Tue, 21 Aug 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A

  • Key: FUML11-35
  • Legacy Issue Number: 17502
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)

    Subclause: 8.4.3.2.1 ClassifierBehaviorExecution, 8.4.3.2.5 ObjectActivation

    Subclause A.3.7 establishes the Java notation “_startObjectBehavior();” as mapping to a start object behavior action, not an operation call, and it also states that “A class may not define a user operation called ‘_startObjectBehavior.’” However, in Subclause 8.4.3.1, Figure 8.17, _startObjectBehavior is shown as an operation on both ClassifierBehaviorExecution and ObjectActivation, and it is specified in as an operation for these classes in Subclauses 8.4.3.2.1 and 8.4.3.2.5.

    Subclause A.3.8 establishes the Java notation “_send(new <signal>());” as mapping to a send signal action, not an operation call. However, in Figure 8.17, _send is shown as an operation of ObjectActivation, and it is specified as an operation in Subclause 8.4.3.2.5.

  • Reported: FUML 1.0 — Mon, 16 Jul 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Conditional node and loop node activations do not wait for contained accept event action activations

  • Key: FUML11-34
  • Legacy Issue Number: 17499
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclauses: 8.5.3.2.2 ConditionalNodeActivation, 8.5.3.2.3 LoopNodeActivation, 8.5.4.2.3 ExpansionRegionActivation

    The resolution to Issue 17314 (Structured activity node activations do not wait for contained accept event action activations), on adopted on Ballot 2 of the fUML 1.1 RTF, works for plain structured activity nodes, but it does not work for structured activity nodes that are conditional nodes, loop nodes or expansion regions. For conditional nodes, the resumption of suspension of the node must take place in the context of a specific conditional clause. For loop nodes, resumption must allow continued iteration of the loop, rather than just completion of the node activation. For expansion regions, resumption must take place in the context of a specific expansion activation group.

  • Reported: FUML 1.0 — Fri, 13 Jul 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    Agreed.

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

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

Null tokens are not sent on by control nodes

  • Key: FUML11-33
  • Legacy Issue Number: 17397
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.5.2.2.15 ObjectNodeActivation

    When an object node has no tokens, ObjectNodeActivation::sendOffers creates a null token to send. However, the holder attribute of this token is not set. This means that, even though the token gets offered, when a node tries to take it from the offering edge instance, the token is considered to have been withdrawn and is not passed on to the token. The effect of this is, in particular, that control node activations will never pass on null tokens, which is incorrect.

    To avoid this, sendOffers should set the holder of the null token to be the object node sending it.

  • Reported: FUML 1.0 — Mon, 28 May 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Errors in ReduceActionActivation::doAction

  • Key: FUML11-32
  • Legacy Issue Number: 17396
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.6.4.2.6 ReduceActionActivation

    The specification for ReduceActionActivation::doAction has a number of errors.

    1. The test “input1 != null” should be “input1 == null”.

    2. The test for “parameter.direction == ParameterDirectionKind.out” should also test for a parameter direction of return.

    3. After the execution of the reducer behavior, parameterValue1 should not be set to the resulting ParameterValue. Instead, only parameterValue1.values should be set to the resulting values (parameterValue1.parameter should remain unchanged as being equal to input1).

    4. There is no abstract syntax constraint that the output of the reducer cannot be empty. The semantics for a reduce action should take into account the possibility of the reducer returning no value and not try to feed an empty input into the next reducer call.

  • Reported: FUML 1.0 — Fri, 25 May 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Addition to resolution to Issue 17299

  • Key: FUML11-31
  • Legacy Issue Number: 17392
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.5.2.2.3 ActivityFinalNodeActivation

    The resolution to Issue 17299 did not take into account, in the revision to ActivityFinalNodeActivation::fire, that the group for the ActivityFinalNodeActivation may be an ExpansionActivationGroup, which has a regionActivation property set instead of containingNodeActivation.

  • Reported: FUML 1.0 — Wed, 23 May 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

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

Error in setting result pin values for CallActions

  • Key: FUML11-30
  • Legacy Issue Number: 17391
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.6.2.2.2 CallActionActivation

    At the end of CallActionActivation::doAction, the output parameter values from the call execution are placed on the result output pins of the call action. However, the current specification presumes that the parameter values from the execution will be in the same order as the output parameters (and output pins). But this will not always be the case.

    For example, if a parameter is an inout parameter, then it will have a parameter value added to the execution with its input before the execution is executed. It’s output will then be written to this existing output parameter value, while parameter values for out parameters will be created ordered after the one for the inout parameter, even if the out parameters are ordered before the inout parameter. Thus, the wrong values will be copied to the output pins.

    Instead of relying on ordering, the specification for doAction should us the parameter reference for each output parameter value to identify the correct result output pin to which the parameter value should be written.

  • Reported: FUML 1.0 — Wed, 23 May 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Read link actions and read structural feature actions do not handle ordered ends correctly

  • Key: FUML11-29
  • Legacy Issue Number: 17346
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.6.3.2.9 ReadLinkActionActivation, 8.6.3.2.13 StructuralFeatureActionActivation

    Read link actions and read structural feature actions do not always return the values for an ordered association end in the correct order. In ReadLinkActionActivation::doAction, after the loop searching for the position at which to insert a featureValue, the statement

    featureValues.addValue(k-1, featureValue);

    should be replaced with

    if (continueSearching)

    { featureValue.addValue(featureValue); }

    else

    { featureValue.addValue(k-1, featureValue); }

    in order to correctly handle the case in which the featureValue should be added at the end of the list.

    There is a similar statement in StructuralFeatureActionActivation::getMatchingLinks to insert a link at the correct position in the list of matching links, and it should be replaced in a similar manner to the above.

  • Reported: FUML 1.0 — Sun, 29 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Correction to the resolution of Issue 17209

  • Key: FUML11-28
  • Legacy Issue Number: 17345
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0 (formal/2011-02-02)
    Subclause: 8.3.2.2.11 Link

    The resolution to Issue 17209 (Error handling creation and destruction of links of associations with ordered ends) included the addition of an addTo operation to the Link class. The specification of this new operation contains the statement:

    FeatureValue otherFeatureValue = featureValues.getValue(j);

    This should, instead, have been:

    FeatureValue otherFeatureValue = otherFeatureValues.getValue(j);

    Also, the resolution didn’t not the need to update Figure 8.12 to reflect the addition to Link of the operations isMatchingLink, getOtherFeatureValues and addTo, and the removal of the operation getFeatureValue.

  • Reported: FUML 1.0 — Sun, 29 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

Structured activity node activations do not wait for contained accept event action activations

  • Key: FUML11-27
  • Legacy Issue Number: 17314
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)
    Subclauses: 8.5.2.2.5 ActivityNodeActivationGroup, 8.5.3.2.4 StructuredActivityNodeActivation, 8.6.4.2.1 AcceptEvent ActionActivation

    When a structured activity node contains one or more accept even actions, then, when those actions are waiting for the reception of event occurrences, one would expect that the structured activity node as a whole would also be waiting, pending the triggering of the actions. As currently specified, when accept event action activation registers to wait for event dispatching, it is not considered to be complete. Nevertheless, once all such actions have registered, and all other contained in a structured activity node have completed, the running of the node activations in the activation group for the structured node finishes, and the structured activity node activation completes, allowing execution to continue to subsequent nodes. This is not correct; the structured activity node activation should essentially be suspended until all the accept event actions activations have actually completed.

  • Reported: FUML 1.0 — Mon, 16 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

    agreed

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

DecisionNodeActivation can send offers to multiple outgoing edges

  • Key: FUML11-26
  • Legacy Issue Number: 17312
  • Status: closed  
  • Source: LieberLieber Software ( Tanja Mayerhofer)
  • Summary:

    In the method DecisionNodeActivation.fire(TokenList), a token offer is sent to each outgoing edge for which the guard evaluates to true resulting in the execution of multiple successor nodes.
    Only one successor node should receive an offer also if the guards of several outgoing edges evaluate to true.

  • Reported: FUML 1.0 — Mon, 16 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

Having a fork node as initial enabled node does not work

  • Key: FUML11-25
  • Legacy Issue Number: 17311
  • Status: closed  
  • Source: LieberLieber Software ( Tanja Mayerhofer)
  • Summary:

    If a fork node is identified as initial enabled node in the method ActivityNodeActivationGroup.run(ActivityNodeActivationList), and the method ActivityNodeActivation.receiveOffer() is called for the ForkNodeActivation, the method ForkNodeActivation.fire(TokenList) does not produce any forked tokens (because there is no real incoming token for the fork node) and because of this, the method call this.sendOffers(forkedTokens) (last statement of the method ForkNodeActivationActivation.fire(TokenList)) does not result in offers sent to successor nodes but this should be possible.

  • Reported: FUML 1.0 — Mon, 16 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

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

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

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

    Revised Text:
    None.
    Disposition: Closed, No Change

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

An activity final node should not fire if it is not offered any tokens

  • Key: FUML11-24
  • Legacy Issue Number: 17300
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.2.2.3 ActivityFinalNodeActivation

    ActivityFinalNodeActivation::fire(incomingTokens) currently terminates the activity node activation group containing the activity final node, even if incomingTokens is empty. This is normally not a problem, since fire is usually only called if at least one token has been offered. However, if the activity final node is in a loop node or a conditional clause with an incoming edge from the body of the loop node or clause, then, when the test for the loop node or clause is being executed, the body part is not yet activated. If the source of the incoming edge to the activity final node is a body part node that is not activated, then the edge will be ignored in determining whether the final node is enabled, resulting in the final node being considered enabled and, unless otherwise prevented, firing prematurely, terminating the enclosing loop node or conditional node.

  • Reported: FUML 1.0 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

LoopNodeActivation does not properly handle termination due to an activity final node

  • Key: FUML11-23
  • Legacy Issue Number: 17299
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Specification: Semantics of a Foundational Subset for Executable UML Models (fUML) (formal/2011-02-01)

    Subclause: 8.5.3.2.3 LoopNodeActivation

    If an activity final node directly owned by a loop node fires, then the loop node should terminate. However, the loop node should still produce values on its output pins based on any computations that have happened so far. Currently, when such an activity final node fires, the enclosing loop node is indeed immediately terminated via a call to its terminate(), but this does not actually terminate the loop in LoopNodeActivation::doStructuredActivity(). That loop only terminates once the test part of the loop executes, producing a null value (since all its nodes will no longer be running), which is interpreted as false. Further, the prior call to terminate() removes all tokens from the output pins in the body part of the loop, meaning that they are no longer available to be moved to the output pins of the loop node. As a result, the loop node produces no output, even if outputs have been computed prior to the firing of the final node.

  • Reported: FUML 1.0 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

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

fUML 1.1 should be based on UML 2.4

  • Key: FUML11-4
  • Legacy Issue Number: 15986
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

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

    Foundational UML (fUML) 1.0 as finalized is based on UML 2.3. With the completion of the UML 2.4 RTF, fUML should be moved to UML 2.4. This would be consistent with the recently adopted Alf action language specification, which will be finalized based on UML 2.4.

    Fortunately, nothing seems to have changed in UML 2.4 that would substantively effect the specification of the fUML abstract syntax subset. However, the fUML normative XMI should be regenerated consistent with UML 2.4/XMI 2.4. Further, UML 2.4 has separated the primitive type model into a separate XMI file with normative XMI IDs, and these should be used for referencing those types in the normative XMI for the fUML Foundational Model Library.

  • Reported: FUML 1.0 — Wed, 26 Jan 2011 05:00 GMT
  • Disposition: Resolved — FUML 1.1
  • Disposition Summary:

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

  • 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: nMeta ( 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

Flow final nodes should be included

  • Key: FUML11-2
  • Legacy Issue Number: 14526
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

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

    Flow final nodes are currently excluded from the fUML subset. However, such nodes can be useful to explicitly consume tokens without terminating an activity. Since their semantics would be very easy to add to the execution model, it should be considered to add them to the fUML subset

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

    Agreed.

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

7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add

  • Key: FUML11-1
  • Legacy Issue Number: 13872
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

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

    Section: 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add

    Summary:

    The fUML execution engine in clause 8 and the fUML reference implementation [1] are both written according to the Java => bUML mapping specified in appendix A of the fUML specification.

    Unfortunately, this Java => bUML mapping does not take into account the different kinds of containers used fUML because the ListAdd operation (A.5.2) is defined to be the Java equivalent of fUML AddStructuralFeature Value

    {isReplaceAll=false}

    .

    This creates a problem in several places where fUML class attributes are defined to be unique; in particular:

    7.4.2.2.2 ActivityEdge::source

    {unique}

    7.4.2.2.2 ActivityEdge::target {unique}

    7.4.2.2.4 ActivityNode::incoming

    {unique}

    7.4.2.2.4 ActivityNode::outgoing {unique}

    The fUML reference implementation [1] loads an fUML model by CMOF reflection.

    This means that it processes each activity edge in three parts:

    1. The activity node at the source of the edge

    2. The activity node at the target of the edge

    3. The edge itself

    #1 and #3 lead to a duplication of the same edge on the outgoing list of the source node.

    #2 and #3 lead to a duplication of the same edge on the incoming list of the target node.

    [1] http://portal.modeldriven.org/content/foundational-uml-reference-implementation

    Proposed resolution:

    The fUML specification should update the Java => bUML mapping to account for the different kinds of containers used for fUML.

    The fUML reference implementation should be updated according to the revised Java => bUML mapping for collections.

    A workaround to this issue for the reference implementation in [1] involves modifying fUML.Syntax.Activities.IntermediateActivities.ActivityEdge as follows:

    public void setTarget(fUML.Syntax.Activities.IntermediateActivities.ActivityNode target) {

    this.target = target;

    /**

    • NFR 04/15/2009
    • Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI,
    • it turns out that activity edges get a duplication of their source pins because:
    • - once by reflection when creating the ActivityNode whose .incoming edges includes this instance.
    • - a second time this ActivityEdge is constructed by reflection.

    */

    if (!target.incoming.contains(this))

    { target.incoming.addValue(this); }

    else

    { Debug.println("ActivityEdge[" + this.name + "].setTarget(target) this edge is already included in the incoming edge list for target: " + target.getClass().getCanonicalName()+"[" + target.name + "]"); }

    }

    public void setSource(fUML.Syntax.Activities.IntermediateActivities.ActivityNode source) {

    this.source = source;

    /**

    • NFR 04/15/2009
    • Because the reference implementation "constructs" the fUML.Syntax model by reflection from the XMI,
    • it turns out that activity edges get a duplication of their source pins because:
    • - once by reflection when creating the ActivityNode whose .outgoing edges includes this instance.
    • - a second time this ActivityEdge is constructed by reflection.

    */

    if (! source.outgoing.contains(this))

    { source.outgoing.addValue(this); }

    else

    { Debug.println("ActivityEdge[" + this.name + "].setSource(target) this edge is already included in the outgoing edge list for target: " + source.getClass().getCanonicalName()+"[" + source.name + "]"); }

    }

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

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

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