Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

  • Acronym: UML
  • Issues Count: 49
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-804 Link incorrect UML 2.5.1 open
UMLR-802 Owner has to do with Namespaces UML 2.5.1 open
UMLR-803 StateMachine initial transition inconsistency UML 2.5.1 open
UMLR-801 Figure 9.1: duplicate graphical element "NamedElement" UML 2.5.1 open
UMLR-800 Typo in caption for figure 14.14 UML 2.5.1 open
UMLR-799 Behavioral Classification UML 2.5.1 open
UMLR-798 Unclear how StateInvariants on a Lifeline identify the next OccurranceSpecification UML 2.5.1 open
UMLR-797 unclear whether imported elements are merged by package merge UML 2.5.1 open
UMLR-796 MultiplicityElement.isOrdered: Abstract Syntax Metamodel does not match the specification document UML 2.5.1 open
UMLR-795 Inheritance of extension not explicitly stated UML 2.5.1 open
UMLR-794 Association wrong here UML 2.5.1 open
UAF13-18 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
UMLR-793 The last link on the page about Diagram Definition is dead UML 2.5.1 open
UMLR-792 Dead URL link for XMI UML 2.5.1 open
UMLR-791 https/www.omg.org/spec/UML/ URL is not valid (typo) UML 2.5.1 open
UMLR-790 UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement UML 2.5.1 open
UMLR-789 Receptions should be redefinable elements as operations are. UML 2.5.1 open
UMLR-788 Inconsistent use of unspecified and unlimited for the multiplicity notation UML 2.5.1 open
UMLR-787 There is not a way to do this... UML 2.5.1 open
UMLR-786 removeAt_and_value wrong UML 2.5.1 open
UMLR-785 Misleading Link UML 2.5.1 open
UMLR-784 Include ordering UML 2.5.1 open
UMLR-783 need to include setup UML 2.5.1 open
UMLR-782 switch LoopNode for ConditionalNode UML 2.5.1 open
UMLR-781 " in state name UML 2.5.1 open
UMLR-780 Local Transitions conflict UML 2.5.1 open
UMLR-779 OCL and Text Mismatch UML 2.5.1 open
UMLR-777 Lambda's,Traits and Generics UML 2.5.1 open
UMLR-778 Textual "Markdown" visualization UML 2.5.1 open
UMLR-776 OCL for excludeCollisions in Namespace element seems incorrect UML 2.5.1 open
UMLR-775 An Activity Edge cannot connect to Activities UML 2.5.1 open
UMLR-774 Needs to be a constraint between AggregationKind and subsetting UML 2.5.1 open
UMLR-773 Please make it clear what is being modeled behind the scenes for figures UML 2.5.1 open
UMLR-772 Please provide more detail on redefinition UML 2.5.1 open
UMLR-771 UML.xmi is not well-formed UML 2.5.1 open
OCL25-217 UML 2.5.1 embedded OCL syntax errors UML 2.5.1 open
UMLR-770 PackageImport Missing for Type Generalization UML 2.5.1 open
UMLR-769 Nested Port not supported on Sequence Diagram UML 2.5.1 open
UMLR-768 InteractionUse can not reference a CollaborationUse (as shown in Figure 17.24) UML 2.5.1 open
UMLR-767 Error in Loop fragment deffinition UML 2.5.1 open
UMLR-766 Duplicate section titles UML 2.5.1 open
UMLR-761 Property.Association is not a union UML 2.5.1 open
UMLR-764 Specializations of an Association Class UML 2.5.1 open
UMLR-758 Duplicated xmi:id values in UML.xmi UML 2.5.1 open
UMLR-756 Behavior::behavioredClassifier bodycondition is serialized as a precondition UML 2.5.1 open
UMLR-755 Unclear whether current State during Transition is the target State UML 2.5.1 open
UMLR-754 Figure 9.11 misses attribute name UML 2.5.1 open
UMLR-751 The definition of relative Time Events is ambigious UML 2.5.1 open
UMLR-747 Typo UML 2.5.1 open

Issues Descriptions

Link incorrect

  • Key: UMLR-804
  • Status: open  
  • Source: me.com ( Thomas Kilian)
  • Summary:

    http://www.omg.org/report_issue.htm does not exist and it should actually point to this very page. Alternatively think about noz using a dedicated link and suggest to follow from the main page.

  • Reported: UML 2.5.1 — Mon, 22 May 2023 22:02 GMT
  • Updated: Thu, 25 May 2023 19:20 GMT

Owner has to do with Namespaces

  • Key: UMLR-802
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    NOTE. The concept of parent (a generalization relationship between Classifiers) is unrelated to the concept of owner (a composition relationship between instances).

    a composition relationship between instances).

    is not what is meant by "composition relationship"... this is not ownership

  • Reported: UML 2.5.1 — Sun, 14 May 2023 02:28 GMT
  • Updated: Tue, 16 May 2023 07:49 GMT

