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

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

  • Acronym: FUML
  • Issues Count: 205
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

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-30 repeated constraint FUML 1.4 FUML 1.5 Resolved closed
FUML15-28 fUML should allow association ends that are not association owned FUML 1.4 FUML 1.5 Resolved closed
FUML15-18 fUML should include association classes FUML 1.4 FUML 1.5 Closed; Out Of Scope closed
FUML15-13 fUML should include unmarshall actions FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-12 fUML should include streaming FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-17 Objects at the composite end of an association should be considered "owned objects" during the destruction of the object at the other end FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-40 ReturnInformation is missing operations FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-29 Missing class descriptions for expansion region activations FUML 1.4 FUML 1.5 Resolved closed
FUML15-4 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.5 Deferred closed
FUML15-7 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.5 Deferred closed
FUML15-27 fUML should not require signal receptions FUML 1.4 FUML 1.5 Resolved closed
FUML15-19 Inv function for Real types signature is wrong FUML 1.4 FUML 1.5 Resolved closed
FUML15-14 fUML should include interruptible activity regions FUML 1.4b1 FUML 1.5 Closed; Out Of Scope closed
FUML15-11 The fUML threading model should be made explicit FUML 1.4b1 FUML 1.5 Deferred closed
FUML15-16 Destroying an object should remove its feature values FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-15 fUML should specify semantics for activity partitions FUML 1.4b1 FUML 1.5 Closed; Out Of Scope closed
FUML15-5 Base Semantics PSL version FUML 1.1 FUML 1.5 Resolved closed
FUML15-3 Defects in Base Semantics from fUML FUML 1.1 FUML 1.5 Resolved closed
FUML15-1 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.5 Closed; No Change closed
FUML15-8 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.5 Closed; No Change closed
FUML15-6 Actions outside the bUML FUML 1.1 FUML 1.5 Closed; No Change closed
FUML15-36 Typo fixes FUML 1.4b1 FUML 1.5 Resolved closed
FUML15-9 Execution of an activity with a data store may never end FUML 1.4b1 FUML 1.5 Resolved closed
FUML14-8 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.4 Deferred closed
FUML14-7 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.4 Deferred closed
FUML14-6 Actions outside the bUML FUML 1.1 FUML 1.4 Deferred closed
FUML14-5 Base Semantics PSL version FUML 1.1 FUML 1.4 Deferred closed
FUML14-4 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.4 Deferred closed
FUML14-3 Defects in Base Semantics from fUML FUML 1.1 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
FUML14-1 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.4 Deferred closed
FUML14-9 Migrate fUML to UML 2.5.1 FUML 1.3 FUML 1.4 Resolved closed
FUML14-21 Correction to the resolution to issue FUML14-10 FUML 1.3 FUML 1.4 Resolved closed
FUML14-10 The ExecutionFactory class descriptions need to be updated in the specification for CentralBufferNode and DataStoreNode FUML 1.3 FUML 1.4 Resolved closed
FUML13-60 Simplification to the resolution of Issue FUML13-1 FUML 1.2 FUML 1.3 Resolved closed
FUML13-26 Reference::equal should use Object::equals FUML 1.2 FUML 1.3 Resolved closed
FUML13-25 Refactor EventOccurrence to provide useful operations FUML 1.2 FUML 1.3 Resolved closed
FUML13-24 Return type of getNextEvent is wrong in Figure 8.17 FUML 1.2 FUML 1.3 Resolved closed
FUML13-23 EventOccurrence should be used instead of SignalInstance in execution model operation parameters FUML 1.2 FUML 1.3 Resolved closed
FUML13-49 Correction to the resolution to issue FUML13-25 FUML 1.2 FUML 1.3 Resolved closed
FUML13-16 Introduce CallEvent, AcceptCallAction and ReplyAction to keep consistency with PSSM FUML 1.2 FUML 1.3 Resolved closed
FUML13-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-22 Association Roles in Figure 7.3 Flipped FUML 1.2 FUML 1.3 Resolved closed
FUML13-29 "Debug" statements should be removed FUML 1.2 FUML 1.3 Resolved closed
FUML13-28 The specification of IntegerFunctions::Div is incorrect FUML 1.2 FUML 1.3 Resolved closed
FUML13-27 Input parameter activity nodes should fire first FUML 1.2 FUML 1.3 Resolved closed
FUML13-32 There is an incorrect note about navigating links using structural feature actions FUML 1.2 FUML 1.3 Resolved closed
FUML13-21 BasicInputOutput operations for reading and writing reals are missing FUML 1.2 FUML 1.3 Resolved closed
FUML13-19 The fUML spec uses "new" in diagrams and text in a specialized manner that is not defined. FUML 1.2 FUML 1.3 Resolved closed
FUML13-18 Prose for semantics of AddStructuralFeatureValueAction required FUML 1.2 FUML 1.3 Resolved closed
FUML13-17 Stand-alone owned behavior of BehavioredClassifier shall be possible FUML 1.2 FUML 1.3 Resolved closed
FUML13-14 Incomplete update to ClassifierBehaviorInvocationEventAccepter::invokeBehavior FUML 1.2 FUML 1.3 Resolved closed
FUML13-12 Bad event accepter removed from the waitingEventAccepter list FUML 1.2 FUML 1.3 Resolved closed
FUML13-3 Base semantics: incorrect description of empty-output-parameter-node FUML 1.0 FUML 1.3 Resolved closed
FUML13-20 Error in RealValue::toString FUML 1.2 FUML 1.3 Resolved closed
FUML13-7 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.3 Deferred closed
FUML13-6 Defects in Base Semantics from fUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-5 The fUML subset should support the raising and handling of exceptions FUML 1.0 FUML 1.3 Deferred closed
FUML13-2 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.3 Deferred closed
FUML13-11 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.3 Deferred closed
FUML13-10 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-9 Actions outside the bUML FUML 1.1 FUML 1.3 Deferred closed
FUML13-8 Base Semantics PSL version FUML 1.1 FUML 1.3 Deferred 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-35 Initial execution of an activity is not run-to-completion FUML 1.1 FUML 1.2 Resolved closed
FUML12-33 Extensional values should have an unique identifier FUML 1.1 FUML 1.2 Resolved closed
FUML12-20 Feature values need to be created for private structural features of parent classifiers FUML 1.1 FUML 1.2 Resolved closed
FUML12-23 RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value FUML 1.1 FUML 1.2 Resolved closed
FUML12-10 Certain Boolean flags are not properly initialized in some cases FUML 1.0 FUML 1.2 Resolved closed
FUML12-60 The OCL for CallBehaviorAction::proper_context has an error FUML 1.1 FUML 1.2 Resolved closed
FUML12-36 Problem with CallActionActivation: possible infinite loop in removeCallExecution() FUML 1.1 FUML 1.2 Resolved closed
FUML12-2 7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance FUML 1.0b1 FUML 1.2 Closed; Out Of Scope closed
FUML12-34 AcceptEventActionActivation::match should match instances of descendants of a trigger's signal FUML 1.1 FUML 1.2 Resolved closed
FUML12-21 ReclassifyObjectAction handles removal of structural features incorrect FUML 1.0 FUML 1.2 Resolved closed
FUML12-19 The types of the ReadLine::errorStatus and WriteLine::errorStatus parameters should be Status FUML 1.1 FUML 1.2 Resolved closed
FUML12-24 RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly FUML 1.1 FUML 1.2 Resolved closed
FUML12-32 ReadSelfAction is not compliant with UML 2.4.1 Superstructure Specification (formal/11-08-06) FUML 1.1 FUML 1.2 Closed; No Change closed
FUML12-31 Correction of method UnlimitedNaturalValue.equals FUML 1.1 FUML 1.2 Resolved closed
FUML12-15 ListFunctions should have a ListConcat behavior FUML 1.1 FUML 1.2 Resolved closed
FUML12-14 FoundationModelLibrary, UnlimitedNaturalFunctions: inconsistencies between the spec and the normative xmi FUML 1.1 FUML 1.2 Resolved closed
FUML12-18 The Listener reception of Notification should have a name FUML 1.1 FUML 1.2 Resolved closed
FUML12-17 FoundationalModelLibrary::Common::Notification should be public FUML 1.1 FUML 1.2 Resolved closed
FUML12-16 The ReadLine::result parameter should have direction "return" FUML 1.1 FUML 1.2 Resolved closed
FUML12-57 List parameters of ListFunctions should be non-unique. FUML 1.1 FUML 1.2 Resolved closed
FUML12-5 The fUML subset should include central buffer nodes and data stores FUML 1.0 FUML 1.2 Deferred closed
FUML12-4 fUML 1.0 beta3 document (ad/2010-03-14), Subclause 10.4.6.2 FUML 1.0 FUML 1.2 Deferred closed
FUML12-3 Annex on normative XMI for fUML FUML 1.0b2 FUML 1.2 Deferred closed
FUML12-1 Section: Base Semantics FUML 1.0b1 FUML 1.2 Deferred closed
FUML12-7 ReclassifyObjectAction does not preserve structural feature values FUML 1.0 FUML 1.2 Resolved closed
FUML12-22 RemoveStructuralFeatureValueActionActivation: Determination of position(s) of value to be removed results in inf. loop FUML 1.1 FUML 1.2 Resolved closed
FUML12-9 The bodyOutputLists for a loop node need to be cleared when the node fires again FUML 1.0 FUML 1.2 Resolved closed
FUML12-13 Objects with cyclic references cannot be converted to string representations FUML 1.1 FUML 1.2 Resolved closed
FUML12-26 Computer-readable version of the Base Semantics FUML 1.1 FUML 1.2 Deferred closed
FUML12-25 Defects in Base Semantics from fUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-12 RealValue::toString puts too many digits in the mantissa FUML 1.1 FUML 1.2 Resolved closed
FUML12-11 Problem with ActivityExecution::terminate FUML 1.1 FUML 1.2 Resolved closed
FUML12-6 The fUML subset shuold support the raising and handling of exceptions FUML 1.0 FUML 1.2 Deferred closed
FUML12-30 Remove unneeded inference rules from Base Semantics FUML 1.1 FUML 1.2 Deferred closed
FUML12-29 Cover all ActivityNodes used in bUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-28 Actions outside the bUML FUML 1.1 FUML 1.2 Deferred closed
FUML12-27 Base Semantics PSL version FUML 1.1 FUML 1.2 Deferred closed
FUML-55 Reference Menzel in Section 10 FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML_-6 Error in ObjectActivation::dispatchNextEvent FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-5 Modification to AcceptEventActionActivation FUML 1.0b2 FUML 1.0 Resolved closed
FUML_-8 Corrections to previous resolutions 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_-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
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_-1 Values passed out to pins from empty parameter nodes FUML 1.0b2 FUML 1.0 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-49 Variable needs initialization in InputPinActivation::receiveOffer 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-47 References to uml::Class in OCL 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-54 ObjectNodeActivation::unofferedTokens is spurious FUML 1.0b1 FUML 1.0b2 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-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-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-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-52 ObjectNodeOrderingKind should be in Activities::IntermediateActivities 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-36 A passive class should not be able to specialize an active class 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-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-39 Items excluded from Kernel 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-35 Active class should not have to have classifier behaviors FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-32 Receptions should never be abstract 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-3 Issue: InitialNodeActivation::fire should use sendOffers 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-6 Issue: ObjectNodeActivation::offeredTokenCount is not initialized 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-10 Error in return value of ActivityNodeActivation::removeToken FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-9 Issue: Bug in ReclassifyObjectActionActivation::doAction 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-2 Issue: ActivityNodeActivation::clearTokens incorrect FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-1 Issue: Sending offers from ForkNodeActivation::fire 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-28 Error in ReadLinkActionActivation 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-26 [FUML] 8.6.3.2.4 CreateLinkActionActivation.doAction() 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-30 Subclause: 8.5.2.2.6 ActivityParameterNodeActivation 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-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-19 Link::getTypes does not initialize a local variable 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-24 [FUML] 7.4.2.2.14 ObjectFlow 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-14 CompoundValue::equals does not conform to 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-16 FeatureValue::hasEqualValues does not follow Annex A conventions FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML-15 EnumerationValue::specify missing a "this" 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-17 InstanceValueEvaluation::evaluate does not initialize local variables FUML 1.0b1 FUML 1.0b2 Resolved closed
FUML11-34 Conditional node and loop node activations do not wait for contained accept event action activations FUML 1.0 FUML 1.1 Resolved closed
FUML11-33 Null tokens are not sent on by control nodes FUML 1.0 FUML 1.1 Resolved closed
FUML11-29 Read link actions and read structural feature actions do not handle ordered ends correctly FUML 1.0 FUML 1.1 Resolved closed
FUML11-28 Correction to the resolution of Issue 17209 FUML 1.0 FUML 1.1 Resolved closed
FUML11-27 Structured activity node activations do not wait for contained accept event action activations FUML 1.0 FUML 1.1 Resolved closed
FUML11-32 Errors in ReduceActionActivation::doAction FUML 1.0 FUML 1.1 Resolved closed
FUML11-31 Addition to resolution to Issue 17299 FUML 1.0 FUML 1.1 Resolved closed
FUML11-30 Error in setting result pin values for CallActions FUML 1.0 FUML 1.1 Resolved closed
FUML11-26 DecisionNodeActivation can send offers to multiple outgoing edges FUML 1.0 FUML 1.1 Resolved closed
FUML11-25 Having a fork node as initial enabled node does not work FUML 1.0 FUML 1.1 Resolved closed
FUML11-24 An activity final node should not fire if it is not offered any tokens FUML 1.0 FUML 1.1 Resolved closed
FUML11-36 Addition to the resolution to fUML Issue 15987 FUML 1.0 FUML 1.1 Resolved closed
FUML11-35 Specification of ClassifierBehaviorExecution and ObjectActivation are not consistent with Annex A FUML 1.0 FUML 1.1 Resolved closed
FUML11-38 Correction to the resolution to fUML Issue 17209 FUML 1.0 FUML 1.1 Resolved closed
FUML11-37 Addition to the resolution of fUML Issue 17203 FUML 1.0 FUML 1.1 Resolved closed
FUML11-39 Addition to the resolution to fUML Issue 17499 FUML 1.0 FUML 1.1 Resolved closed
FUML11-3 An action may not stop firing again FUML 1.0b2 FUML 1.1 Resolved closed
FUML11-2 Flow final nodes should be included FUML 1.0b1 FUML 1.1 Resolved closed
FUML11-1 7.4.2.2.2 ActivityEdge, 7.4.2.2.4 ActivityNode & A.5.2 List Add FUML 1.0b1 FUML 1.1 Resolved closed
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-4 fUML 1.1 should be based on UML 2.4 FUML 1.0 FUML 1.1 Resolved closed
FUML11-16 ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor FUML 1.0 FUML 1.1 Resolved closed
FUML11-15 Error handling creation and destruction of links of associations with ordered ends FUML 1.0 FUML 1.1 Resolved closed
FUML11-23 LoopNodeActivation does not properly handle termination due to an activity final node 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-21 ForkNodeActivation does not clear its tokens on termination FUML 1.0 FUML 1.1 Resolved closed
FUML11-20 ExpansionRegionActivation does not reset its activationGroups FUML 1.0 FUML 1.1 Resolved closed
FUML11-19 Error in check for enable nodes FUML 1.0 FUML 1.1 Resolved closed
FUML11-14 Error in ActivityNodeActivationGroup::getOutputParameterNodeActivations FUML 1.0 FUML 1.1 Resolved closed
FUML11-13 Bug in ForkedToken::withdraw when the baseToken is a ForkedToken FUML 1.0 FUML 1.1 Resolved closed
FUML11-12 Bug in DestroyObjectActivation::objectIsComposite FUML 1.0 FUML 1.1 Resolved closed
FUML11-7 Error in CreateLinkAction semantics FUML 1.0 FUML 1.1 Resolved closed
FUML11-6 Error in ExpansionRegionActivation::takeOfferedTokens FUML 1.0 FUML 1.1 Resolved closed
FUML11-18 Structural Feature Actions on Data Values Need to Create a new Result Value FUML 1.0 FUML 1.1 Resolved closed
FUML11-17 ActionActivation.sendOffers(): Missing sending of offers on outgoing control flows? FUML 1.0 FUML 1.1 Resolved closed
FUML11-9 Error in DecisionNodeActivation semantics FUML 1.0 FUML 1.1 Resolved closed
FUML11-8 Duplicate code for ActionActivation::putToken FUML 1.0 FUML 1.1 Resolved closed
FUML11-11 Error in RemoveStructuralFeatureVauleActionActivation::doAction FUML 1.0 FUML 1.1 Resolved closed
FUML11-10 Spurious comment on operation PinActivation::fire FUML 1.0 FUML 1.1 Resolved closed

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:

