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.)

Update LoopNodeActivation

Agreed.

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.

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.

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

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.

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.

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.

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)

...
}
}

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.

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.

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.

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.

Correct the OCL

Agreed.

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

Update CallActionActivation::removeCallExecution

Agreed.

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'

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.

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.

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.

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.

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.

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.

Give the parameters type Status

Agreed that the parameters should have type Status.

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)

>>> ++i;
}

Update RemoveStructuralFeatureValueActionActivation

Agreed.

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

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.

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

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.

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.

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.

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.’

Fix discrepencies

The issue description is correct.

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.

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.

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.

Make Notification public

Agreed that Notification should be public.

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”.

Change the result parameter direction to return

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

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.

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.

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.

Defer

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

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.

Defer

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

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.

Defer

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

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

Defer

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

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.

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.

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).

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.

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.)

Update LoopNodeActivation::doStructuredActivity

Agreed.

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.

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.

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).

Defer

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

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.

Defer

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

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.

Update RealValue::toString

Agreed.

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.

Update ActivityExecution::terminate

Agreed.

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.

Defer

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

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

Defer

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

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

Defer

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

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.

Defer

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

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

Defer

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