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

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

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

Issues Descriptions

fUML should include streaming

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

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

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

    Add semantics for streaming

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

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

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

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

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

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

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

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

fUML should include unmarshall actions

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

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

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

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

    Add UnmarshallAction

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

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

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

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

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

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

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

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

    Update DestroyObjectActionActivation::destroyObject

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

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

ReturnInformation is missing operations

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

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

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

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

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

    Add ReturnInformation operation descriptions

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

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

Destroying an object should remove its feature values

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

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

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

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

    Update Object::destroy

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

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

Typo fixes

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

    p94 8.6.2.2 Operations [2]

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

    -> compound

    p123 8.7.2.3 Operations [7]

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

    -> properties

    p146 8.8.2.7 2nd sentence

    The parameteValues for any output [...]

    -> parameterValues

    p170 8.9.2.4 Attributes

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

    -> prerequisites

    p185 8.9.2.9 Operations [2]

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

    -> interchangeable

    p205 8.9.2.21 Operations [6]

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

    -> transferred

    p213 2nd para 2nd sentence

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

    -> Activation::doAction

    p230 Operations [16] run ()

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

    -> outgoing

    p239 Operations [1]

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

    -> context

    p245 8.10.2.12 Associations 2nd bullet

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

    -> Clauses

    p285 8.10.2.37 Operations [1]

    TokenList incomingTakens = new tokenList();

    -> incomingTokens

    p289 Operations [13]

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

    -> which

    p291 8.10.2.42 Operations [1]

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

    -> occurrence

    p314 10.1 2nd para 2nd bullet

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

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

    -> axiomatization

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

    Make editorial corrections

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

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

The fUML threading model should be made explicit

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

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

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

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

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

    Defer

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

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

fUML should specify semantics for activity partitions

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

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

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

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

    Out of scope

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

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

fUML should include interruptible activity regions

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

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

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

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

    Out of scope

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

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

Execution of an activity with a data store may never end

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

    Consider the following activity:

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

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

    According to the specification of DataStoreNodeActivation:

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

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

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

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

    Fix ForkNodeActivation::terminate

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

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