repeated constraint

  • Key: FUML15-30
  • Status: closed  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    constraint 3 is a repetition of constraint 1

  • Reported: FUML 1.4 — Sun, 4 Aug 2019 17:07 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Restore fuml_class_active_class_classifier_behavior constraint

    In the normative fUML_Syntax XMI for fUML 1.4, there are actually three constraints for Class (as there were in fUML 1.3). In subclause 7.7.2.2, constraint [1] should actually be fuml_class_active_class_classifier_behavior, as in the XMI.

    [Editorial note: This subclause was incorrectly numbered 7.7.2.1 in the fUML 1.4 document.]

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

fUML should allow association ends that are not association owned

  • Key: FUML15-28
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The constraint fuml_association_owns_memberEnds added to Association in 7.7.2.1 requires an association in fUML to own all its ends. While this simplifies association semantics, it is inconsistent with the default in most UML tools, which is to have association ends owned by the end types. Further, SysML requires that only non-navigable ends can be association owned (see SysML 1.5, 8.3.2.4 Block, Constraint 3).

    Now, it is often sufficient to simply consider non-association-owned ends to be just regular attributes of their owning classifiers, ignoring the association, for the purpose of fUML semantics. Nevertheless, doing this loses any bidrectional semantics the association might have. And such a model is technically not fUML conformant.

    Therefore, it would be better if fUML provided semantics for associations that did not own all their ends.

  • Reported: FUML 1.4 — Wed, 24 Apr 2019 02:16 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Allow associations with unowned ends

    If there current constraint requiring associations to own their ends is simply removed, the current semantics already handles associations with unowned ends almost completely correctly. This is because it is already possible to perform structural feature actions on owned ends of associations as if they were features of the types of the opposite ends. The semantics works the same even if the ends are not owned by the association, including bidirectionality. The key to this is that if an association end is owned by an end type, then the values of that end are still maintained only in links of the association, not in feature values on instances of the end types.

    There are only two additional actions that need to be considered:

    • Reclassify object action: If an object is reclassified such that it losses a feature that is an association end, then all links from that object via that association end need to be destroyed.
    • Unmarshall action: The values of any attribute of an unmarshalled value that is an association end needs to be obtained from the links of the appropriate association. (Unmarshall actions where added to fUML by the resolution of FUML15-13.)
  • Updated: Fri, 18 Sep 2020 17:03 GMT

fUML should include association classes

  • Key: FUML15-18
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    While the fUML subset includes classes and associations, it currently does not include association classes. The original reason for this was that association classes can always be simulated using just regular classes, and keeping associations separate from classes made the fUML execution model simpler. However, when one uses a class instead of an association class, the effective end multiplicities do not reflect the association multiplicities, so the model is less clear. Therefore, it would be preferable to support association classes directly, along with the relevant link object actions on them.

  • Reported: FUML 1.4 — Mon, 18 Mar 2019 14:16 GMT
  • Disposition: Closed; Out Of Scope — FUML 1.5
  • Disposition Summary:

    Out of scope

    The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

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

fUML should include unmarshall actions

  • Key: FUML15-13
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Unmarshall actions are currently excluded from the fUML subset with the rational that they "redundant with unmarshalling a signal as received by an accept event action" (see subclause 7.11.1 in the fUML 1.4 specification). However, there are cases when it is useful to accept a signal without unmarshalling it initially (e.g., in order to be able to test its type), and then later unmarshall it. Further, unmarshall actions can be used for objects other than signals, providing a more convenient way to access object attributes than using multiple read structural feature actions.

    Therefore, the rationale for excluding unmarshall actions from fUML is weak. They would also be very simple to specify (since their behavior is effectively already included in the specification for accept event actions with isUnmarshall = true). So, these actions should be included in fUML.

  • Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:29 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Add UnmarshallAction

    Add UnmarshallAction to the fUML syntax subset and UnmarshallActionActivation to the fUML execution model.

    In addition, fix the unmarshalling logic in AcceptEventActionActivation. The current logic does not properly handle the case when an accepted signal instance has a type that is a subtype of the signal declared for the triggering signal event. This is because SignalEventOccurrence::getParameterValues returns parameter values for all the attributes of the signal instance, which may be more than those of the signal supertype declared in the triggering signal event. The unmarshalling loop in AcceptEventActionActivation::accept then tries to unmarshall all the parameter values, but the number of result pins is determined by the number of attributes on signal declared in the signal event.

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

fUML should include streaming

  • Key: FUML15-12
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The fUML subset currently specifically excludes streaming parameters (see constraint fuml_parameter_not_exception_not_streaming in subclause 7.5.2.5 of the fUML 1.4 specification). While the use of streaming parameters is not critical for the modeling of software behavior, it is very commonly used in SysML activity models. Indeed, there is currently work ongoing to specify precise execution semantics for SysML 1.7, which will need to include the semantics of streaming. But the semantics of streaming are not really specific to SysML, and would also be useful for modeling the equivalent of "lazy evaluation" of lists, even in software models. Therefore, the fUML subset should be updated to include streaming parameters and the semantics of streaming in the execution of activities.

  • Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:19 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Add semantics for streaming

    Including semantics for streaming parameters in fUML was of interest from the time the standard was first developed. While it was decided not to include originally, the lack of streaming semantics has been increasingly detrimental to the use of fUML in the core area of model simulation. Further, much of the functionality need for streaming actually already exists in the current fUML execution model.

    During the execution of an activity, the primary effect of using streaming parameters is on the semantics of call actions. When calling a behavior without streaming parameters, values on the input pins of the calling action are made available to the executing behavior, then the behavior executes to completion, after which any output parameter values are placed on the output pins of the calling action. On the other hand, if a behavior with input streaming parameters is called, then the behavior may continue executing even after all non-streaming inputs have been processed, in order to handle additional inputs that may be received through the streaming parameters. Further, if the behavior has streaming output parameters, then values posted to those parameters will be immediately offered from the output pins of the calling action, even while the behavior is still executing.

    There is a close similarity between the semantics of calling an activity and the semantics of a structured activity node with a similar body to the activity. To a certain extent, the semantics of such a call can be thought of as being much like doing a “macro insertion” of the body of the called activity as a structured activity node at the point of the call. The semantic model for a structured activity node gives it an associated activity node activation group, similar to the activation group associated with a called activity. The activity node activation group for the structured activity node activation is created when the structured activity node activation fires.

    In this semantic analog, the pins for non-streaming parameters on the call action are analogous to pins on the structured activity node. This means that the normal rules for firing and completing the structured activity node as an action apply to these pins. Extending this analogy to streaming, the pins for streaming parameters on the call action do not correspond to pins on the structured activity node, but, rather, the incoming object flows for streaming input parameter values pass directly into the interior of the structured activity node, and the outgoing object flows for output parameter values pass directly out. This reflects the semantics that, once the structured activity node has fired, tokens can pass freely in and out on these flows. The semantics of a call action with streaming parameters is analogous. Once the call action has fired, tokens can continue to pass in and out on the flows attached to pins corresponding to streaming parameters, during the execution of the called activity.

    In the current semantic model for structured activity nodes, when a structured activity node activation fires, activity edge instances are also created at this time for the object flows that cross the structured activity node boundary. These edge instances directly connect pin activations outside the nested activity node activation group to those inside, allowing the flow of tokens regardless of the presence of the surrounding structured activity node. In order to allow such streaming semantics for call actions, it is necessary to create similar connections across the activity node activation group for containing the call action activation and the group for the called activity, in order to allow values to stream in and out of the called activity during its execution. The proposal here is to provide the necessary connections by allowing a streaming parameter value to have a registered listener. With this approach when values are posted to the streaming parameter, they are distributed to the registered listener.

    • In the case of an input parameter, the corresponding activity parameter node creates a listener for itself and registers it with the appropriate parameter value. The call action input pin activation then continues to post values to the streaming parameter value as it receives them at any time during the execution of the call action, and these are then forwarded via the listener to the activity parameter node to be offered within the called activity.
    • For an output parameter, the call behavior action creates a listener for its corresponding output pin activation. The activity parameter node activation for the output parameter within the called activity execution then posts values to the streaming parameter value as it receives them at any time during the activity execution, and these are then forwarded via the listener to the output pin activation to be offered within the calling activity. Note that there is no direct connection between the activity parameter node activation for an output parameter and the streaming parameter value object for that parameter. Instead, the activity parameter node activation obtains the appropriate parameter value from its activity execution when necessary to post new values.

    In addition to new execution model class related to the listeners, this mechanism requires some significant changes to the specification of, particularly, the classes ActivityParameterNodeActivation, ActionActivation and CallActionActivation. However, the proposed streaming semantics are a clear extension of those currently specified for execution within an activity, and the adding this capability is entirely backwards compatible with previous fUML-conformant models that do not use streaming.

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

Objects at the composite end of an association should be considered "owned objects" during the destruction of the object at the other end

  • Key: FUML15-17
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The UML specification the, for a DestroyObjectAction, "If isDestroyOwnedObjects is true, objects owned by the object through composite aggregation are destroyed..." [UML 2.5.1, 16.4.3.2] Clearly, this includes the case when one object "owns" another that is referenced in a composite property of the first object. It is less clear whether such ownership should also include an object linked to the first object by a composite association, in which the composite association end is owned by the association. However, it would seem likely that one would expect such objects to be included.

    In fUML, the currently specified behavior for a DestroyObjectAction with isDestroyOwnedObjects = true is that composition links from an object being destroyed are always destroyed, but the object at the other end is not destroyed (see [fUML 1,4, 8.10.2.16 DestroyObjectActionActivation, operation destroyObject]). Note that such links are destroyed even if isDestroyLinks = false, which does not seem consistent with the UML specification. It would be more consistent if such linked objects were also considered "owned objects" and destroyed along with the owning object, just as if they had been referenced by a composite property of the owning object.

  • Reported: FUML 1.4b1 — Thu, 20 Dec 2018 22:08 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Update DestroyObjectActionActivation::destroyObject

    The specification for DestroyObjectActionActivation::doAction actually includes the comment "If isDestroyOwnedObjects is true, destroy all objects owned by the referent via composition links", not even mentioning objects owned via attributes. The behavior of the action should be revised to destroy objects owned both via attributes and via links.

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

ReturnInformation is missing operations

  • Key: FUML15-40
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    According to FUML13-16 the Class ReturnInformation should have following operations:

    • getOperation
    • copy
    • equals
    • getTypes
    • new_
    • reply
    • specify
    • toString

    Obviously the text has been truncated, since in 1.4 only the first 3 are listed.

  • Reported: FUML 1.4b1 — Wed, 1 Apr 2020 18:59 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Add ReturnInformation operation descriptions

    The submitter is correct, several operations for class ReturnInformation seem to have gotten lost in the restructuring of the specification document from 1.3 to 1.4. The operations are all in the normative fUML_Semantics XMI file for 1.4, though, so the descriptions just need to be added back into the specification document.

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