StateMachine initial transition inconsistency

  • Key: UMLR-803
  • Status: open  
  • Source: Private ( Eshar Gal)
  • Summary:

    The specification state in page 312 that the only transition from an initial Pseudostate should never have an associated trigger or guard:
    “It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.”

    Page 361 specify a constraint for the trigger (initial_transition):
    “An initial Transition at the topmost level Region of a StateMachine that has no Trigger.”
    inv: (source.oclIsKindOf(Pseudostate) and container.stateMachine->notEmpty()) implies trigger->isEmpty()

    With the above, an inconsistency appears in page 344, Figure 14.44:
    A trigger associated transition originating from the initial pseudostate.

  • Reported: UML 2.5.1 — Mon, 15 May 2023 13:52 GMT
  • Updated: Mon, 15 May 2023 18:17 GMT

Figure 9.1: duplicate graphical element "NamedElement"

  • Key: UMLR-801
  • Status: open  
  • Summary:

    the "NamedElement" is twice on the diagram, once in the upper left corner ("NW") and once at the bottom right to the center ("SSO").

    I think the lower right one can go.

  • Reported: UML 2.5.1 — Tue, 14 Feb 2023 19:13 GMT
  • Updated: Fri, 17 Mar 2023 18:14 GMT

Typo in caption for figure 14.14

  • Key: UMLR-800
  • Status: open  
  • Source: n/a ( Jan Mewes)
  • Summary:

    Observed:

    Figure 14.14 Submachine Sate that uses an exit point

    Expected:

    Figure 14.14 Submachine State that uses an exit point

  • Reported: UML 2.5.1 — Sun, 12 Feb 2023 06:01 GMT
  • Updated: Fri, 17 Mar 2023 14:57 GMT

Behavioral Classification

  • Key: UMLR-799
  • Status: open  
  • Source: OptConsult Company ( Himu)
  • Summary:

    As-Is Reads:
    13.2.3.1 A Behavior is a specification of events that may occur dynamically over time (see also sub clause 13.3 on the explicit modeling of Events in UML).
    13.1 UML provides Behavior, Event, and Trigger constructs to model the corresponding fundamental concepts of behavioral modeling.

    Suggestion:
    1) Change Ch13 Title AS-IS (Common Behavior) to (say, Mutability).
    Rational: This will free the word Behavior to specify something as follows.
    It is possible (and desirable) to treat the fundamental constructs of modeling, viz. Behavior, Event, and Trigger, (like other constructs of UML) independent of each other.
    For example, it is possible to conceptualize 'Behavior' as an attribute of relevant class.
    Similarly, Event and Trigger.
    In the paradigm of Object Management, such classification of one or more latent capabilities of objects, can and should simplify some of the problems with modeling (in my humble opinion).
    Thank you for letting me express an opinion...
    PS: Please accept my apologies, if this is already addressed in UML 2.6.

  • Reported: UML 2.5.1 — Mon, 23 Jan 2023 04:27 GMT
  • Updated: Tue, 24 Jan 2023 14:35 GMT

Unclear how StateInvariants on a Lifeline identify the next OccurranceSpecification

  • Key: UMLR-798
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    StateInvariants cover a Lifeline and define a Constraint. The specification says:

    17.2.3.5 StateInvariant
    [...] The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

    Very well, but how is the "next" OccurrenceSpecification identified?

    My first guess was that the Lifeline would have an ordered set of InteractionFragments (both OccurrenceSpecification and StateInvariant are such fragments). But, no, there is none. events:OccurrenceSpecification is ordered, but stateInvariant:StateInvariant is not, and both are subsets of coveredBy:InteractionFragment, which is also not ordered.

    The only way I can think of is to identify the next OccurrenceSpecification by setting it as the constrainedElement of the Constraint. Actually, that really makes sense and should be mandatory.

    Suggestion
    Replace sentence in 17.2.3.5 StateInvariant

    The Constraint is evaluated immediately prior to the execution of the next OccurrenceSpecification.

    with

    The Constraint must constrain an OccurranceSpecification of the covered Lifeline. It will be evaluated immediately before this occurrance.

    Replace sentence in Notation 17.2.4.5 StateInvariant

    The possible associated Constraint is shown as text in curly brackets on the lifeline.

    with

    The possible associated Constraint is shown as text in curly brackets on the lifeline immediately above the constrained OccurrenceSpecification.

    Add a constraint to 17.12.25
    constrains_one_OccurrenceSpecification
    self.invariant.constrainedElement->size()=1
    AND
    self.covered.events->includes(self.invariant.constrainedElement->first())

  • Reported: UML 2.5.1 — Tue, 13 Dec 2022 10:56 GMT
  • Updated: Tue, 13 Dec 2022 10:56 GMT

unclear whether imported elements are merged by package merge

  • Key: UMLR-797
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    When two packages have a merge relationship, the elements with the same name and metatype are merged. Does that include the elements imported into the package? The specification says:

    the contents of the Package to be merged are combined with the contents of the receiving Package.

    merged element – refers to a model element that exists in the merged package.

    I expected that "content" means packagedElement and "exists" means that the merged package is the owningPackage.

    However, according to one member of the taskforce, the imported elements are merged. So, it probably does mean member and memberNamespace.

    From the text of the specification, I cannot derive that. I propose to add a clarification.

    I attached an example diagram that shows the results of the two interpretations: A Class A is imported via PackageImport to Package P2 (the mergedPackage). In this Package no Class of this name is defined. Now P2 is merged into P3 (the receivingPackage), which owns a Class A. There are two interpretations possible:
    a) The resultingPackage P3 owns the result of merging P1::A with P3::A.
    b) The resultingPackage P3 owns P3::A

    In both cases the resultingPackage will also contain a PackageImport that imports P1::A, but since it already contains a Class with this name, it will not be added to the namespace.

  • Reported: UML 2.5.1 — Wed, 26 Oct 2022 15:13 GMT
  • Updated: Wed, 2 Nov 2022 17:40 GMT
  • Attachments:

