Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-185 Association class notation with just class or association UML 2.1.2 open
UMLR-119 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-503 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02) UML 2.1.2 open
UMLR-505 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations UML 2.1.2 open
UMLR-170 there are numerous places where associations between UML elements have only one, navigable role UML 2.1.2 open
UMLR-144 Section: 14.3.24, 14.3.20 UML 2.1.2 open
UMLR-143 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) UML 2.1.2 open
UMLR-142 role bindings of a CollaborationUse UML 2.1.1 open
UMLR-138 Section: 15.3.7 Constraint [2] UML 2.1.2 open
UMLR-136 Section: 18.3.3 UML 2.1.2 open
UMLR-134 Section 7.3.44 UML 2.1.2 open
UMLR-133 Section: 7.3.41 UML 2.1.2 open
UMLR-132 UML 2 has lost cability to represent operations by collaborations UML 2.1.2 open
UMLR-126 Figure 7.48 and the accompanying discussion under 7.3.21 UML 2.1.1 open
UMLR-124 Section: 7.3.37 Package (from Kernel) UML 2.1.1 open
UMLR-122 Section: 16.3.5 UML 2.1.1 open
UMLR-120 Section: Annex A: Diagrams UML 2.1.1 open
UMLR-118 Section: 14.4 Timing Diagram: Continuous time axis UML 2.1.1 open
UMLR-111 Section: 10.3.4 of formal/2007-02-03 UML 2.1.1 open
UMLR-100 Section: 13 & 14 UML 2.1.1 open
UMLR-96 Section: 15.3.12, p 588, 589 UML 2.1.1 open
UMLR-93 Section: 7.3.33 UML 2.1.1 open
UMLR-79 Section: 7.3.9 UML 2.1 open

Issues Descriptions

Association class notation with just class or association

  • Key: UMLR-185
  • Legacy Issue Number: 14426
  • Status: open  
  • Source: Raytheon ( Roy Bell)
  • Summary:

    Association class notation should include just the class symbol or
    just the association symbol, in addition to the current combination of
    these. Association classes are both associations and classes and
    should be able to be notated as either one separately.

  • Reported: UML 2.1.2 — Sat, 19 Sep 2009 04:00 GMT
  • Updated: Wed, 24 Apr 2019 09:09 GMT

Section: Annex A: Diagrams

  • Key: UMLR-119
  • Legacy Issue Number: 11272
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    There are less diagram kinds defined than UML diagrams. In particular I miss a diagram kind for object, deployment and composite structure diagrams

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Tue, 6 Dec 2016 19:54 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations (02)

  • Key: UMLR-503
  • Legacy Issue Number: 18082
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    I've also doubts on the following constraint: “UseCases can not have Associations to UseCases specifying the same subject.”. In my opinion, and in my interpretation of what is written on page 686, UseCases can not have Associations to UseCases, whether they specify or not the same subject.

    What form of association may exist among UseCases specifying different subjects?

  • Reported: UML 2.1.2 — Fri, 21 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - Need stricter limit on associations

  • Key: UMLR-505
  • Legacy Issue Number: 18081
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text (688): UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors

    [AC] I believe here one or more constraints are missing. The associations an Actor can have are correctly constrained (see page 694) to be only with UseCase, Class and Component.
    A UseCase, in my opinion and in the whole literature that I know, can only have associations with Actors (while it can have other types of relationship, such as dependencies with other classifiers).
    If I am right, then also what is written on page 688 - “UseCases may have other Associations and Dependencies to other Classifiers (e.g., to denote input/output, events, and behaviors).” - should be corrected.

  • Reported: UML 2.1.2 — Fri, 21 Nov 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