Missing class descriptions for expansion region activations

  • Key: FUML15-29
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The class descriptions that were under Extra Structured Activities in the execution model in fUML 1.3 (ExpansionRegionGroup, ExpansionNodeActivation, ExpansionRegionActivation, TokenSet) were accidentally left out of the fUML 1.4 specification. The semantics of expansion regions are described in 8.10.1 in the fUML 1.4 specification, and the classes are shown in Figure 8.34 in that subclause. Descriptions of these classes should have been included in 8.10.2.

  • Reported: FUML 1.4 — Sat, 18 May 2019 19:00 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Add missing descriptions for expansion region activations

    The following subclauses from the fUML 1.3 specification (formal/17-07-02)

    • 8.5.5.2.1 ExpansionActivationGroup
    • 8.5.5.2.2 ExpansionNodeActivation
    • 8.5.5.2.3 ExpansionRegionActivation
    • 8.5.5.2.4 TokenSet

    should be added to the fUML 1.5 specification as subclauses 8.10.2.17, 8.10.2.18, 8.10.2.19 and 8.10.2.42 (after adjusting for the other added subclauses), respectively.

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

Computer-readable version of the Base Semantics

  • Key: FUML15-4
  • Legacy Issue Number: 18795
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.5
  • Disposition Summary:

    Defer

    The fUML 1.5 RTF agrees that this issue should be resolved but, due to lack of time, is deferring it to a future RTF.

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

Cover all ActivityNodes used in bUML

  • Key: FUML15-7
  • Legacy Issue Number: 18798
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.5
  • Disposition Summary:

    Defer

    The fUML 1.5 RTF agrees that this issue should be resolved, but was not able to apply the necessary expertise to resolve it at this time, so is deferring it to a future RTF.

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

fUML should not require signal receptions

  • Key: FUML15-27
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    UML does not require that a model include signal receptions in order to send or accept signals. However, fUML adds the constraints SendSignalAction::fuml_send_signal_action_target_signal_reception (in 7.11.2.11) and AcceptEventAction::fuml_accept_event_receive_all_triggering_signals (in 7.11.2.2) that require the use of signal receptions for both sending and accepting signals. These constraints are entirely methodologically motivated, and they are unnecessary to the execution semantics for SendSignalActionActivation (in 8.10.2.33) or AcceptEventActionActivation (in 8.10.2.3), since both deal directly with signals (and their instances), not signal receptions.

    Since UML does not itself require the use of signal receptions, they are often not use in practice by modelers, and having to add them just to be properly conformant with fUML is a nuisance. The constraints should be removed.

  • Reported: FUML 1.4 — Tue, 23 Apr 2019 23:20 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Remove constraints requiring receptions

    It is agreed that the contraints SendSignalAction::fuml_send_signal_action_target_signal_reception and AcceptEventAction::fuml_accept_event_receive_all_triggering_signals should be removed.

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

Inv function for Real types signature is wrong

  • Key: FUML15-19
  • Status: closed  
  • Source: Technische Universität Ilmenau ( Francesco Bedini)
  • Summary:

    Is: Inv(x: Real, y: Real)
    Should be: Inv(x: Real) : Real

  • Reported: FUML 1.4 — Thu, 28 Mar 2019 15:13 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Correct Inv in Table 9.4.

    The specification of the Inv function is correct in the normative library XMI, but, as described in the issue, this is shown incorrectly in Table 9.4 in 9.3.3. This should be corrected.

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

fUML should include interruptible activity regions

  • Key: FUML15-14
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Interruptible activity regions are currently excluded from the fUML subset "because they are considered to be more appropriate for 'higher level' process modeling and outside the scope of fUML" (see subclause 7.10.1 of the fUML 1.4 specification). However, in the specification of the detail behavior of an asynchronously running activity, it is often useful to be able to break out of some ongoing behavior when some event is accepted. Using an interruptible region is the most convenient way to do this, and this is not really "higher level" process modeling.

    Indeed, using interruptible regions in this way is common in SysML activity models. And current ongoing work on specifying the precise semantics of SysML 1.7 will need to include the semantics of interruptible regions. However, since this semantics is not really specific to SysML, it would be better if it was specified within fUML.

  • Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:37 GMT
  • Disposition: Closed; Out Of Scope — FUML 1.5
  • Disposition Summary:

    Out of scope

    The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

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

The fUML threading model should be made explicit

  • Key: FUML15-11
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 8.9.1 of the fUML 1.4 speification describes the "threading model" for concurrent execution of actions within an activity. Currently, this is an "implicit" threading model, in the sense that a "thread" is simply a sequence of operation calls between action activation objects. There is no explicit class in the execution model that represents such a "thread" (as opposed to, for example, the explicit model for the execution of a behavior).

    While this is sufficient for the purposes of defining the semantics of activities as currently defined in fUML, it can be problematic in some cases for building additional semantics on this foundation. For example, in order to define the semantics of timing of execution within an activity (as required to respond to the currently open Precise Semantics of Time RFP), it would be very helpful to have a reified model of threads to which time semantics could be attached. This would also simply the current modeling of suspension and resumption of threads due to accept event actions.

    So, while a refactoring of the fUML execution model to introduce an explicit threading model would not introduce any functional change to fUML itself, it would allow fUML to be a better foundation on which to build other precise semantics standards.

  • Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:08 GMT
  • Disposition: Deferred — FUML 1.5
  • Disposition Summary:

    Defer

    The fUML 1.5 RTF agrees that this issue should be addressed. However, more analysis is necessary to consider if such a sweeping change can actually be made without functionally changing the execution semantics. The RTF has decided to defer resolution of the issue until this analysis can be done.

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

Destroying an object should remove its feature values

  • Key: FUML15-16
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    According to UML semantics, "when an object is destroyed, it is no longer classified under any Classifier" [UML 2.5.1, 16.4.3.2], which is realized operationally in fUML. The fUML specification states, further, that "since such [destroyed] objects do not have any types, they will have neither attributes nor behaviors" [fUML 1.4, 8.10.1, Destroy Object Actions].

    However, while the Object::destroy operation (called by DestroyObjectActionActivation::destroyObject) does remove all of an Object's types, it leaves any FeatureValues that have been set for the Object. This means that the Object still effectively has values for the attributes of types it no longer has. This does not seem to be what would be expected from the text in either the UML or fUML specifications. It would be better if the FeatureValues of an Object were also removed when it was destroyed.

  • Reported: FUML 1.4b1 — Thu, 20 Dec 2018 19:33 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Update Object::destroy

    This is a simple change to the Object::destroy operation to clear the featureValues attribute as well as the types attribute.

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

fUML should specify semantics for activity partitions

  • Key: FUML15-15
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Activity partitions are currently excluded from the fUML subset "because they are a very general modeling construct in UML activities and their precise execution semantics is unclear" (see subclause 7.10.1 of the fUML 1.4 specification). And, in fact, despite more careful wording in the UML 2.5 specification than in previous versions of UML (see subclause 15.6.3.1 in the UML 2.5.1 specification), activity partitions still have a very broad set of possible uses with semantics that are not very precisely defined.

    Nevertheless, activity partitions are widely used by modelers to define "swim lanes" on activity diagrams. Further, they are used in SysML as one important way for allocating system functionality to subsystems. Therefore, it would be very helpful if fUML provided a precise semantics for at least the most common usage patterns for activity partitions in general, which could also provide a foundation for more specific usages in profiles such as SysML.

  • Reported: FUML 1.4b1 — Sat, 1 Dec 2018 21:47 GMT
  • Disposition: Closed; Out Of Scope — FUML 1.5
  • Disposition Summary:

    Out of scope

    The RTF has decided that this to large a change to the scope of fuml to be handled in the RTF process. Adding this capability to fUML would be better handled by an RFC or RFP process.

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

Base Semantics PSL version

  • Key: FUML15-5
  • Legacy Issue Number: 18796
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Update footnote 2 in subclause 10.1

    There has only been one internationally standardized version of PSL so far. However, just in case there may eventually be an update, the reference in footnote 2 in subclause 10.1 can be updated to specifically cite "ISO 18629-1:2004", which is the overview part of the standard as of 2004 (which is still the current version). In addition, the link http://www.nist.gov/psl now seems to redirect to a general NIST Engineering Laboratory page, not a page on PSL, so that should also be removed from the footnote.

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

Defects in Base Semantics from fUML

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

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

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

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

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

    This file can help to recognize the defects.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Update subclause 10.4.8.3

    Unfortunately, the file referenced in the issue is no longer available at the given link, and it was never physically attached to the issue (or, if it was at some point, it is now lost). Further, whether the base semantics are provably satisfiable has not seemed to be an issue in the successful use of fUML. Therefore, until someone takes the initiative to do further research and compile a new list of identified defects in the base semantics, it does not seem to be necessary to make any changes in this regard for now.

    On the other hand, the defect specifically identified in subclause 10.4.8.3 is, indeed, an error that should be corrected.

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

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

Remove unneeded inference rules from Base Semantics

  • Key: FUML15-8
  • Legacy Issue Number: 18799
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — FUML 1.5
  • Disposition Summary:

    Close, no change

    This issue has been carried over for some time. If there was any analysis provided with the original issue indicating which inference rules in the base semantics are currently not needed, it has been lost. Such inference rules, if there are in fact any, may not strictly be needed, but having them is not harmful, especially since it is unlikely that there are many, and there have been no further issues filed relating to this.

    Therefore, it seems safe to close this issue without changing the specification.

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

Actions outside the bUML

  • Key: FUML15-6
  • Legacy Issue Number: 18797
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — FUML 1.5
  • Disposition Summary:

    Close, no change

    The specification already does provide base semantics for both AcceptEventAction (in 10.4.13) and ReadIsClassifiedObjectAction (in 10.4.12).

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

Typo fixes

  • Key: FUML15-36
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    p94 8.6.2.2 Operations [2]

    // To be equal, the otherValue must also be a compund value [...]

    -> compound

    p123 8.7.2.3 Operations [7]

    // Create a new link with no type or properies.

    -> properties

    p146 8.8.2.7 2nd sentence

    The parameteValues for any output [...]

    -> parameterValues

    p170 8.9.2.4 Attributes

    • running : Boolean
      [...] enabled for execution once all its other prerequesites

    -> prerequisites

    p185 8.9.2.9 Operations [2]

    // Return true if [...], because control tokens are interchangable.

    -> interchangeable

    p205 8.9.2.21 Operations [6]

    // Otherwise, [...] and return a copy of it transfered to a new

    -> transferred

    p213 2nd para 2nd sentence

    The operation StructuredActivity
    Activcation::doAction checks the mustIsolate flag [...]

    -> Activation::doAction

    p230 Operations [16] run ()

    {{// Run this action activation and any outoging fork node [...]}

    -> outgoing

    p239 Operations [1]

    // [Note that this requires the behavior context to be compatible with [...]
    current contect object.]
    

    -> context

    p245 8.10.2.12 Associations 2nd bullet

    • selectedClause : clause
      The clause chosen from the set of selected Blauses [...]

    -> Clauses

    p285 8.10.2.37 Operations [1]

    TokenList incomingTakens = new tokenList();

    -> incomingTokens

    p289 Operations [13]

    // Terminate the execution of all contained node activations (whice

    -> which

    p291 8.10.2.42 Operations [1]

    // Return the position (counting from 1) of the first occurance [...]

    -> occurrence

    p314 10.1 2nd para 2nd bullet

    • Process Specification Language (PSL), a foundational axiomitization [...]

    This clause uses an embedded approach to axiomitization, which [...]

    -> axiomatization

  • Reported: FUML 1.4b1 — Sat, 8 Feb 2020 12:55 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Make editorial corrections

    It is agreed that the typos identified in the issue should be corrected.

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

Execution of an activity with a data store may never end

  • Key: FUML15-9
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Consider the following activity:

    Per the fUML execution model, when the ActivityFinalNodeActivation is fired, the ActivityExecution will terminate, and all nodes inside the activity group will be terminated (ActivityNodeActivationGroup::terminateAll()).

    When ForkNodeActivation is terminated, it will clear all its tokens. And, when the token is cleared, it will be removed from its holder (Token::withdraw()). In the case the holder of the token is a DataStoreNodeActivation, it then will remove that token (DataStoreNodeActivation::removeToken(Token))

    According to the specification of DataStoreNodeActivation:

    [1] removeToken ( in token : Token ) : Integer
    // Remove the given token from the data store, but then immediately
    // add a copy back into the data store and offer it (unless the
    // node activation has already been terminated).
    
    int i = super.removeToken(token);
    if (this.isRunning()) {
        super.addToken(token.copy());
        this.sendUnofferedTokens();
    }
    
    return i;
    

    If this.isRunning() returns true, it will continue to send unoffered tokens, leading to the execution never ending.

    Whether this.isRunning() returns true or false depends on the order of termination of DataStoreNodeActivation and ForkNodeActivation in the activity group. If DataStoreNodeActivation::terminate() is called before ForkNodeActivation::terminate(), it is fine (DataStoreNodeActivation::isRunning() will be false). If DataStoreNodeActivation::terminate() is called after ForkNodeActivation::terminate(), DataStoreNodeActivation::isRunning() is still true, and the execution does not end.

  • Reported: FUML 1.4b1 — Thu, 22 Nov 2018 19:00 GMT
  • Disposition: Resolved — FUML 1.5
  • Disposition Summary:

    Fix ForkNodeActivation::terminate

    The problem is that ForkNodeActivation::terminate clears its tokens before it terminates the activation. If it terminated first (i.e., called super.terminate() before calling self.clearTokens()), then, when it received another offer from the data store node, it would ignore it. ObjectNodeActivation::terminate used to have this same problem, but it was changed in fUML 1.3 as part of the update adding central buffer and data store nodes. Unfortunately, a similar change to ForkNodeActivation::terminate was not made at that time.

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

Remove unneeded inference rules from Base Semantics

  • Key: FUML14-8
  • Legacy Issue Number: 18799
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

Cover all ActivityNodes used in bUML

  • Key: FUML14-7
  • Legacy Issue Number: 18798
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

Actions outside the bUML

  • Key: FUML14-6
  • Legacy Issue Number: 18797
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

Base Semantics PSL version

  • Key: FUML14-5
  • Legacy Issue Number: 18796
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

Computer-readable version of the Base Semantics

  • Key: FUML14-4
  • Legacy Issue Number: 18795
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

Defects in Base Semantics from fUML

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

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

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

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

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

    This file can help to recognize the defects.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.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

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

Migrate fUML to UML 2.5.1

  • Key: FUML14-9
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 6.2 Changes to Adopted OMG Specifications of the Precise Semantics for UML State Machines (PSSM) Beta 1 specification document (ptc/17-04-04) states:

    The PSSM syntax is a subset of the UML 2.5.1 abstract syntax metamodel, and the required functionality formalized in PSSM is taken from that specified in UML 2.5.1. However, PSSM is also semantically based on fUML and PSCS. But the current versions of these standards, fUML 1.2.1 and PSCS 1.0 are based on UML 2.4. In order to avoid inconsistency, particularly given the sweeping reorganization of the UML abstract syntax metamodel adopted in UML 2.5, the fUML and PSCS syntax and semantics models have been migrated to UML 2.5.1 for use with PSSM, but with no change to their functionality. In addition, the fUML and PSCS models have been updated to use an approach for identifying and constraining their syntax subsets that is consistent with that used in PSSM.

    In adopting this specification, the fUML RTF was directed to update the fUML specification consistent with the migration of fUML syntax and semantics models top UML 2.5.1. Since the adoption of PSSM, fUML 1.3 has been approved as the current version of fUML, so the fUML 1.4 RTF now needs to carry out the migration of fUML 1.3 to UML 2.5.1 for fUML 1.4.

  • Reported: FUML 1.3 — Tue, 26 Dec 2017 23:05 GMT
  • Disposition: Resolved — FUML 1.4
  • Disposition Summary:

    Migrate fUML to UML 2.5.1

    Migrating fUML to UML 2.5.1 and adopting the new approach for identifying and constraining their syntax subsets (but with no change to fUML functionality), requires the following updates to the fUML specification document:

    • Remove the reflection of UML conformance levels in fUML and any references to the infrastructure/superstructure separation.
    • Update the normative references to UML 2.5.1 and the latest versions of the MOF, OCL and XMI specificatiopns.
    • Update subclause 6.1 Changes to Adopted Specifications to reflect the semantic clarifications in UML 2.5.1.
    • Update Clause 7 Abstract Syntax to reflect the UML 2.5.1 package structure and the new approach for specifying the fUML abstract syntax subset.
    • Update Clause 8 Execution Model to reflect the UML 2.5.1 package structure.

    The normative syntax and semantics XMI also need to be updated to reflect the new approach for specifying the abstract syntax subset and for the UML 2.5 reorganization.

  • Updated: Wed, 3 Oct 2018 14:20 GMT
  • Attachments:

Correction to the resolution to issue FUML14-10

  • Key: FUML14-21
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The resolution to issue FUML14-10 added code to ExecutionFactory::instantiateVistor to instantiate CentralBufferNodeActivation and DataStoreNodeActivation. However, since DataStoreNode is a kind of CentralBufferNode, and the test for CentralBufferNode comes before DataStoreNode, the test for CentralBufferNode needs to also test that the element being visited is not a DataStoreNode, in order to avoid incorrectly instantiating a CentralBufferNodeActivation for a DataStoreNodeActivation. The resolution to FUML14-10 neglects to do this.

  • Reported: FUML 1.3 — Thu, 10 May 2018 02:28 GMT
  • Disposition: Resolved — FUML 1.4
  • Disposition Summary:

    Correct resolution to issue FUML14-10

    Correct the error in FUML14-10 regarding the instantiation of DataStoreNodeActivation.

  • Updated: Wed, 3 Oct 2018 14:20 GMT

The ExecutionFactory class descriptions need to be updated in the specification for CentralBufferNode and DataStoreNode

  • Key: FUML14-10
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The resolution to Issue FUML13-4 added CentralBufferNode and DataStoreNode to the fUML abstract syntax subset for fUML 1.3. However, the revised text in the resolution neglected updating the description of the ExecutionFactory instantiateVisitor operation in order to instantiate the corresponding CentralBufferNodeActivation and DataStoreNodeActivationClasses. However, in the normative fUML_Semantics.xmi file for the execution model, the code for the operation LociL2::ExecutionFactoryL2::instantiateVisitor actually has been updated to instantiate CentralBufferNodeActivation and LociL3::ExecutionFactoryL3::instantiateVisitor has been updated to instantiate DataStoreNodeActivation. This needs to be reflected in the corresponding descriptions for these operations in the specification document.

  • Reported: FUML 1.3 — Mon, 19 Feb 2018 17:58 GMT
  • Disposition: Resolved — FUML 1.4
  • Disposition Summary:

    Update ExecutionFactory for CentralBufferNode and DataStoreNode

    Update the specification for ExecutionFactory as necessary.

  • Updated: Wed, 3 Oct 2018 14:20 GMT

Simplification to the resolution of Issue FUML13-1

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

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

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

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

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

    Update EventOccurrence::SendBehavior

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

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

Reference::equal should use Object::equals

  • Key: FUML13-26
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Update Reference::equals and add Object::equals

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

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

Refactor EventOccurrence to provide useful operations

  • Key: FUML13-25
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Add operations to EventOccurrence

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

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

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

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

Return type of getNextEvent is wrong in Figure 8.17

  • Key: FUML13-24
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Fix getNextEvent return type

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

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

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

  • Key: FUML13-23
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Change SignalInstance usage to EventOccurrence

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

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

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

Correction to the resolution to issue FUML13-25

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

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

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

    ­

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

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

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

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

    Remove unnecessary statement

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

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

Introduce CallEvent, AcceptCallAction and ReplyAction to keep consistency with PSSM

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

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

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

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

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

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

    Add CallEvent, AcceptCallAction and ReplyAction

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

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

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

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

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

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

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

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

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

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

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

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:

Association Roles in Figure 7.3 Flipped

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

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

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

    Fix Figure 7.3

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

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

"Debug" statements should be removed

  • Key: FUML13-29
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Remove "Debug" statements

    Agreed.

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

The specification of IntegerFunctions::Div is incorrect

  • Key: FUML13-28
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

    Correct postcondition

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

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

Input parameter activity nodes should fire first

  • Key: FUML13-27
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

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

    Update ActivityNodeActivationGroup::run

    Agreed.

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

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

  • Key: FUML13-32
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

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

    Remove identified note

    Agreed.

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

BasicInputOutput operations for reading and writing reals are missing

  • Key: FUML13-21
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

    Add readReal and writeReal operations

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

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

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

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

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

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

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

    Fix incorrect notation for unlimited natural values

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

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

Prose for semantics of AddStructuralFeatureValueAction required

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

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

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

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

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

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

    Add note on AddStructuralFeatureValueAction

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

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

Stand-alone owned behavior of BehavioredClassifier shall be possible

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

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

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

    Remove fUML_allowed_owned_behaviors constraint

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

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

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

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

Incomplete update to ClassifierBehaviorInvocationEventAccepter::invokeBehavior

  • Key: FUML13-14
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

    Correct ClassifierBehaviorInvocationEventAccepter::invokeBehavior

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

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

Bad event accepter removed from the waitingEventAccepter list

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

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

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

    waitingEventAccepters [ AcceptEventActionEventAccepter ]

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

    waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ]

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

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

    matchingEventAccepterIndexes [ 1 ]

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

    waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ]

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

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

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

    Correct dispatchNextEvent

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

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

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

