Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

  • Acronym: UML
  • Issues Count: 12
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Correction to 7336

  • Key: UML15-12
  • Legacy Issue Number: 7671
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Referring to the 040829.PDF FTF draft, in Figure 192, the two
    associations ownedParameterSet should point to ParameterSet, to be
    consistent with the text.

  • Reported: UML 1.4.2 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Dependency errors

  • Key: UML15-11
  • Legacy Issue Number: 7670
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Referring to the 040829.PDF FTF draft, the following dependencies
    should be changed:

    • Figure 141

    IntermediateActions imports BasicActions and Communications,
    rather than merge.

    CompleteActions does not depend on StructuredActions, and only
    imports BehaviorStateMachines and AssociationClasses.

    • Figure 175:

    FundamentalActivities merges BasicActions. The merge from
    StructuredActivities to BasicActions can be removed.

    CompleteActivities imports BehaviorStateMachines, rather than
    merge.

  • Reported: UML 1.4.2 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML2 super/Profile/Unconsistent association extension description

  • Key: UML15-10
  • Legacy Issue Number: 7665
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is
    not possible to have an association between two stereotypes or between a
    stereotype and a metaclass unless they are subsets of existing associations
    in the reference metamodel." I fail to see how a profile could in fact could
    cause an association between 2 stereotypes to subset an existing association
    in a reference metamodel since the stereotypes do not at all inherit from
    the baseClasses so do not inherit any of its properties or associations in
    order to be able to subset them: this is emphasized by the MOF
    representation shown in the new Figure 447.

    Indeed profiles do not support association subsetting. This should be made
    clear in the spec to avoid any confusion while using profiles.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML2 super/Profile/Unconsistent Profile extension description

  • Key: UML15-9
  • Legacy Issue Number: 7664
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    18.3.5 says that "A profile by definition extends a reference metamodel or
    another profile."
    While in theory I could see how it might be modeled, I don't see how the
    latter could work in practice with real tools. Let's extend the current
    example and define a new Profile called ClockTechnology with Stereotype
    AtomicClock with baseClass Clock and property radioactiveElement:String..."

    Import between profiles is supported, and stereotype generalization is the
    usual way to achieve what has been called "extending a profile".

    The reference to profile extension should be simply discarded. A profile
    extends a reference metamodel.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super Issue re: DI compliance

  • Key: UML15-8
  • Legacy Issue Number: 7649
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance with UML 2 Superstructure.

    In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value.

  • Reported: UML 1.4.2 — Wed, 25 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2/ Inconsistencies in usage of package merge

  • Key: UML15-7
  • Legacy Issue Number: 7623
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    With the adoption of the updated definition of package merge, there are a number of places in both the Infrastructure and the Superstructure metamodels where the pre-conditions of package merge are violated. These need to be fixed.

  • Reported: UML 1.4.2 — Sun, 15 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/Infra: no notation for "isQuery" characteristic of Operations

  • Key: UML15-6
  • Legacy Issue Number: 7616
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The spec does not have a way of indicating that an operation has "isQuery" set to true.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    This is a duplicate of 6514 and has been resolved as part of the resolution to 7315.

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/Infra: return type of an operation

  • Key: UML15-5
  • Legacy Issue Number: 7615
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    At the bottom of pg. 79 of the Super FAS there are some examples ;
    +createWindow (location: Coordinates, container: Container [0..1]): Window

    +toString (): String

    However that does not conform with the syntax of Operations (on page 78), which does not support the ":<return-type>" notation. It is probably a good idea to allow such a syntax since it is quite common, is used in most UML books and tools, and is conveniently similar to the notation for attributes.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    This is a duplicate of 6213 and has been resolved as part of the resolution to 7315.

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Need to documetn diagramming conventions for association ends

  • Key: UML15-4
  • Legacy Issue Number: 7606
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    It is necessary to fully document the notational conventions used in the UML metamodel diagrams. In particular, it is necessary to be specific about the conventions used to denote the navigability and ownership of association ends, since the UML spec does not provide a default

  • Reported: UML 1.4.2 — Thu, 29 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Remove Package Templates? Feedback requested

  • Key: UML15-3
  • Legacy Issue Number: 7577
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Package templates were a nice idea but they were never properly implemented in the UML 2 spec. At the moment, what is in the spec is incorrect and completely different from what is in the metamodel (I am not sure how that came about – maybe Birger recalls). Neither version is complete or correct.

    The concept is a nice one to have, however, at this stage I am thinking of removing it altogether and leaving it as a new feature to be added in a future version.

    Does anyone have strong objections to the removal of this concept?

    (Reminder: package templates were the mechanism that depended on string substitution for instantiation.)

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/state machines/Maximum one region

  • Key: UML15-2
  • Legacy Issue Number: 7576
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The package MaximumOneRegion was intended to be used as an optional package that restricts some of the general capabilities of behavioral state machines. This kind of capability is normally provided by a profile and should not be included in the standard, since it, effectively, displaces other parts of the standard.

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

StartOwnedBehaviorAction

  • Key: UML15-1
  • Legacy Issue Number: 7574
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    This action should be renamed and semantics clarified to apply to
    classifier behaviors.

  • Reported: UML 1.4.2 — Sun, 11 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT