According to the class description, ObjectActivation has the following method signatures:

• getNextEvent ( ) : EventOccurrence
• send ( in eventOccurrence : eventOccurrence )

However, on Figure 8.17 it has the following, which remained from the 1.1 version of the spec:

• getNextEvent () : SignalInstance
• send (signalInstace : SignalInstance)

Figure 8.17 should be updated to have the current signatures.

In the last three paragraphs of page 53, under sub-section "Behavioral Semantics", references to Figure 8.14 and 8.15 are used. However, these references should most probably be provided for Figure 8.1 and Figure 8.2 instead, which are located on top of page 54.

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.

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.

constraint 3 is a repetition of constraint 1

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 fUML 1.5 RTF agrees that this issue should be resolved but, due to lack of time, is deferring it to a future 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 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

Update Object::destroy

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

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

Close, no change

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

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

Make editorial corrections

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

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.

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.

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

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.

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

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

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

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

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

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.

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

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

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

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

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.

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.

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

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

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.

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.

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.

Correct resolution to issue FUML14-10

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

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.

Update ExecutionFactory for CentralBufferNode and DataStoreNode

Update the specification for ExecutionFactory as necessary.

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.

Update EventOccurrence::SendBehavior

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

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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

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.

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.

Remove "Debug" statements

Agreed.

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

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.

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.

Update ActivityNodeActivationGroup::run

Agreed.

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.

Remove identified note

Agreed.

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

Correct dispatchNextEvent

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

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.

Remove sentence

Agreed.

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.

Correct RealValue::toString

Agreed.

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

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.

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.

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.