MultiplicityElement.isOrdered: Abstract Syntax Metamodel does not match the specification document

  • Key: UMLR-796
  • Status: open  
  • Source: Danish Agency for Data Supply and Infrastructure ( Heidi Vanparys)
  • Summary:

    According to the UML 2.5.1, the default value for attribute isOrdered of abstract class MultiplicityElement is false, see clause 7.8.8.5 and see figure 7.10 in clause 7.5.2.

    However, this default value for isOrdered is not present in the Abstract Syntax Metamodel (the XMI file with file id ptc/18-01-01 present at https://www.omg.org/spec/UML/20161101/UML.xmi). In comparison, the default value for isUnique (true) is present in the XMI. See lines 12855-12873.

    <ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isOrdered" name="isOrdered">
    <type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
    <ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isOrdered-_ownedComment.0"
    body="For a multivalued multiplicity, this attribute specifies whether the values in an instantiation of this MultiplicityElement are sequentially ordered.">
    <annotatedElement xmi:idref="MultiplicityElement-isOrdered"/>
    </ownedComment>
    <defaultValue xmi:type="uml:LiteralBoolean"
    xmi:id="MultiplicityElement-isOrdered-_defaultValue"/>
    </ownedAttribute>
    <ownedAttribute xmi:type="uml:Property" xmi:id="MultiplicityElement-isUnique" name="isUnique">
    <type href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes.xmi#Boolean"/>
    <ownedComment xmi:type="uml:Comment" xmi:id="MultiplicityElement-isUnique-_ownedComment.0"
    body="For a multivalued multiplicity, this attributes specifies whether the values in an instantiation of this MultiplicityElement are unique.">
    <annotatedElement xmi:idref="MultiplicityElement-isUnique"/>
    </ownedComment>
    <defaultValue xmi:type="uml:LiteralBoolean"
    xmi:id="MultiplicityElement-isUnique-_defaultValue"
    value="true"/>
    </ownedAttribute>

    The result of this is that when I create custom diagrams illustrating specific parts from the UML metamodel, the default value for isOrdered is not shown in my UML tool.

  • Reported: UML 2.5.1 — Wed, 17 Aug 2022 08:33 GMT
  • Updated: Wed, 24 Aug 2022 19:40 GMT

Inheritance of extension not explicitly stated

  • Key: UMLR-795
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Fig. 12.21 shows Entity as a specialization of Bean... but Entity does not show any extensions... therefore Entity inherits its extensions from Bean... but nowhere in the standard does it explicitly say that extension relationship are inherited by subclasses... even though one could perhaps derive that from the fact that extensions are associations... it should be explicitly stated in the standard

  • Reported: UML 2.5.1 — Sat, 2 Jul 2022 19:51 GMT
  • Updated: Thu, 14 Jul 2022 15:40 GMT

Association wrong here

  • Key: UMLR-794
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    the sentence "EncapsulatedClassifiers to differentiate
    between them but without being directly coupled to them. Classes, Components, Associations and Collaborations are
    concrete metaclasses that use these capabilities."

    should have AssociationClass and not Association here... and does not even need AssociationClass because AssociationClass is a specialization of a Class...

    Association does not Specialize EncapsulatedClassifier

  • Reported: UML 2.5.1 — Sun, 8 May 2022 15:35 GMT
  • Updated: Thu, 19 May 2022 16:02 GMT

UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement

  • Key: UAF13-18
  • Status: open  
  • Source: Department of Navy ( James Ciarcia)
  • Summary:

    UML makes it hard/impossible to provide defaultValues for properties that have upper multiplicity higher than 1 since the defaultValue is limited to 1 ValueSpecification. While an OpaqueExpression could be used to provide a result of more than 1 element, this still requires execution of extra metaclass associations and the digital trail to Literals or InstanceValue's. Recommend changing the multiplicity to 0 .. *.

  • Reported: UML 2.5.1 — Mon, 31 Jan 2022 21:17 GMT
  • Updated: Fri, 22 Apr 2022 13:35 GMT




UML::Property.defaultValue has upper multiplicity of 1 even though Property is a MultiplicityElement

  • Key: UMLR-790
  • Status: open  
  • Source: Department of Navy ( James Ciarcia)
  • Summary:

    UML makes it hard/impossible to provide defaultValues for properties that have upper multiplicity higher than 1 since the defaultValue is limited to 1 ValueSpecification. While an OpaqueExpression could be used to provide a result of more than 1 element, this still requires execution of extra metaclass associations and the digital trail to Literals or InstanceValue's. Recommend changing the multiplicity to 0 .. *.

  • Reported: UML 2.5.1 — Mon, 31 Jan 2022 21:23 GMT
  • Updated: Mon, 7 Feb 2022 18:09 GMT

Receptions should be redefinable elements as operations are.

  • Key: UMLR-789
  • Status: open  
  • Source: Dassault Systemes ( Tautvydas Juska)
  • Summary:

    Both Operations and Receptions are Redefinable Elements. However, not we cannot redefine Receptions. This is caused because query isConsistentWith() specifies where we can redefine them or not. By default, this value is "False" and for operations, the value is set to "true", but for Receptions, the value is not specified, which means it is "False".
    We should make Receptions also redefinable elements as Operations are, which requires to specify isConsistentWith() query with "True" value.

  • Reported: UML 2.5.1 — Tue, 18 Jan 2022 08:51 GMT
  • Updated: Tue, 18 Jan 2022 21:27 GMT

Inconsistent use of unspecified and unlimited for the multiplicity notation

  • Key: UMLR-788
  • Status: open  
  • Source: ACM ( Christophe THIERRY)
  • Summary:

    The first paragraph p.35 states: << A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation containing a single star “” instead of “0..” multiplicity. >>
    The use of the term "unspecified upper bound" is not consistent with the sentence found 3 paragraphs above (on p.34): << The star character is used as part of a multiplicity specification to represent an unlimited upper bound. >> nor with the specification of the semantics related to this notation (on top of p.34): << A MultiplicityElement is unlimited if its upperBound has the UnlimitedNatural value of unlimited (“*”) >>.
    Solution: replace "unspecified upper bound" with "unlimited upper bound" in that sentence.

  • Reported: UML 2.5.1 — Mon, 22 Nov 2021 08:59 GMT
  • Updated: Wed, 24 Nov 2021 15:32 GMT

There is not a way to do this...

  • Key: UMLR-787
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    There is no metaclass for Link so there is no way to do this... in Fig. 9.30 you have two InstanceSpecification being connected by a link... but how do you do this?... you can't do it with a Connector because a Connector is between two ConnectableElements and
    an InstanceSpecification is not a ConnectableElement...

    think that there needs to be a Link metaclass specifically for this purpose..

  • Reported: UML 2.5.1 — Mon, 13 Sep 2021 00:38 GMT
  • Updated: Mon, 20 Sep 2021 10:30 GMT

removeAt_and_value wrong

  • Key: UMLR-786
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    It says "ReadVariableActions" and it should say "RemoveVariableValueAction"

  • Reported: UML 2.5.1 — Wed, 1 Sep 2021 17:52 GMT
  • Updated: Wed, 8 Sep 2021 14:24 GMT

Misleading Link

  • Key: UMLR-785
  • Status: open  
  • Source: Siemens Mobility ( Philipp Rost)
  • Summary:

    Clicking on "A_bodyPart_loopNode::loopNode" within "bodyPart : ExecutableNode [0..*] (opposite A_bodyPart_loopNode::loopNode)" doesn't guide you to the correct Object "16.15.6 A_bodyPart_loopNode [Association]" on page 542. It redirects onto "bodyPart" itself.

  • Reported: UML 2.5.1 — Wed, 1 Sep 2021 09:06 GMT
  • Updated: Wed, 8 Sep 2021 14:24 GMT

Include ordering

  • Key: UMLR-784
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    constraints matching_loop_variables and matching_result_pins need to include ordering

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 06:29 GMT
  • Updated: Mon, 9 Aug 2021 14:02 GMT

need to include setup

  • Key: UMLR-783
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

     setup_test_and_body
    The test and body parts of a ConditionalNode must be disjoint with each other.

    this should say "setup, test, and body parts"

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 04:53 GMT
  • Updated: Mon, 9 Aug 2021 14:01 GMT

switch LoopNode for ConditionalNode

  • Key: UMLR-782
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

     setup_test_and_body
    The test and body parts of a ConditionalNode must be disjoint with each other.

    should be LoopNode instead of ConditionalNode

  • Reported: UML 2.5.1 — Mon, 9 Aug 2021 04:51 GMT
  • Updated: Mon, 9 Aug 2021 14:01 GMT

" in state name

  • Key: UMLR-781
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    The standard says

    "(Alternatively, a Transition of kind local can be shown as a
    Transition leaving a State symbol containing the text “*.” The Transition is then considered to belong to the
    enclosing composite State.)"

    What does this mean, how is this done, why would one do this?... either there needs to be an example of this in the standard or it needs to be removed

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 15:48 GMT
  • Updated: Mon, 5 Apr 2021 17:03 GMT