Error in RealValue::toString

  • Key: FUML13-20
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

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

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

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

    Correct RealValue::toString

    Agreed.

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

Computer-readable version of the Base Semantics

  • Key: FUML13-7
  • Legacy Issue Number: 18795
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

Defects in Base Semantics from fUML

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

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

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

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

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

    This file can help to recognize the defects.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

The fUML subset should support the raising and handling of exceptions

  • Key: FUML13-5
  • Legacy Issue Number: 15989
  • Status: closed  
  • Source: 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

Remove unneeded inference rules from Base Semantics

  • Key: FUML13-11
  • Legacy Issue Number: 18799
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

Cover all ActivityNodes used in bUML

  • Key: FUML13-10
  • Legacy Issue Number: 18798
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

Actions outside the bUML

  • Key: FUML13-9
  • Legacy Issue Number: 18797
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

Base Semantics PSL version

  • Key: FUML13-8
  • Legacy Issue Number: 18796
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.3
  • Disposition Summary:

    Defer

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

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

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

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

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

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

    Recommended solution:

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

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

    Invoke classifier behaviors from the event dispatch loop

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

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

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

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

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

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

Extensional values should have an unique identifier

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

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

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

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

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

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

    return super.toString();

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

    Normatively define IDs for extensional values

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

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

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

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

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

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

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

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

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

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

    Update StructuredValue

    Agreed.

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

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

RemoveStructuralFeatureValueAction: Removal of links does not consider provided input value

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

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

    The following code could be a resolution to this issue:

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

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

    >>> if(inputValue != null)

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

    ...
    }
    }

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

    Update RemoveStructuralFeatureValueActionActivation

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

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

Certain Boolean flags are not properly initialized in some cases

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

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

    Subclauses: 8.5.2.2.4 ActivityNodeActivation, 8.6.2.2.1 ActionActivation and 8.6.4.2.1 AcceptEventActionActivation

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

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

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

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

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

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

    Add attribute initializations

    Agreed.

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

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

The OCL for CallBehaviorAction::proper_context has an error

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

    The current OCL for the proper_context constraint on CallBehaviorAction is

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

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

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

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

    Correct the OCL

    Agreed.

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

Problem with CallActionActivation: possible infinite loop in removeCallExecution()

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

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

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

    Update CallActionActivation::removeCallExecution

    Agreed.

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

7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance

  • Key: FUML12-2
  • Legacy Issue Number: 13510
  • Status: closed  
  • Source: NASA ( 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

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

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

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

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

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

    Change AcceptEventActionActivation::match

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

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

ReclassifyObjectAction handles removal of structural features incorrect

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

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

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

    Remove CompoundValue::removeFeatureValue

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

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

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

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

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

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

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

    Give the parameters type Status

    Agreed that the parameters should have type Status.

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

RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly

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

    RemoveStructuralFeatureValueActionActivation: Removing links with specified remove at value works incorrectly

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

    The following code would be the resolution for this bug:

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

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

    >>> ++i;
    }

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

    Update RemoveStructuralFeatureValueActionActivation

    Agreed.

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

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

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

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

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

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

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

    fUML constrains calls to behaviors with contexts

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

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

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

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

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

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

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

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

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

Correction of method UnlimitedNaturalValue.equals

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

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

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

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

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

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

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

    Update UnlimitedNaturalValue::equals

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

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

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

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

ListFunctions should have a ListConcat behavior

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

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

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

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

    Add ListFunctions::ListConcat

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

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

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

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

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

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

    Fix discrepencies

    The issue description is correct.

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

The Listener reception of Notification should have a name

  • Key: FUML12-18
  • Legacy Issue Number: 18513
  • 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: 9.3 Common

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

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

    Give the reception a name

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

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

FoundationalModelLibrary::Common::Notification should be public

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

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

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

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

    Make Notification public

    Agreed that Notification should be public.

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

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

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

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

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

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

    Change the result parameter direction to return

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

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

List parameters of ListFunctions should be non-unique.

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

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

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

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

    Make list parameters non-unique

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

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

The fUML subset should include central buffer nodes and data stores

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

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

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

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

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

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

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

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

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

    Update RemoveStructuralFeatureValueActionActivation

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

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

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

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

Objects with cyclic references cannot be converted to string representations

  • Key: FUML12-13
  • Legacy Issue Number: 18365
  • 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.3.2.2.2 CompundValue

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

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

    Update CompoundValue::toString

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

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

Computer-readable version of the Base Semantics

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

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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

Defects in Base Semantics from fUML

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

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

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

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

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

    This file can help to recognize the defects.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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

RealValue::toString puts too many digits in the mantissa

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

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

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

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

    Update RealValue::toString

    Agreed.

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

Problem with ActivityExecution::terminate

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

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

    Subclauses: 8.5.2.2.2 ActivityExecution

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

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

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

    Update ActivityExecution::terminate

    Agreed.

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

The fUML subset shuold support the raising and handling of exceptions

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

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

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

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

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

    Defer

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

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

Remove unneeded inference rules from Base Semantics

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

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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

Cover all ActivityNodes used in bUML

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

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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

Actions outside the bUML

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

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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

Base Semantics PSL version

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

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Disposition: Deferred — FUML 1.2
  • Disposition Summary:

    Defer

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

DecisionNodeActivation can send offers to multiple outgoing edges

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

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

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

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

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

Having a fork node as initial enabled node does not work

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

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

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

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

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

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

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

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

    Revised Text:
    None.
    Disposition: Closed, No Change

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

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

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

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

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

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

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

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

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

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

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

ExecutionFactoryL2::instantiateVistor duplicates code from ExecutionFactorL3::instatiateVistor

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

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

    Subclause: 8.2.3.2.1 ExecutionFactoryL2

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

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

    agreed

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

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

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

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

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

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

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

Error in check for enable nodes