there are numerous places where associations between UML elements have only one, navigable role

  • Key: UMLR-170
  • Legacy Issue Number: 13908
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the specification there are numerous places where associations between UML elements have only one, navigable role. This seriously restricts the ability of derived properties that are added as part of a profile. Though most tool vendors implement bi-directional relationships for everything anyway, this doesn't help at all when you're trying to define the implementation of the derived property (i.e. tag), as part of a property. It is my belief that all associations in UML should be bi-directional to support a method of non-ambiguous definition. A couple of obvious examples are: 1. Navigating from a realizing relationship to a realized InformationFlow. 2. Navigating from an ActivityEdge to an Action via a Pin.

  • Reported: UML 2.1.2 — Wed, 29 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.24, 14.3.20

  • Key: UMLR-144
  • Legacy Issue Number: 12568
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 5 5.1 Interactions diagrams shows messages that are type of MessageSort (from Interactions/BasicInteractions, level L1). There is no way to express that a message is an exception. Only signals and calls are expressed. Exception is none of them ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

3 3.2 Behavior (CommonBehaviors/BasicBehaviors)

  • Key: UMLR-143
  • Legacy Issue Number: 12566
  • Status: open  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 3 3.2 Behavior (CommonBehaviors/BasicBehaviors) is having relationship redefinedBehavior, that should be derived

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

