1. OMG Mailing List
  2. Semantics of a Foundational Subset for Executable UML Models 1.3 (fUML) RTF

Open Issues

  • Issues not resolved
  • Name: fuml-rtf
  • Issues Count: 21

Issues Summary

Key Issue Reported Fixed Disposition Status
FUML15-29 Missing class descriptions for expansion region activations FUML 1.4 open
FUML15-17 Objects at the composite end of an association should be considered "owned objects" during the destruction of the object at the other end FUML 1.4b1 open
FUML15-16 Destroying an object should remove its feature values FUML 1.4b1 open
FUML15-19 Inv function for Real types signature is wrong FUML 1.4 open
FUML15-8 Remove unneeded inference rules from Base Semantics FUML 1.1 open
FUML15-6 Actions outside the bUML FUML 1.1 open
FUML15-5 Base Semantics PSL version FUML 1.1 open
FUML15-9 Execution of an activity with a data store may never end FUML 1.4b1 open
FUML15-3 Defects in Base Semantics from fUML FUML 1.1 open
FUML15-28 fUML should allow association ends that are not association owned FUML 1.4 open
FUML15-27 fUML should not require signal receptions FUML 1.4 open
FUML15-18 fUML should include association classes FUML 1.4 open
FUML15-11 The fUML threading model should be made explicit FUML 1.4b1 open
FUML15-15 fUML should specify semantics for activity partitions FUML 1.4b1 open
FUML15-14 fUML should include interruptible activity regions FUML 1.4b1 open
FUML15-13 fUML should include unmarshall actions FUML 1.4b1 open
FUML15-12 fUML should include streaming FUML 1.4b1 open
FUML15-7 Cover all ActivityNodes used in bUML FUML 1.1 open
FUML15-4 Computer-readable version of the Base Semantics FUML 1.1 open
FUML15-2 The fUML subset should support the raising and handling of exceptions FUML 1.0 open
FUML15-1 Annex on normative XMI for fUML FUML 1.0b2 open

Issues Descriptions

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

Remove unneeded inference rules from Base Semantics

  • Key: FUML15-8
  • Legacy Issue Number: 18799
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Updated: Mon, 6 May 2019 00:11 GMT

Actions outside the bUML

  • Key: FUML15-6
  • Legacy Issue Number: 18797
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Updated: Mon, 6 May 2019 00:11 GMT

Base Semantics PSL version

  • Key: FUML15-5
  • Legacy Issue Number: 18796
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 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:

Defects in Base Semantics from fUML

  • Key: FUML15-3
  • Legacy Issue Number: 18794
  • Status: open  
  • Source: PhD Student ( Alessandro Gerlinger Romero)
  • Summary:

    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.

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Updated: Mon, 6 May 2019 00:11 GMT

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

Cover all ActivityNodes used in bUML

  • Key: FUML15-7
  • Legacy Issue Number: 18798
  • Status: open  
  • Source: Anonymous
  • Summary:

    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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Updated: Fri, 5 Oct 2018 19:13 GMT

Computer-readable version of the Base Semantics

  • Key: FUML15-4
  • Legacy Issue Number: 18795
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: FUML 1.1 — Sun, 30 Jun 2013 04:00 GMT
  • Updated: Fri, 5 Oct 2018 19:13 GMT

The fUML subset should support the raising and handling of exceptions

  • Key: FUML15-2
  • Legacy Issue Number: 15989
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: FUML 1.0 — Wed, 26 Jan 2011 05:00 GMT
  • Updated: Fri, 5 Oct 2018 19:13 GMT

Annex on normative XMI for fUML

  • Key: FUML15-1
  • Legacy Issue Number: 14979
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: FUML 1.0b2 — Fri, 15 Jan 2010 05:00 GMT
  • Updated: Fri, 5 Oct 2018 19:13 GMT