FUML — Revise fUML to be based on UML 2.3

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

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

Relevant semantic issues include, in particular:

• 6111 Reentrancy 1

• 9863 Section: Actions – Output of read actions for no values

• 9870 Actions on non-unique properties with location specified

• 9858 Default weight

• 9873 Section: Common Behavior – isReentrant should default to true

• 10045 11.3.47 on StructuralFeatureAction (and related sections on subclasses)

• 11646 StructuredActivityNode

• 13898 what's the difference > between weight=1 and weight=*?

• 13914 Clarify that input pins do not accept more tokens than their actions can immediately consume

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

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

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

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