Local Transitions conflict

  • Key: UMLR-780
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Standard says

    "Transitions of the kind local can originate from the border of the containing composite State, or one of its entry
    points, or from a Vertex within the composite State."

    yet the OCL Constraint for Transition pg. 361 is

    state_is_local
    A Transition with kind local must have a composite State or an entry point as its source.
    inv: (kind = TransitionKind::local) implies
    ((source.oclIsKindOf (State) and source.oclAsType(State).isComposite) or
    (source.oclIsKindOf (Pseudostate) and source.oclAsType(Pseudostate).kind =
    PseudostateKind::entryPoint))

    which does not include "a Vertex within the composite State"

    the diagram fig 14.34 Local Transition does not include "a Vertex within the composite State" but the fig. 14.35 External Transitions

    something is wrong here... is the S1 to S2 transition in fig 14.35 correct... then the text is wrong... otherwise other things have to change...

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 15:26 GMT
  • Updated: Mon, 5 Apr 2021 15:32 GMT

OCL and Text Mismatch

  • Key: UMLR-779
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    same_classifier
    The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the
    classifier that contains the interaction enclosing this lifeline.
    inv: represents.namespace->closure(namespace)->includes(interaction._'context')

    The text says ancestor which has to do with Generalization issues... yet the OCL deals with namespaces... Ancestors can be in different namespaces... so which is it, does the interaction need to be in the namespace of the ancestor... or does the interaction need to be contained somewhere in the namespace hierarchy... I am thinking it is Generalization over namespace

  • Reported: UML 2.5.1 — Sun, 4 Apr 2021 12:47 GMT
  • Updated: Mon, 5 Apr 2021 15:32 GMT