role bindings of a CollaborationUse

  • Key: UMLR-142
  • Legacy Issue Number: 12544
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Using a simple Dependency to define the role bindings of a CollaborationUse seems too "light". I suggest to change for a Realization relationship which has a stronger - and i think more convenient - semantic.

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.7 Constraint [2]

  • Key: UMLR-138
  • Legacy Issue Number: 12354
  • Status: open  
  • Source: Logica ( Tis Veugen)
  • Summary:

    Constraint [2] says: A protocol transition never has associated actions. My problem is that this constraint makes it impossible to specify a consistent pair of a server protocol state machine (PSM) and a client PSM. The server PSM has call events as triggers. It also has internal events causing autonomous state transitions. However, the latter transitions must be notified to the client PSM. This can only be done by actions in which signal events are generated to the client FSM. Such signals are the triggers in the client FSM; and in fact the same problem happens here. Since the call events to the server PSM are caused by internal events at the client PSM, that force call events to the server PSM in the actions. I hope this issue can be solved or at least clarified. Thanks.

  • Reported: UML 2.1.2 — Sun, 23 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 18.3.3

  • Key: UMLR-136
  • Legacy Issue Number: 12279
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    Section 18.3.3 states, that "An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier". Whereas in section 7.3.3 (Association) on page 43, it is stated that: "Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the association whereas navigable ends were assumed to be owned by the classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are orthogonal concepts [...]" The mentioned description in ExtensionEnd seems to contradict the definition of an Association. For the UML Profile Extension Mechanism two issues are essential to be clarified: 1) Is it possible, that an ExtensionEnd (which is owned by the Extension instead of the extended Class) is navigable? 2) Is it possible in a UML-Profile to define an Association which relates a Stereotype with a metaclass and which is navigable on both association ends (if the association end which refers to the stereotype is owned by the association itself instead of by the extended class)? [unidirectional Associations navigable from a stereotype to the extended metaclass seem to be allowed, as exemplified in the SysML 1.0 Standard at page 164]

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3.44

  • Key: UMLR-134
  • Legacy Issue Number: 12272
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The metaclasses 'Attribute' and 'AssociationEnd' (defined in UML 1.x) are merged in the metaclass 'Property' in UML 2.x. But the terms 'attribute' and 'association end' are still used in the standard, based one the two possible Property-containments (Property owned by a 'Class' respectively by an 'Association'). In addition, a semantic for the different values of the meta-property 'aggregation' is only defined for a 'Property' of style 'association end'. I propose to re-introduce the metaclasses 'Attribute' and 'AssociationEnd' as specializations of 'Property', making 'Property' an abstract class (the meta-property 'aggregation' should be then moved to AssociationEnd).

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.41

  • Key: UMLR-133
  • Legacy Issue Number: 12267
  • Status: open  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The last sentence of the Semantics definition for Parameter is: "If the behavioral feature is an operation, then the type and multiplicity of this parameter is the same as the type and multiplicity of the operation itself.". The multiplicity of an operation is not defined in the standard: Operation does neither inherit from MultiplicityElement, nor has it an element called 'multiplicity'. Proposed resolution: Replace this sentence by: "If the behavioral feature is an operation, then the type of this parameter is the same as the type of the operation itself

  • Reported: UML 2.1.2 — Mon, 10 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2 has lost cability to represent operations by collaborations

  • Key: UMLR-132
  • Legacy Issue Number: 12203
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    It appears that UML 2 has lost the ability to represent operations by collaborations. (There the collaboration related the parameters of the operation as roles.) Now a collaboration use can only be owned by a classifier. A behavior could still be explained by an operation, but not an operation. If this is desired, the references to operations owning collaboration uses need to be purged. Otherwise it has to be fixed that operations can own collaboration uses.

  • Reported: UML 2.1.2 — Thu, 31 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 7.48 and the accompanying discussion under 7.3.21

  • Key: UMLR-126
  • Legacy Issue Number: 11807
  • Status: open  
  • Source: Duke University ( John Madden)
  • Summary:

    Figure 7.48 and the accompanying discussion under 7.3.21 GeneralizationSet>Examples on pp 78-79 uses the example of a generalization set consisting of a single class to explain the proper use of the isCovering and isDisjoint attributes. I believe this example is infelicitous in the context of this exposition because generalization sets consisting of a single class present a special case, and this detracts from the exposition. In what way are they a special case? IF (a generalization set consists of a single class AND it is

    {incomplete}) THEN it can only be {disjoint}. This is because if the complement of an {incomplete}

    generalization set is non-empty, and consists of all instances that are NOT members of the solitary class in the generalization set. In other words, for a generalization set consisting of a single class, the combination

    {incomplete, overlapping}

    is self-contradictory. IF (a generalization set consists of a single class AND it is

    {complete}) THEN it can only be {overlapping}. This is because the complement of a {complete}

    generalization set is the null set, and the null set is a member of every set. In other words, the combination

    {complete, disjoint}

    is self-contradictory. I would recommend pointing out that generalization sets consisting of a single class represent a special case, and I would treat them separately (?footnote). For purposes of the exposition, I would modify Figure 7.48 to include at least two classes (perhaps Employee, Manager) instead of just Employee in the right-hand generalization set.

  • Reported: UML 2.1.1 — Sun, 9 Dec 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.37 Package (from Kernel)

  • Key: UMLR-124
  • Legacy Issue Number: 11342
  • Status: open  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    The type of association 'packageMerge' is shown as 'Package'. In contradiction to this is the describing text of this association and the Figure 7.14 on p. 34 showing that the association 'packageMerge' is from 'Package' to 'PackageMerge'. Correct in chapter '7.3.37 Package (from Kernel)' the type of association 'packageMerge' from 'Package' to 'PackageMerge'.

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.5

  • Key: UMLR-122
  • Legacy Issue Number: 11307
  • Status: open  
  • Source: 4Soft GmbH ( Klaus Bergner)
  • Summary:

    The Description section states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly." This is often understood as stating that the behavior of an included use case has to be executed during every execution of the behavior of the including use case. Example: The following informal use case fragment contains a conditional call of an included use case: Step x: If the user choses to print the reports, <<include>> the use case "Print reports". With the understanding given above, this use case fragment would be invalid (at least if the included use case is not included elsewhere in the including use case). In a similar vein, the Semantics section states: "All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed." Besides the obvious error (the sentence should say: "... is executed at a single location in the including use case ..."), this is sometimes understood as stating that the behavior of the included use case must be executed exactly once during the execution of the including use case. Another (equally wrong) interpretation would be that the included use case must be included exactly once in the use case specification (implying, for example, that there must not be two lines in the same textual use case specification containing an <<include>> directive for a certain use case). Both sections should be clarified, clearly stating that: - The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram). Analogy: A routine that contains multiple calls to a subroutine in its source code. - The including use case is responsible for calling the included use case. It may choose to call it once, repeatedly, or not at all. Analogy: A routine with conditional execution paths or iterative behavior, performing subroutine calls conditionally or iteratively. Proposal for changing the sentence in the Description section: "Note that the included use case is not optional, and is always required for the including use case to be fully specified. The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram)." Proposal for a change and an addition in the Semantics section: "All of the behavior of the included use case is executed in the including use case before execution of the including use case is resumed. Depending on behavior of the including use case, the included use case may be called once, multiple times or not at all." I would be very pleased to receive a first, quick reply by mail.

  • Reported: UML 2.1.1 — Mon, 27 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Annex A: Diagrams

  • Key: UMLR-120
  • Legacy Issue Number: 11273
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The abbreviation sd for interaction diagrams should be renamed to id. sd stands for sequence diagram, but there three more interaction diagrams. It is confusing to have a diagram kind sd for a timing diagram.

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.4 Timing Diagram: Continuous time axis

  • Key: UMLR-118
  • Legacy Issue Number: 11092
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Table 14.6., State or condition timeline: It is unclear how the time information is stored in the interaction model. Especially if it is a continuous timeline. Please clarify the repository model for timing diagrams

  • Reported: UML 2.1.1 — Fri, 8 Jun 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.4 of formal/2007-02-03

  • Key: UMLR-111
  • Legacy Issue Number: 10781
  • Status: open  
  • Source: Vilnius University, Lithuania ( Donatas Ciuksys)
  • Summary:

    The direction of deployment dependency is wrong in all figures that use this kind of dependency, e.g. figure 10.9 on page 216 (direction is opposite to the one stated in metamodel). The deployment dependency in these figures is being drawn from artifact (client) to target (suplier), though figure 10.4 on page 210 defines Deployment as being dependency with DeploymentTarget as client and DeployedArtifact as supplier, so direction should be opposite - from target to artifact. As an alternative, the metamodel could be adjusted.

  • Reported: UML 2.1.1 — Mon, 19 Feb 2007 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 13 & 14

  • Key: UMLR-100
  • Legacy Issue Number: 9923
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    Some of the concepts defined in the Interaction chapter (n 14), as for example BehaviorExecutionSpecification, are more general than Interaction and shoul dbe part of the chpater 13 which concern is behavior in general. I suggest to review the chapter 14 in order to extract from this section all the concept that are generic w.r.t. behavior and to put them in the chapter 13.

  • Reported: UML 2.1.1 — Tue, 18 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 15.3.12, p 588, 589

  • Key: UMLR-96
  • Legacy Issue Number: 9840
  • Status: open  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    There are 3 kinds (TransitionKind) of transitions: internal, external and local. Are there firing priorities between these? For example, consider the case of an internal transition within a state and an external transition with same state as its source state, triggered by the same event, with no guard conditions. If that event occurs, which transition(s) will fire? The standard states, "An internal transition in a state conflicts only with transitions that cause an exit from that state," but neither the firing priorities nor the transition selection algorithm define how such a conflict should be resolved.

  • Reported: UML 2.1.1 — Mon, 26 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.33

  • Key: UMLR-93
  • Legacy Issue Number: 9754
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement

  • Reported: UML 2.1.1 — Tue, 23 May 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7.3.9

  • Key: UMLR-79
  • Legacy Issue Number: 9369
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I propose an optional enhancement of the comment symbol: It is possible to draw a small circle at the end of the anchor line. That way it is easier to read a diagram if the anchor line crosses other dependency lines. The small circle is already used in several diagrams. It is part of the famous Visio stencil of Pavel Hruby.

  • Reported: UML 2.1 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT