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

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

  • Acronym: FUML
  • Issues Count: 14
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

repeated constraint

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

    constraint 3 is a repetition of constraint 1

  • Reported: FUML 1.4 — Sun, 4 Aug 2019 17:07 GMT
  • Updated: Mon, 5 Aug 2019 18:53 GMT

Missing class descriptions for expansion region activations

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

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

  • Reported: FUML 1.4 — Sat, 18 May 2019 19:00 GMT
  • Updated: Sat, 18 May 2019 19:00 GMT

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: open  
  • 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
  • Updated: Mon, 6 May 2019 00:11 GMT

Destroying an object should remove its feature values

  • Key: FUML15-16
  • Status: open  
  • 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
  • Updated: Mon, 6 May 2019 00:11 GMT

Inv function for Real types signature is wrong

  • Key: FUML15-19
  • Status: open  
  • Source: Technische Universit├Ąt Ilmenau ( Francesco Bedini)
  • Summary:

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

  • Reported: FUML 1.4 — Thu, 28 Mar 2019 15:13 GMT
  • Updated: Mon, 6 May 2019 00:11 GMT

Execution of an activity with a data store may never end

  • Key: FUML15-9
  • Status: open  
  • 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
  • Updated: Mon, 6 May 2019 00:11 GMT
  • Attachments:

fUML should allow association ends that are not association owned

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

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

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

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

  • Reported: FUML 1.4 — Wed, 24 Apr 2019 02:16 GMT
  • Updated: Wed, 24 Apr 2019 02:16 GMT

fUML should not require signal receptions

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

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

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

  • Reported: FUML 1.4 — Tue, 23 Apr 2019 23:20 GMT
  • Updated: Tue, 23 Apr 2019 23:20 GMT

fUML should include association classes

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

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

  • Reported: FUML 1.4 — Mon, 18 Mar 2019 14:16 GMT
  • Updated: Mon, 18 Mar 2019 14:16 GMT

The fUML threading model should be made explicit

  • Key: FUML15-11
  • Status: open  
  • 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
  • Updated: Sun, 2 Dec 2018 12:46 GMT

fUML should specify semantics for activity partitions

  • Key: FUML15-15
  • Status: open  
  • 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
  • Updated: Sat, 1 Dec 2018 21:47 GMT

fUML should include interruptible activity regions

  • Key: FUML15-14
  • Status: open  
  • 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
  • Updated: Sat, 1 Dec 2018 21:37 GMT

fUML should include unmarshall actions

  • Key: FUML15-13
  • Status: open  
  • 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
  • Updated: Sat, 1 Dec 2018 21:29 GMT

fUML should include streaming

  • Key: FUML15-12
  • Status: open  
  • 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
  • Updated: Sat, 1 Dec 2018 21:19 GMT