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

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

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

Issues Summary

Key Issue Reported Fixed Disposition Status
FUML15-2 The fUML subset should support the raising and handling of exceptions FUML 1.0 FUML 1.5 Resolved closed
FUML15-1 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.5 Closed; No Change closed
FUML14-1 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.4 Deferred closed
FUML14-2 The fUML subset should support the raising and handling of exceptions FUML 1.0 FUML 1.4 Deferred closed
FUML13-4 The fUML subset should include central buffer nodes and data stores FUML 1.0 FUML 1.3 Resolved closed
FUML13-1 SendSignalAction completion semantics FUML 1.0b1 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-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
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-21 ReclassifyObjectAction handles removal of structural features incorrect FUML 1.0 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-7 ReclassifyObjectAction does not preserve structural feature values FUML 1.0 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-3 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.2 Deferred 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-1 Section: Base Semantics FUML 1.0b1 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
FUML-55 Reference Menzel in Section 10 FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML_-8 Corrections to previous resolutions FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-6 Error in ObjectActivation::dispatchNextEvent FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-7 Additional changes required for action firing semantics FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-5 Modification to AcceptEventActionActivation FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-1 Values passed out to pins from empty parameter nodes FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-2 UML input pins do not accept more tokens than their actions can immediately consume FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-4 Additional changes required for structured activity node execution FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-3 Diagram graphics in the fUML specification FUML 1.0b2 FUML 1.0 Resolved closed
UML25-674 TestIdentityAction for datatypes FUML 1.0b2 UML 2.5 Resolved closed
UML24-33 Expansion nodes using all the tokens in them as a single collection FUML 1.0b2 UML 2.4 Resolved closed
FUML-53 Attributes introduced in CompleteActivities should not be included in the fUML subset FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-54 ObjectNodeActivation::unofferedTokens is spurious FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-52 ObjectNodeOrderingKind should be in Activities::IntermediateActivities FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-51 Revise fUML to be based on UML 2.3 FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-50 Structured activity node execution model needs to be corrected FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-48 Include activity diagrams for classifier behaviors FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-49 Variable needs initialization in InputPinActivation::receiveOffer FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-46 Problems with OCL for AcceptEventAction::fUML_active_context FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-47 References to uml::Class in OCL FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-45 OCL for SendSignalAction::target_signal_reception is incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-44 OCL incomplete for CallBehaviorAction::proper_context FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-43 Pin should be abstract FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-42 The composition from ObjectNode to TypedElement is incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-41 InstanceValue constraint is redundant FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-40 Incorrect generalizations in Kernel FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-39 Items excluded from Kernel FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-35 Active class should not have to have classifier behaviors FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-38 OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-36 A passive class should not be able to specialize an active class FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-37 A data type should not be allowed to have operations FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-34 Base Semantics FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-33 The superclass of ActvityNode and ActivityEdge should be RedefinableElement FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-32 Receptions should never be abstract FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-31 Only abstract classes should be able to have abstract behavioral features FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-30 Subclause: 8.5.2.2.6 ActivityParameterNodeActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-25 7.5.2.2.9 SendSignalAction FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-26 [FUML] 8.6.3.2.4 CreateLinkActionActivation.doAction() FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-27 8.6.4.2.1 [5]AcceptEventActionActivation::accept(in signalInstance:SignalInstance) FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-29 8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-24 [FUML] 7.4.2.2.14 ObjectFlow FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-28 Error in ReadLinkActionActivation FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-23 Event should be a specialization of PackageableElement FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-22 LoopNodeActivation::doStructuredActivity uses a Java array FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-21 ActionActivation::isSourceFor does not initialize a local variable FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-20 UnlimitedNaturalValue::toString does not follow Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-18 IntegerValue::toString uses Java String.valueOf FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-15 EnumerationValue::specify missing a "this" FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-17 InstanceValueEvaluation::evaluate does not initialize local variables FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-14 CompoundValue::equals does not conform to Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-16 FeatureValue::hasEqualValues does not follow Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-13 BooleanValue::toString uses Java String.valueOf FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-12 ExecutionFactory::getStrategy doesn't follow conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-19 Link::getTypes does not initialize a local variable FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-10 Error in return value of ActivityNodeActivation::removeToken FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-11 ExecutionFactory::instantiateVisitor should not use Java reflection FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-8 Issue: The result pin of clear and write structural feature actions can be optional FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-9 Issue: Bug in ReclassifyObjectActionActivation::doAction FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-7 Issue: CallActionActivation cannot handle more than one concurrent call FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-5 The call to receiveOffer at the end of ActionActivation::fire could can cause an infinite recursion FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-4 An action can consume more tokens from a pin than the allowed multiplicity upper bound FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-6 Issue: ObjectNodeActivation::offeredTokenCount is not initialized FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-2 Issue: ActivityNodeActivation::clearTokens incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-3 Issue: InitialNodeActivation::fire should use sendOffers FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-1 Issue: Sending offers from ForkNodeActivation::fire FUML 1.0b1 FUML 1.0b2 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-33 Null tokens are not sent on by control nodes 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-36 Addition to the resolution to fUML Issue 15987 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-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-37 Addition to the resolution of fUML Issue 17203 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-30 Error in setting result pin values for CallActions 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-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-29 Read link actions and read structural feature actions do not handle ordered ends correctly 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-21 ForkNodeActivation does not clear its tokens on termination 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-22 ExpansionRegionActivation isReady condition is too strong 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-18 Structural Feature Actions on Data Values Need to Create a new Result Value 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-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-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-12 Bug in DestroyObjectActivation::objectIsComposite 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-10 Spurious comment on operation PinActivation::fire FUML 1.0 FUML 1.1 Resolved closed
FUML11-11 Error in RemoveStructuralFeatureVauleActionActivation::doAction FUML 1.0 FUML 1.1 Resolved closed
FUML11-7 Error in CreateLinkAction 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-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-9 Error in DecisionNodeActivation semantics 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-4 fUML 1.1 should be based on UML 2.4 FUML 1.0 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