Lambda's,Traits and Generics

  • Key: UMLR-777
  • Status: open  
  • Source: N/A Transitioning ( Caleb Cushing)
  • Summary:

    So one issue I have noticed with UML over the last few years is the lack of a few types that have become much more prevalent.

    Specifically I'm thinking about Lambda's and Traits.

    I think Lambda, or anonymous functions, and method references can be represented with a class, anonymous or otherwise, using a generic of type <<lambda>>. But I feel as though that doesn't really call it out in the way I would generally like. I'm wondering if they should treated with a different shape when they're used. In some languages that are not java, these are not classes in any way shape or form (that I'm aware). Heh, maybe an arrow box with a name.

    Traits, or flat composition instead of multiple inheritance, similar to java's interfaces with default methods (though traits can have state). I suspect it'd be fine to represent these with the "class" using the generic <<trait>> but I don't know that using the -|> operator to show inheritance is actually appropriate, or even the -<> composition operator, since that seems like it's representing a different object of the same "aggregate root" (using the meaning of the term from domain driven design).

    Generics, UML doesn't really support this at all, By that I mean List<Bar>, I suppose you can but it in the text, but when you have an interface that takes a parameter, or a method, or whatever, it's kind of hard to represent in my opinion that the type is parameterized with other types. If I have a method that returns List<Bar>, there's no class of type List<Bar> that tooling would generally find. Of course you can simply use a one to many relationship, but if you're generating code in either direction, or using this for a more strictly guiding document, E.g. it's a List, not a Set, it's problematic.

    By the way, I don't know what version this happened in, but thanks for clarifying composition vs aggregation. though I think they're backwards from other industry language about aggregates and composition, at least composition seems to match the definition of an aggregate in DDD.

  • Reported: UML 2.5.1 — Fri, 5 Mar 2021 19:11 GMT
  • Updated: Fri, 5 Mar 2021 20:42 GMT

Textual "Markdown" visualization

  • Key: UMLR-778
  • Status: open  
  • Source: N/A Transitioning ( Caleb Cushing)
  • Summary:

    In modern development, git, and markdown have become very popular. While I don't think that markdown (CommonMark) needs to be explicitly supported, I think it would we good to take it into consideration. The idea being that this standard textual representation is readable in plain text format. I think that the mermaid.js browser plugin also does a nice job, by rendering the document when it's in a fenced code block. Having this would allow us to commit markdown (or whatever, that supports it) to our git repositories, or other things and have it rendered wherever we take it.

    An additional thing that may (or may not?) need to be considered, importing from existing "libraries" or "diagrams". One thing I don't like about these tools, especially for class diagrams, if I need to reuse the same class I have to completely recreate it. I think another thing that may want to be considered here, is hiding, if I import a "library" then I want to be able to hide some of its details, I may not want to show all methods in this diagram, for example. It could be argued though, that that is just a hazard of doing that. I don't feel that strongly about that. Speed of creation here is more important.

    references to some varying syntax, and are just examples, I'm certain their are many many more, by having a spec-ed syntax all of these variants could implement that as an option, solving the same problem that UML originally tried to resolve about people using visual communication formats and then standardizing that so that you could walk into an environment and know the "language".

    https://yuml.me/diagram/scruffy/class/samples
    https://mermaid-js.github.io/mermaid/#/
    https://sequencediagram.org/
    https://state-machine-cat.js.org/

  • Reported: UML 2.5.1 — Fri, 5 Mar 2021 19:27 GMT
  • Updated: Fri, 5 Mar 2021 19:36 GMT

OCL for excludeCollisions in Namespace element seems incorrect

  • Key: UMLR-776
  • Status: open  
  • Source: Deniz Eren ( Deniz Eren)
  • Summary:

    Hi,

    UML machine consumable xmi 2.5.1 xmi-id "Namespace-excludeCollisions" has OCL:

    result = (imps->reject(imp1 | imps->exists(imp2 | not imp1.isDistinguishableFrom(imp2, self))))

    However clearly it should have "imp1 <> imp2" like this:

    result = (imps->reject(imp1 | imps->exists(imp2 | imp1 <> imp2 and not imp1.isDistinguishableFrom(imp2, self))))

    Best regards,
    Deniz

  • Reported: UML 2.5.1 — Fri, 29 Jan 2021 12:43 GMT
  • Updated: Fri, 29 Jan 2021 17:58 GMT

An Activity Edge cannot connect to Activities

  • Key: UMLR-775
  • Status: open  
  • Source: private person ( Andreas Warnke)
  • Summary:

    Problem:
    A CommunicationPath is a ActivityEdge. An ActivityEdge has source and target properties of type ActivityNode. But an Activity is not an ActivityNode. So the CommunicationPath link vom Activity to Activity is invalid.
    Such a link should be valid - otherwise the diagram in 15.5.5 Examples is wrong.

    Info: Some tools seem to simply allow this:
    <ownedBehavior xmi:type="uml:Activity" xmi:id="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" name="Create Title Entry" visibility="public" isReadOnly="false" isSingleExecution="false">
    ...
    <edge xmi:type="uml:ControlFlow" xmi:id="EAID_B750FB8E_8132_4569_99C2_8C0DFD11F144" visibility="public" source="EAID_940293B7_001A_4d5d_BCFE_24CB874155E3" target="EAID_D4190768_7F03_4546_B5E5_38E4DBE56F19"/>
    or
    https://github.com/awarnke/crystal_facet_uml/blob/master/example_diagrams/export_test/export_test_15_activity.xmi

    Proposed fix: Would it make sense to make an Activity derive from ActivityNode instead of Behavior, and ActivityNode derived from Behavior?

    Maybe i simply understood the current specification wrong - then please ignore my Comment.
    Regards
    A. Warnke

  • Reported: UML 2.5.1 — Sat, 12 Dec 2020 11:58 GMT
  • Updated: Mon, 4 Jan 2021 08:44 GMT

Needs to be a constraint between AggregationKind and subsetting

  • Key: UMLR-774
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    if AggregationKind is ordered

    {none,shared,composite}

    low to high... the there should be a constraint on a subsetting property such that the subsetting property's aggregationkind is at least that of the subsetted property or greater

  • Reported: UML 2.5.1 — Thu, 12 Nov 2020 13:37 GMT
  • Updated: Tue, 17 Nov 2020 14:28 GMT

Please make it clear what is being modeled behind the scenes for figures

  • Key: UMLR-773
  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    As an example, it is stated here that
    "The values of the ownedAttributes of a Stereotype (or its generalizations) applied to a model element can be shown in one
    of the following three ways:
    1 As part of a comment symbol connected to the graphic node representing the model element."
    Later it says "Within a comment symbol, or, if displayed before or above the model element’s name, the Property values from a specific Stereotype are optionally preceded with the name of the applied Stereotype within a pair of guillemets. This is useful if values of more than one applied stereotype should be shown.".
    I have not found within this specification in either the semantics or notation sections an explanation for what Comment symbols are representing with regards to this. Since there is the InstanceSpecification construct I do not believe this is expected to be manually typed.
    I can understand one scenario where I create an InstanceSpecification to represent an instance of a Stereotype and I could have a Comment symbol represent only that. That could be extended to say that a Comment symbol should present information from more than one stereotype instance.Alternatively it could be meant that you define an InstanceSpecification and InstanceValues referenced by slots could reference the stereotype instances and that these should be decomposed as stated. However, 9.8.4 said, for an InstanceValue, that only the name of the referenced InstanceSpecification should be shown.
    The specification must make it clear what should be modeled for a given figure, each time you present something that has not already been described, to avoid tool vendors coming to conclusions which could be different from those intended.

  • Reported: UML 2.5.1 — Fri, 16 Oct 2020 08:58 GMT
  • Updated: Tue, 27 Oct 2020 19:33 GMT

Please provide more detail on redefinition

  • Key: UMLR-772
  • Status: open  
  • Source: UNICOM Systems ( Mark Gregory)
  • Summary:

    I am attempting to implement support for UML 2.5.1.
    When handling property redefinition based on the uml Abstract Syntax Metamodel.xmi :
    Given this sort of construct in the xmi..(newproperty, baseproperty xmi:ids added for reference in my question below)
    <ownedAttribute xmi:type="uml:Property" xmi:id="newproperty"..">
    <redefinedProperty xmi:idref="baseproperty"/>
    I need to understand whether it is correct to..
    a) assume that newproperty is being defined from scratch (meaning: clean slate; a brand new property)
    or b) the property being redefined (baseproperty) should be adjusted based on what changes are specified in the xmi

    In our current implementation it is rather difficult for us to accommodate a change in name of the existing property so I propose that newproperty is a subset baseproperty, with the additional restriction on baseproperty that it becomes a derived union.
    This paper..
    "On the Relationships Between Subsetting,Redefinition and Association Specialization"
    https://uni-koblenz.de/~ist/documents/Bildhauer2010OTR.pdf
    .. although based on material dated 2006 (UML2.2), this discussed UML property redefinition in comparison to subsetting and judged that redefinition was subsetting with a constraint.

  • Reported: UML 2.5.1 — Tue, 21 Jul 2020 16:45 GMT
  • Updated: Wed, 29 Jul 2020 08:58 GMT

UML.xmi is not well-formed

  • Key: UMLR-771
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In comparison to UML 2.5's xmi there is an additional

    <documentation>
    <shortDescription>UML.xmi: XMI representation of the metamodel for UML 2.5.1.</shortDescription>
    </documentation>

    This makes the XMI ill-formed since there is no xmlns declaration for the blank namespace.

    Change to xmi:Documentation

  • Reported: UML 2.5.1 — Tue, 5 May 2020 06:39 GMT
  • Updated: Tue, 5 May 2020 17:47 GMT

UML 2.5.1 embedded OCL syntax errors

  • Key: OCL25-217
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The new OCL for UML 2.5.1 seems not to have been checked by any tool; shame on you. There are two syntax errors:

    OpaqueExpression-only_in_or_return_parameters-specification makes use of ParameterDirectionKind::in but 'in' is a reserved word and so it must be escaped as in other similar constraints. Change to ParameterDirectionKind::'in'

    Lifeline-interaction_uses_share_lifeline-_specification has a Bag rather than Boolean argument for the final implies. Perhaps the select(...) should be followed by a ->notEmpty() or the select(...) could be an exists(...)

  • Reported: UML 2.5.1 — Tue, 5 May 2020 16:55 GMT
  • Updated: Tue, 5 May 2020 16:55 GMT

PackageImport Missing for Type Generalization

  • Key: UMLR-770
  • Status: open  
  • Source: N/A ( Jon Lindberg)
  • Summary:

    In the XMI representation of the metamodel for UML 2.5.1:

    • The package Classification defines the class InstanceValue.
    • InstanceValue contains a generalization to the class ValueSpecification.
    • ValueSpecification is defined in the package Values.
    • The package Classification does not contain a packageImport element for the Values package or for any other package which itself imports Values. This renders the type of ValueSpecification undefined at the point where it is used by InstanceValue.

    The most immediate solution appears to be to add a packageImport to the definition of the Classification package, e.g., '<packageImport xmi:type="uml:PackageImport" xmi:id="Classification-_packageImport.3" importedPackage="Values"/>'.

  • Reported: UML 2.5.1 — Sun, 25 Aug 2019 03:40 GMT
  • Updated: Thu, 5 Sep 2019 14:50 GMT

Nested Port not supported on Sequence Diagram

  • Key: UMLR-769
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    currently, there is no way to specify a nested port as a part decomposition in a sequence diagram

  • Reported: UML 2.5.1 — Sat, 3 Aug 2019 00:12 GMT
  • Updated: Mon, 5 Aug 2019 18:52 GMT

InteractionUse can not reference a CollaborationUse (as shown in Figure 17.24)

  • Key: UMLR-768
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification contains following diagram:

    It shows how a CollaborationUse w1 can be used to bind the parts of a concrete Class E to roles in the generic Collaboration W. The InteractionUse in the sequence diagram of E is then shown as if it references w1.Q. This is not possible, since an InteractionUse can only reference another Interaction. In the case shown it might just be inferred, since there is only one CollaborationUse. However, it is possible to use the same Collaboration multiple times with different role bindings, and then it is necessary to define which one is happening.

    Suggestion
    This is a useful feature. I think the Metamodel should be enhanced. One possibility would be to allow InteractionUses to reference CollaborationUses.

  • Reported: UML 2.5.1 — Thu, 25 Jul 2019 12:15 GMT
  • Updated: Thu, 25 Jul 2019 12:17 GMT
  • Attachments:

Error in Loop fragment deffinition

  • Key: UMLR-767
  • Status: open   Implementation work Blocked
  • Source: FHOOE ( Georg Fritze)
  • Summary:

    the textual syntax is wrong:
    ‘loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
    =>
    ‘loop’[‘(’ <minint> [‘,’ <maxint> ] ‘)’]

    If this textual syntax describes the Guard than is also should be able to contain a bool statement (17.6.3.17 Loop).
    If this text describes the format of the name, please explain how to distinguish between an InteractionConstraint and a Guard.

  • Reported: UML 2.5.1 — Fri, 14 Jun 2019 23:03 GMT
  • Updated: Wed, 17 Jul 2019 18:06 GMT

Duplicate section titles

  • Key: UMLR-766
  • Status: open  
  • Source: Fraunhofer FOKUS ( Niels Hoppe)
  • Summary:

    Sections 17.9.1.1 and 17.9.1.2 both bear the title "Graphical Paths". This is correct for section 17.9.1.2, but not for section 17.9.1.1 as it describes graphical nodes (not paths) as written in the section body and the referenced table 17.3 "Graphic Nodes Included in Communication Diagrams".

  • Reported: UML 2.5.1 — Mon, 3 Jun 2019 12:47 GMT
  • Updated: Wed, 17 Jul 2019 18:06 GMT

Property.Association is not a union

  • Key: UMLR-761
  • Status: open   Implementation work Blocked
  • Source: Capricorn Pro s.r.o. ( Slávek Rydval)
  • Summary:

    Property.association is not set as union although Property.owningAssociation is subsetting it.

  • Reported: UML 2.5.1 — Tue, 2 Apr 2019 20:11 GMT
  • Updated: Tue, 18 Jun 2019 06:39 GMT

