Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Open Issues

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

Issues Descriptions

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

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: 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

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

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

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: 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 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