The fUML subset should support the raising and handling of exceptions

  • Key: FUML15-2
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: Model Driven Solutions ( 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: Resolved — FUML 1.5
  • Disposition Summary:

    Add exception handling

    The request to include exceptions in the fUML subset is one of the oldest that has not been resolved. As noted in the issue description, it was originally submitted against the FTF beta version of the fUML specification. Since then, the lack of support for exceptions has continued to be an impediment, particularly when using fUML for executable modeling for software. This lack often results in the use of poor workarounds, such as using "null" to represent an undefined or erroneous value, or other such "flagging" mechanisms – just the kind of things that exceptions were invented to avoid.

    Further, exceptions are now also needed in fUML to support the proposed precise semantics SysML 1.7 (see https://issues.omg.org/browse/SYSML17-237), which will include an option in which constraint failure causes an exception to be raised. It is not considered feasible to add exception handling as just an extension for SysML 1.7 semantics.

    And it turns out that adding exception handling to fUML is fairly straightforward, primarily just requiring a way to record the propagation of an exception up the call chain and new semantics for exception handlers. Specifically, this involves the following updates.

    7. Abstract Syntax
    7.5 Classification

    • Add BehavioralFeature::raisedException. (Note that the UML specification does not give any formal constraints that would actually prevent the raising of exceptions not declared in the raisedException list. However, its inclusion would allow a tool to potentially do optional static checking for unexpected exception raising.)
    • Add Operation::raisedException. (This is just a redefinition of BehavioralFeature::raisedException.)

    7.10 Activities

    • Add ExceptionHandler.

    7.11 Actions

    • Add RaiseExceptionAction.

    8. Execution Model
    8.3 Loci

    • Update ExecutionFactory to add instantiation of RaiseExceptionActionActivation as the semantic visitor for RaiseExceptionAction.

    8.8 Common Behavior

    • Update Execution with semantics to propagate an exception raised during execution.

    8.9 Activities

    • Add (abstract) ExecutableNodeActivation with semantics for handling exceptions.

    8.10 Actions

    • Update ActionActivation with action-specific semantics for handling an exception.
    • Update CallActionActivation with semantics for propagating an exception raised by the call execution.
    • Add RaiseExceptionActionActivation with the semantics for raising an exception.
  • Updated: Fri, 18 Sep 2020 17:03 GMT
  • Attachments:

Annex on normative XMI for fUML

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

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

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

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

    Annex is no longer necessary

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

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

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

Annex on normative XMI for fUML

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

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

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

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

    Defer

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

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

The fUML subset should support the raising and handling of exceptions

  • Key: FUML14-2
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: Model Driven Solutions ( 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.4
  • Disposition Summary:

    Defer

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

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

The fUML subset should include central buffer nodes and data stores

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

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:

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

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

The fUML subset should support the raising and handling of exceptions

  • Key: FUML13-5
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: Model Driven Solutions ( 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: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

    Defer

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

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

Certain Boolean flags are not properly initialized in some cases

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

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

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

ReclassifyObjectAction does not preserve structural feature values

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

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

Annex on normative XMI for fUML

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

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

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

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

    Defer

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

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

The fUML subset should include central buffer nodes and data stores

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

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

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

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

    Defer

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

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

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

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

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

The fUML subset shuold support the raising and handling of exceptions

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


Corrections to previous resolutions

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

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

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

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

    Agreed.

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

Error in ObjectActivation::dispatchNextEvent

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

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.4.3.2.5 ObjectActivation

    In the operation ObjectActivation::dispatchNextEvent, the line

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

    should be:

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

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

    Agreed.

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

Additional changes required for action firing semantics

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

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.6.2.2.1 ActionActivation

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

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

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

    Agreed.

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

Modification to AcceptEventActionActivation

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

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.6.4.2.1 AcceptEventActionActivation

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

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

    Agreed.

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

Values passed out to pins from empty parameter nodes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Additional changes required for structured activity node execution

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

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 8.5.2.2.5 ActivityNodeActivationGroup

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

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

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

    int j = 1;

    boolean notFound = true;

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

    int k = 1;

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

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

    { notFound = false; }

    k = k + 1;

    }

    j = j + 1;

    }

    return notFound;

    In the operation Run, replace the code:

    ActivityEdgeInstanceList incomingEdges = activation.incomingEdges;

    boolean isEnabled;

    if (activation instanceof ActionActivation)

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

    else

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

    int j = 1;

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

    int k = 1;

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

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

    { isEnabled = false; }

    k = k + 1;

    }

    j = j + 1;

    }

    if (isEnabled)

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

    }

    With:

    if (activation instanceof ActionActivation |

    activation instanceof ControlNodeActivation |

    activation instanceof ActivityParameterNodeActivation) {

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

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

    if (isEnabled & activation instanceof ActionActivation) {

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

    int j = 1;

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

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

    }

    if (isEnabled)

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

    }

    }

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

    Agreed.

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

Diagram graphics in the fUML specification

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

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

    All the abstract syntax diagrams in the spec should:

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

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

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

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

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

TestIdentityAction for datatypes

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

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

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

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

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

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

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

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

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

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on ExpansionRegion to
    indicate whether the individual tokens of the input and out expansion
    nodes are taken as collections, or whether all the tokens in the nodes
    are taken as one collection. In ExecUML this attribute value would
    always be for the second option.

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

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

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

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

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

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

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

    Activity::isSingleExecution

    ObjectFlow::isMulticast

    ObjectFlow::isMultiReceive

    ObjectNode::ordering

    ObjectNode::isControlType

    Pin::isControl

    JoinNode::isCombineDuplicate

    Parameter::isException

    Parameter::isStream

    Parameter::effect

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

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

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

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

ObjectNodeActivation::unofferedTokens is spurious

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

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

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

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

    The association should be removed.

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

ObjectNodeOrderingKind should be in Activities::IntermediateActivities

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

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

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

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

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

    Revised Text:
    None.
    Disposition: Duplicate/merged

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

Revise fUML to be based on UML 2.3

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

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

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

    Relevant semantic issues include, in particular:

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

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

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

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

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

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

Structured activity node execution model needs to be corrected

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

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

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

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

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

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

Include activity diagrams for classifier behaviors

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

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

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

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

    Agreed.

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

Variable needs initialization in InputPinActivation::receiveOffer

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

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

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

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

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

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

Problems with OCL for AcceptEventAction::fUML_active_context

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

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

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

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

    Note that the subclause for AcceptEventAction is actually 7.5.4.2.1.

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

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

References to uml::Class in OCL

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

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

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

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

    Agreed.

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

OCL for SendSignalAction::target_signal_reception is incorrect

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

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

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

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

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

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

OCL incomplete for CallBehaviorAction::proper_context

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

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

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

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

    Agreed.

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

Pin should be abstract

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

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

    In Figure 39, Pin should be shown as abstract.

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

    Agreed.

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

The composition from ObjectNode to TypedElement is incorrect

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

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

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

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

    Agreed.

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

InstanceValue constraint is redundant

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

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

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

    Recommendation: Remove the constraint on InstanceValue.

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

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

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

Incorrect generalizations in Kernel

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

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

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

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

    Recommendation:

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

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

    Agreed.

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

Items excluded from Kernel

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

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

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

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

    Agreed.

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

Active class should not have to have classifier behaviors

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

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

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

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

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

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

OpaqueBehavior::opaqueBehavior should be OpaqueBehavior::language

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

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

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

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

    Agreed.

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

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

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

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

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

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

    Agreed.

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

A data type should not be allowed to have operations

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

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

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

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

    Agreed.

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

Base Semantics

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

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

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

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

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

The superclass of ActvityNode and ActivityEdge should be RedefinableElement

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

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

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

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

    Agreed.

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

Receptions should never be abstract

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

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

    Subclause: 7.3.3.2.3 Reception

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

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

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

    Add the constraint as proposed

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

Only abstract classes should be able to have abstract behavioral features

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

    Specification: Semantics of a Foundational Subset for Executable UML Models

    Subclause: 7.2.2.2.3 Class

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

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

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

    Add the constraint as proposed

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

Subclause: 8.5.2.2.6 ActivityParameterNodeActivation

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

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

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

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

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

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

7.5.2.2.9 SendSignalAction

  • Key: FUML-25
  • Legacy Issue Number: 13511
  • 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.5.2.2.9 SendSignalAction

    Summary:

    The description of the constraint states:

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

    The OCL constraint is invalid:

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

    >includes(self.signal)

    Proposed resolution:

    Change:

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

    >includes(self.signal)

    To:

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

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

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

    Change the constraint as proposed

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

[FUML] 8.6.3.2.4 CreateLinkActionActivation.doAction()

  • Key: FUML-26
  • Legacy Issue Number: 13544
  • 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: 8.6.3.2.4 CreateLinkActionActivation

    Summary:

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

    Proposed resolution:

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

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

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

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;

    boolean noMatch = true;

    int j = 1;

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

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

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

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

    j = j + 1;

    }

    }



    Link newLink = new Link();



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

    LinkEndCreationData endData = endDataList.getValue;



    int insertAt = 0;

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

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

    }



    this.getExecutionLocus().add(newLink);



    To:



    Association linkAssociation = this.getAssociation();

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



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

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;



    boolean noMatch = true;

    int j = 1;

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

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

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

    j = j + 1;

    }

    }

    Link newLink = new Link();

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

    LinkEndCreationData endData = endDataList.getValue;

    int insertAt = 0;

    if (endData.insertAt != null)

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

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

    }

    newLink.type = linkAssociation;

    this.getExecutionLocus().add(newLink);

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

    Change the code as (essentially) as proposed.

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

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

  • Key: FUML-27
  • Legacy Issue Number: 13546
  • 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: 8.6.4.2.1 AcceptEventActionActivation

    Summary:

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

    Proposed resolution:

    Change the operation from:

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

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

    // the result pin.

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

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

    // corresponding output pin.

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

    // token.

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

    // action execution with the context object.

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

    OutputPinList resultPins = action.result;

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

    if (this.running) {

    if (!action.isUnmarshall)

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

    else {

    FeatureValueList featureValues = signalInstance.getFeatureValues();

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

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

    }

    this.sendOffers();

    this.waiting = false;

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

    // if (this.isReady())

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

    this.receiveOffer();

    }



    }



    To:



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

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

    // the result pin, if any.

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

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

    // corresponding output pin, if any.

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

    // token.

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

    // action execution with the context object.



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

    OutputPinList resultPins = action.result;



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



    if (this.running) {

    if (resultPins.size() > 0) {

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

    FeatureValueList featureValues = signalInstance.getFeatureValues();

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

    }

    }

    this.sendOffers();



    this.waiting = false;



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

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

    this.receiveOffer();

    }

    }

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

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

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

8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation

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

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

    Section: 8.6.2.2.1 ActionActivation, 8.6.3.2.4 CreateLinkActionActivation and 8.6.3.2.8 LinkActionActivation

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

    Summary:

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

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

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

    Proposed Resolution:

    Resolving this issue entails 3 things:

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

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

    /**

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

    */

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

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

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

    // owned by the action of the action execution.

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

    // input pin and return them.

    // NFR 04/16/2009

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

    PinActivation pinActivation = this.getPinActivation(pin);

    TokenList tokens = pinActivation.getTokens();

    ValueList values = new ValueList();

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

    Token token = tokens.getValue;

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

    if (value != null)

    { values.addValue(value); }

    }

    return values;

    }

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

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

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

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

    // end data.

    boolean matches = false;

    if (endData.value == null)

    { matches = true; }

    else {

    Property end = endData.end;

    FeatureValue linkFeatureValue = link.getFeatureValue(end);

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

    if (endData instanceof LinkEndDestructionData) {

    if (!((LinkEndDestructionData) endData).isDestroyDuplicates

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

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

    else

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

    } else

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

    }

    return matches;

    }

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

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

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

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

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

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

    public void doAction() {

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

    // for which links are being destroyed.

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

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

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

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

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

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

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

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

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

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

    LinkEndDestructionDataList destructionDataList = action.endData;

    boolean destroyOnlyOne = false;

    int j = 1;

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

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

    LinkEndDataList endDataList = new LinkEndDataList();

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

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

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

    ExtensionalValueList matchingLinks = new ExtensionalValueList();

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

    ExtensionalValue value = extent.getValue;

    Link link = (Link) value;

    if (this.linkMatchesEndData(link, endDataList))

    { matchingLinks.addValue(link); }

    }

    /*

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

    */

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

    LinkEndDestructionData endData = destructionDataList.getValue;

    Property end = endData.end;

    if (!endData.isDestroyDuplicates

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

    { this.getTokens(endData.destroyAt); }

    this.getTokens(endData.value);

    }

    if (destroyOnlyOne) {

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

    // non-deterministically choose one. ***

    if (matchingLinks.size() > 0)

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

    } else {

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

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

    }

    }

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

    public void doAction() {

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

    // which the action applies.

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

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

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

    LinkEndDataList endDataList = action.endData;

    LinkEndData openEnd = null;

    int i = 1;

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

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

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

    i = i + 1;

    }

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

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

    ExtensionalValue value = extent.getValue(j);

    Link link = (Link) value;

    if (this.linkMatchesEndData(link, endDataList))

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

    }

    /*

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

    */

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

    LinkEndData endData = endDataList.getValue(k);

    if (endData.value != null)

    { this.getTokens(endData.value); }

    }

    }

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

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

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

[FUML] 7.4.2.2.14 ObjectFlow

  • Key: FUML-24
  • Legacy Issue Number: 13509
  • 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.14 (ObjectFlow)

    Summary:

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

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

    Proposed resolution:

    Add a second OCL constraint on ObjectFlow:

    [2] ObjectFlow::no_transformation_or_selection_behavior()

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

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

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

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

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

    Revised Text:
    None.
    Disposition: Closed, no change

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

Error in ReadLinkActionActivation

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

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

    Section: 8.6.3.2.9 ReadLinkActionActivation

    In ReadLinkActionActivation::doAction, the code:

    if (endDataList.getValue.value == null)

    { openEnd = endDataList.getValue(i); }

    Should be changed to:

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

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

    Change the code as proposed

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

Event should be a specialization of PackageableElement

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

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

    Summary:

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

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

    Event should, indeed, have PackageableElement as a generalization

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

LoopNodeActivation::doStructuredActivity uses a Java array

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

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

    Summary:

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

    Proposed Resolution:

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

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

    { … }

    ”, replace the code with:

    this.activationGroup.terminateAll();

    this.bodyOutputLists.clear();

    OutputPinList bodyOutputs = loopNode.bodyOutput;

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

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

    this.runLoopVariables();

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

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

    Change the code as proposed

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

ActionActivation::isSourceFor does not initialize a local variable

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of isSourceFor with:

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

    boolean isSource = false;

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

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

    return isSource;

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

    Change the code as proposed.

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

UnlimitedNaturalValue::toString does not follow Annex A conventions

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "*";

    if (this.value.naturalValue >= 0)

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

    return stringValue;

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

    Change the code as proposed.

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

IntegerValue::toString uses Java String.valueOf

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "";

    if (this.value == 0)

    { stringValue = "0"; }

    else {

    int positiveValue = this.value;

    if (positiveValue < 0)

    { positiveValue = -positiveValue; }

    do {

    int digit = positiveValue % 10;

    if (digit == 0)

    { stringValue = "0" + stringValue; }

    else if (digit == 1)

    { stringValue = "1" + stringValue; }

    else if (digit == 2)

    { stringValue = "2" + stringValue; }

    else if (digit == 3)

    { stringValue = "3" + stringValue; }

    else if (digit == 4)

    { stringValue = "4" + stringValue; }

    else if (digit == 5)

    { stringValue = "5" + stringValue; }

    else if (digit == 6)

    { stringValue = "6" + stringValue; }

    else if (digit == 7)

    { stringValue = "7" + stringValue; }

    else if (digit == 8)

    { stringValue = "8" + stringValue; }

    else if (digit == 9)

    { stringValue = "9" + stringValue; }

    positiveValue = positiveValue / 10;

    } while (positiveValue > 0);

    if (this.value < 0)

    { stringValue = "-" + stringValue; }

    }

    return stringValue;

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

    Change the code as proposed

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

EnumerationValue::specify missing a "this"

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

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

    Summary:

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

    Proposed Resolution:

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

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

    Change the code as proposed.

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

InstanceValueEvaluation::evaluate does not initialize local variables

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

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

    Summary:

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

    Proposed Resolution:

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

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

    Change the code as proposed.

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

CompoundValue::equals does not conform to Annex A conventions

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of the equals operation with:

    boolean isEqual = otherValue instanceof CompoundValue;

    if (isEqual) {

    CompoundValue otherCompoundValue = (CompoundValue)otherValue;

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

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

    int i = 1;

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

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

    boolean matched = false;

    int j = 1;

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

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

    if (thisFeatureValue.feature == otherFeatureValue.feature)

    { matched = thisFeatureValue.hasEqualValues(otherFeatureValue); }

    j = j + 1;

    }

    isEqual = matched;

    i = i + 1;

    }

    }

    return isEqual;

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

    Change the code as proposed

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

FeatureValue::hasEqualValues does not follow Annex A conventions

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

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

    Summary:

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

    Proposed Resolution:

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

    Replace:

    ValueList otherValues = new ValueList();

    with:

    FeatureValue otherFeatureValues = new FeatureValue();

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

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

    Change the code as proposed

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

BooleanValue::toString uses Java String.valueOf

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of the toString operation with:

    String stringValue = "false";

    if (this.value)

    { stringValue = "true"; }

    return stringValue;

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

    Change the code as proposed.

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

ExecutionFactory::getStrategy doesn't follow conventions

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

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

    Summary:

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

    Proposed Resolution:

    Replace the body of getStrategy with:

    // Get the strategy with the given name.

    int i = this.getStrategyIndex(name);

    SemanticStrategy strategy = null;

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

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

    return strategy;

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

    Change the code as proposed.

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

Link::getTypes does not initialize a local variable

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

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

    Summary:

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

    Proposed Resolution:

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

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

    Change the code as proposed.

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

Error in return value of ActivityNodeActivation::removeToken

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

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

    Summary:

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

    Proposed Resolution:

    At the end of the operation replace:

    return i -1;

    with:

    if (notFound)

    { i = 0; }

    else

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

    Change the code as proposed.

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

ExecutionFactory::instantiateVisitor should not use Java reflection

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

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

    Summary:

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

    Proposed Resolution:

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

    // Instantiate a visitor object for the given element.

    SemanticVisitor visitor = null;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    return visitor;

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

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

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

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

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

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

    Summary:

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

    Proposed resolution:

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

    this.putToken(action.result, value);

    with:

    if (action.result != null)

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

    Change the code as proposed.

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

Issue: Bug in ReclassifyObjectActionActivation::doAction

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

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

    Summary:

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

    Proposed resolution:

    Replace:

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

    with:

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

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

    Change the code as proposed.

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

Issue: CallActionActivation cannot handle more than one concurrent call

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

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

    Section: 8.6.2.2.2 (CallActionActivation)

    Summary:

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

    Proposed resolution:

    Under associations, replace CallActionActivation::callExecution with:

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

    At the beginning of CallActionActivation::doAction, replace:

    this.callExecution = this.getCallExecution();

    if (this.callExecution != null) {

    with:

    Execution callExecution = this.getCallExecution();

    if (callExecution != null) {

    this.callExecutions.addValue(callExecution);

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

    this.callExecution = null;

    with:

    this.removeCallExecution(callExecution);

    Replace the body of CallActionActivation::terminate with:

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

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

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

    super.terminate();

    Add the following operation:

    CallActionActivation::removeCallExecution(execution: Execution)

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

    boolean notFound = true;

    int i = 1;

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

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

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

    }

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

    Change the code as proposed

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

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

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

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

    Section: 8.6.2.2.1 (ActionActivation)

    Summary:

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

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

    Proposed resolution:

    Replace:

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

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

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

    { this.receiveOffer(); }

    with:

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

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

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

    boolean fireAgain = true;

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

    int j = 1;

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

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

    if (fireAgain)

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

    }

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

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

    Change the code as proposed.

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

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

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

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

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

    Summary:

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

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

    Proposed resolution:

    Add the following operation to ObjectNodeActivation:

    ObjectNodeActivation::takeUnofferedTokens(): Token[*]

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

    TokenList tokens = this.getUnofferedTokens();

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

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

    return tokens;

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

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

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

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

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

    super.fire(incomingTokens);

    this.sendUnofferedTokens();

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

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

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

    Change the code as proposed

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

Issue: ObjectNodeActivation::offeredTokenCount is not initialized

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

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

    Section: 8.5.2.2.15 (ObjectNodeActivation)

    Summary:

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

    Proposed resolution:

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

    super.run();

    this.offeredTokenCount = 0;

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

    Change the code as proposed

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

Issue: ActivityNodeActivation::clearTokens incorrect

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

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

    Section: 8.5.2.2.3 (ActivityNodeActivation)

    Summary:

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

    Proposed resolution:

    Replace the current code with the following:

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

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

    Change the code as proposed

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

Issue: InitialNodeActivation::fire should use sendOffers

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

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

    Section: 8.5.2.2.12 (InitialNodeActivation)

    Summary:

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

    Proposed resolution:

    Replace:

    super.fire(tokens);

    with:

    this.sendOffers(tokens);

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

    Change the code as proposed.

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

Issue: Sending offers from ForkNodeActivation::fire

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

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

    Proposed resolution:

    Replace the loop:

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

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

    with:

    this.sendOffers(forkedTokens);

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

    Replace the offending loop as proposed

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

Errors in ReduceActionActivation::doAction

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

Null tokens are not sent on by control nodes

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

Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A

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

Addition to the resolution to fUML Issue 15987

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

Correction to the resolution to fUML Issue 17209

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

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: Model Driven Solutions ( 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

Addition to the resolution of fUML Issue 17203

  • Key: FUML11-37
  • Legacy Issue Number: 17558
  • Status: closed  
  • Source: Model Driven Solutions ( 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 17499

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

Error in setting result pin values for CallActions

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

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

Correction to the resolution of Issue 17209

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

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

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

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

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

ForkNodeActivation does not clear its tokens on termination

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

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

ExpansionRegionActivation isReady condition is too strong

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

ExpansionRegionActivation does not reset its activationGroups

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

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

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

Error in check for enable nodes

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

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

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

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

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

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

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

Spurious comment on operation PinActivation::fire

  • Key: FUML11-10
  • Legacy Issue Number: 17168
  • Status: closed  
  • Source: Model Driven Solutions ( 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 RemoveStructuralFeatureVauleActionActivation::doAction

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

Error in CreateLinkAction semantics

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

Duplicate code for ActionActivation::putToken

  • Key: FUML11-8
  • Legacy Issue Number: 16687
  • Status: closed  
  • Source: Model Driven Solutions ( 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 ExpansionRegionActivation::takeOfferedTokens

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

Error in DecisionNodeActivation semantics

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

An action may not stop firing again

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

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

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

    agreed

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

fUML 1.1 should be based on UML 2.4

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

Flow final nodes should be included

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