Specializations of an Association Class

  • Key: UMLR-764
  • Status: open  
  • Source: Software Centre of Excellence, Rolls-Royce Div. ( Dave Banham)
  • Summary:

    The very last paragraph of section 11.5.3.2 states "An AssociationClass cannot be a generalization of an Association or a Class." However, there appear to be no constraints specified for AssociationClass (11.8.2) or Generalization (9.9.7), or GeneralizationSet (9.9.8) to formalize the intent of this statement.

    To be clear, does this statement mean that an AssociationClass cannot be a Generalization's general or specific property? If so, why not?

    I think there are two cases to consider:
    1. Redefinition/subsetting of the association class' end properties results in the need to subset the association class;
    2. Classifying the association class into subtypes through specialization;

    Case 1 would naturally lead to the specializations of the AssociationClass being AssociationClasses (because an association is being used to redefine the association that is typed by the more general AssociationClass).

    Case 2. would naturally lead to the specializations of the AssociationClass being Classes (because no new associations are being specified). Although, in reality, instances of these subtype classes are, by inheritance, instances of their general AssocaitionClass.

    Case 2 also makes me think of power types. Can an association class be a power type? If it can then that may well provide a workaround for case 2.

  • Reported: UML 2.5.1 — Wed, 24 Apr 2019 14:33 GMT
  • Updated: Wed, 12 Jun 2019 15:37 GMT

Duplicated xmi:id values in UML.xmi

  • Key: UMLR-758
  • Status: open  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    The following `xmi:id` attribute values occur multiple times in the document. My understanding is that `xmi:id` attribute values are meant to be unique.

    This looks like a copy/paste error. The given IDs are present within the `UML::StateMachine::State` class and within the `UML::StateMachine::Vertex` class. I suspect that the elements within the `Vertex` class should be prefixed with `Vertex-` instead of `State-`.

    • State-isConsistentWith
    • State-isConsistentWith-_ownedComment.0
    • State-isConsistentWith-pre
    • State-isConsistentWith-pre-_specification
    • State-isConsistentWith-redefiningElement
    • State-isConsistentWith-result
    • State-isConsistentWith-spec
    • State-isConsistentWith-spec-_specification
  • Reported: UML 2.5.1 — Wed, 27 Feb 2019 16:44 GMT
  • Updated: Wed, 6 Mar 2019 14:54 GMT

Behavior::behavioredClassifier bodycondition is serialized as a precondition

  • Key: UMLR-756
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Behavior::behavioredClassifier like many UML operations has a body defined in OCL.

    This is normally "result="-prefixed to become a pseudo-Boolean bodycondition in XMI.

    However exceptionally Behavior::behavioredClassifier is serialized as a precondition where its non-Boolean value is an error. (Eclipse OCL has finally added the relevant WFR.)

  • Reported: UML 2.5.1 — Sat, 19 Jan 2019 13:18 GMT
  • Updated: Thu, 31 Jan 2019 15:23 GMT

Unclear whether current State during Transition is the target State

  • Key: UMLR-755
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification says:

    Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing.

    States don't have effect Behaviors, only Transitions have them. Is that meant here? It would make sense, because otherwise there is no specification, what State the Machine would be "in" during the Transition. And since the effect Behavior could refer to the current State, it must have a defined State.

    Suggested change

    Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior of that State or effect Behavior of the Transition leading to it (if defined) start executing.

  • Reported: UML 2.5.1 — Mon, 21 Jan 2019 13:59 GMT
  • Updated: Mon, 21 Jan 2019 13:59 GMT

Figure 9.11 misses attribute name

  • Key: UMLR-754
  • Status: open  
  • Source: Rheinmetall Air Defence ( Yves Strube)
  • Summary:

    In Figure 9.11 "ClassB" has an attribute "Integer = 7" which redefines the default of "ClassA::height". However the name of the attribute seems to be missing in "ClassB". It should probably say "height: Integer = 7".

  • Reported: UML 2.5.1 — Wed, 9 Jan 2019 06:40 GMT
  • Updated: Mon, 14 Jan 2019 20:37 GMT

The definition of relative Time Events is ambigious

  • Key: UMLR-751
  • Status: open  
  • Source: Scarecrow Consultants ( James Towers)
  • Summary:

    A relative Time Event i.e. after(x) as used as a trigger on a state machine transition is ambiguous as it is not clear when the earliest occurrence of this trigger could be.

    If the originating state is entered at time T1 and the transition is taken at time T2 then providing T2 - T1 > x the event has happened 'after' x (in the common meaning of the word),
    however if T2 - T1 = x it is not clear if the transition has been taken too early or not. This is because it is not defined whether 'after' means T2 - T1 > x or T2 - T1 >= x

  • Reported: UML 2.5.1 — Thu, 18 Oct 2018 16:15 GMT
  • Updated: Mon, 22 Oct 2018 14:35 GMT

Typo

  • Key: UMLR-747
  • Status: open  
  • Source: Yxlon ( Jörn Sierwald)
  • Summary:

    The last paragraph refers to a property called isDirectlyInstantiated. The property is actually called isIndirectlyInstantiated.

  • Reported: UML 2.5.1 — Wed, 17 Jan 2018 08:22 GMT
  • Updated: Wed, 24 Jan 2018 16:01 GMT