Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UML25-607 UML 2 Super/Templates/Inconsistent organization UML 1.4.2 UML 2.5 Resolved closed
UML25-606 UML 2 Superstructure -Incompatible use of term link UML 1.4.2 UML 2.5 Resolved closed
UML25-604 UML 2.0 Issue: Semantics of Provided and Required Interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-615 9.3.11 Port (from Ports) UML 1.4.2 UML 2.5 Resolved closed
UML25-614 .3.44 Property (from Kernel) UML 1.4.2 UML 2.5 Resolved closed
UML25-610 UML2 super/CommonBehavior/Opaque behavior : bad OO modelling UML 1.4.2 UML 2.5 Resolved closed
UML25-611 7.3.24 Interface (from Interfaces) UML 1.4.2 UML 2.5 Resolved closed
UML25-605 UML 2 Superstructure - cross-hair notation for nested classes UML 1.4.2 UML 2.5 Resolved closed
UML25-612 9.3.6 Connector (from InternalStructures) UML 1.4.2 UML 2.5 Resolved closed
UML25-613 8.3.1 Component (from BasicComponents, PackagingComponents) UML 1.4.2 UML 2.5 Resolved closed
UML25-622 inconsistent Generalization subsections in spec format UML 1.4.2 UML 2.5 Resolved closed
UML25-621 notational standard for {subsets x} in textual contexts UML 1.4.2 UML 2.5 Resolved closed
UML25-623 "Class" should read "Classifier" in Generalization subsection for Behaviore UML 1.4.2 UML 2.5 Resolved closed
UML25-619 15.3.10 Region (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-626 UML2 Super / Templates / ordering of subExpressions UML 1.4.2 UML 2.5 Resolved closed
UML25-617 15.3.16 Vertex (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-616 Artifact (from Artifacts) UML 1.4.2 UML 2.5 Resolved closed
UML25-625 UML 2 Super/ Classes / issue with Property::isComposite UML 1.4.2 UML 2.5 Resolved closed
UML25-618 15.3.8 Pseudostate (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-601 UML 2 Super and Infra/ defualt property of Parameter::effect UML 1.4.2 UML 2.5 Resolved closed
UML25-602 Associations between interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-582 UML 2 Super/Components/missing description of Connector::contract UML 1.4.2 UML 2.5 Resolved closed
UML25-581 UML 2 Super/Interactions/notation for accessing a static feature UML 1.4.2 UML 2.5 Resolved closed
UML25-584 Missing notation for Behaviors in a BehavioredClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-583 Name without a colon for Property in Composite Structures UML 1.4.2 UML 2.5 Resolved closed
UML25-586 Profiles in Compliance Level 1? UML 1.4.2 UML 2.5 Resolved closed
UML25-585 Redundant parameter specifications for Operation and Behavior UML 1.4.2 UML 2.5 Resolved closed
UML25-579 UML 2 Super/Activities/Class-Activity association missing UML 1.4.2 UML 2.5 Resolved closed
UML25-578 UML2 super&infra/Profiles/ownership of Image UML 1.4.2 UML 2.5 Resolved closed
UML25-588 Figures 103 and 121 use <> dependencies UML 1.4.2 UML 2.5 Resolved closed
UML25-587 . <> on Usage UML 1.4.2 UML 2.5 Resolved closed
UML25-580 UML 2 Super/Templates/Template substitution symbol problematic UML 1.4.2 UML 2.5 Resolved closed
UML25-577 Port should specialize featuringClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-595 Active and passive UML 1.4.2 UML 2.5 Resolved closed
UML25-594 P.58 Missing closing bracket in second constraint UML 1.4.2 UML 2.5 Resolved closed
UML25-591 Compliance points - Diagram Interchange UML 1.4.2 UML 2.5 Resolved closed
UML25-598 included use case wrongly referred to as the including use case UML 1.4.2 UML 2.5 Resolved closed
UML25-597 check the BNF example given in the text UML 1.4.2 UML 2.5 Resolved closed
UML25-590 Bidirectional messages to a port object UML 1.4.2 UML 2.5 Resolved closed
UML25-589 Figures 120 and 121 UML 1.4.2 UML 2.5 Resolved closed
UML25-593 P.35 Typo in OCL definition of isDistinguishableFrom query UML 1.4.2 UML 2.5 Resolved closed
UML22-935 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-934 token UML 1.4.2 UML 2.1 Resolved closed
UML22-937 ``conditional node or conditional node'' delete one. UML 1.4.2 UML 2.1 Resolved closed
UML22-936 add the rule of ``natural termination'' UML 1.4.2 UML 2.1 Resolved closed
UML22-938 Delete sentence UML 1.4.2 UML 2.1 Resolved closed
UML22-933 UML 2 -- Need explanations of XMI structure and usage UML 1.4.2 UML 2.1 Resolved closed
UML22-932 token movement UML 1.4.2 UML 2.1 Resolved closed
UML22-931 output tokens (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-927 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-930 text p.297 UML 1.4.2 UML 2.1 Resolved closed
UML22-929 Section 12 (03) UML 1.4.2 UML 2.1 Resolved closed
UML22-928 Section 12 (02) UML 1.4.2 UML 2.1.2 Resolved closed
UML22-853 UML 2 Super / Conformance / inconsistencies UML 1.4.2 UML 2.1 Resolved closed
UML22-852 UML 2 Super / General / missing merges UML 1.4.2 UML 2.1 Resolved closed
UML22-851 UML 2 Super / General / improper subsetting UML 1.4.2 UML 2.1 Resolved closed
UML22-855 UML 2 Super / General / invalid subset rule too strict UML 1.4.2 UML 2.1 Resolved closed
UML22-854 UML 2 Super / Kernel / excessive restriction on redefinition UML 1.4.2 UML 2.1 Resolved closed
UML22-856 UML 2 Super / Common Behaviors / missing multiplicites UML 1.4.2 UML 2.1 Resolved closed
UML22-835 Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-834 Specification: Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-850 UML 2 Super / Collaborations / improper subset UML 1.4.2 UML 2.1 Resolved closed
UML22-849 Profiles::ObjectNode has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-848 Profiles::ExtensionEnd has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-845 Should Profiles::Image be an Element? UML 1.4.2 UML 2.1 Resolved closed
UML22-847 Remove redundant superclass for Element UML 1.4.2 UML 2.1 Resolved closed
UML22-846 OCL for Property::opposite() is incorrect: UML 1.4.2 UML 2.1 Resolved closed
UML22-815 Section: 14.3.24 UML 1.4.2 UML 2.1 Resolved closed
UML22-756 Profiles:Extension End UML 1.4.2 UML 2.1 Resolved closed
UML22-763 UML 2 super/templates/ UML 1.4.2 UML 2.1 Resolved closed
UML22-762 UML 2 Super/templates/inexplicable constraint on defaults UML 1.4.2 UML 2.1 Resolved closed
UML22-731 MultiplicityElement BNF too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-734 Used of "Redefines ...from Abstractions" in descriptions is misleading UML 1.4.2 UML 2.1 Resolved closed
UML22-733 BNF Notation for Operation is too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-732 Incomplete BNF for Property UML 1.4.2 UML 2.1 Resolved closed
UML22-636 Section: 9.3.3 UML 1.4.2 UML 2.1 Resolved closed
UML22-561 InfrastructureLibrary defines, but should not use package merge UML 1.4.2 UML 2.1 Resolved closed
UML22-557 section 2.10.4.1 detailed semantics of collaborations UML 1.4.2 UML 2.1 Resolved closed
UML22-559 Interactions UML 1.4.2 UML 2.1 Resolved closed
UML22-558 Section: 7.3.44 - OCL incorrect UML 1.4.2 UML 2.1 Resolved closed
UML22-555 Section: 7.2.8 UML 1.4.2 UML 2.1 Resolved closed
UML22-560 UML 2 Super Basic Interactions UML 1.4.2 UML 2.1.2 Resolved closed
UML22-556 Classes UML 1.4.2 UML 2.1 Resolved closed
UML22-623 Stereotypes applying in UML 2.0 UML 1.4.2 UML 2.1 Resolved closed
UML22-593 Terminology Issue UML 1.4.2 UML 2.1.2 Resolved closed
UML22-657 Section: 10.4 UML 1.4.2 UML 2.1 Resolved closed
UML22-565 ReduceAction UML 1.4.2 UML 2.1 Resolved closed
UML22-564 UML 2 Super / Incorrect statement on port visibility UML 1.4.2 UML 2.1 Resolved closed
UML22-553 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-549 Inconsistent use of 'Element' between MOF and UML UML 1.4.2 UML 2.1 Resolved closed
UML22-548 Missing XMI tags in spec and XMI rendition of metamodel UML 1.4.2 UML 2.1 Resolved closed
UML22-547 Move Comment into Basic and add Kind UML 1.4.2 UML 2.1 Resolved closed
UML22-546 Unconsistent Profile extension description (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-545 Unconsistent association extension description UML 1.4.2 UML 2.1 Resolved closed
UML22-551 Problem with diagram references in Profiles section UML 1.4.2 UML 2.1 Resolved closed
UML22-550 Design principles UML 1.4.2 UML 2.1 Resolved closed
UML22-552 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-140 Meaning of navigability UML 1.4.2 UML 2.2 Resolved closed
UML22-138 page 134, Chapter 11.4.1 UML 1.4.2 UML 2.2 Resolved closed
UML22-137 page 97, Chapter 10.2.2. MultiplicityElement UML 1.4.2 UML 2.2 Resolved closed
UML22-135 ObjectNode UML 1.4.2 UML 2.2 Resolved closed
UML22-134 UseCase and Actors UML 1.4.2 UML 2.2 Resolved closed
UML22-128 Section: 10.1 Types Diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-93 Figure 179 (Control nodes) UML 1.4.2 UML 2.2 Resolved closed
UML22-101 Section: Actions UML 1.4.2 UML 2.2 Resolved closed
UML22-100 CombinedFragment Loop notation UML 1.4.2 UML 2.2 Resolved closed
UML22-98 editorial in section 12 UML 1.4.2 UML 2.2 Resolved closed
UML22-97 UML 2 Different constraints for Property in Super and Infra UML 1.4.2 UML 2.2 Resolved closed
UML22-96 rewording isuse? UML 1.4.2 UML 2.2 Resolved closed
UML22-95 reword sentence UML 1.4.2 UML 2.2 Resolved closed
UML22-94 A test cannot be empty UML 1.4.2 UML 2.2 Resolved closed
UML22-114 Events in Sequence diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-113 1. Deployment UML 1.4.2 UML 2.2 Resolved closed
UML22-115 Nested Nodes UML 1.4.2 UML 2.2 Resolved closed
UML22-120 Return message UML 1.4.2 UML 2.2 Resolved closed
UML22-121 multiplicity should not be used/shown in an communicates association UML 1.4.2 UML 2.2 Resolved closed
UML22-73 inconsistent description UML 1.4.2 UML 2.2 Resolved closed
UML22-80 UML 2 Super / Kernel / invalid restriction in isConsistentWith() UML 1.4.2 UML 2.2 Resolved closed
UML22-67 namespace UML 1.4.2 UML 2.2 Resolved closed
UML22-66 Figure 89 on page 158 is incorrect UML 1.4.2 UML 2.2 Resolved closed
UML22-70 UML2/Infra section 11.6.2/ Enumerations should not have attributes UML 1.4.2 UML 2.2 Resolved closed
UML22-79 Default values for ValueSpecification are not specified properly UML 1.4.2 UML 2.2 Resolved closed
UML22-46 isComposite inconsistency in UML 2.0 and MOF 2.0 UML 1.4.2 UML 2.2 Resolved closed
UML22-47 should retain Comment and its associations to Element UML 1.4.2 UML 2.2 Resolved closed
UML22-49 Use case extension inconsistencies UML 1.4.2 UML 2.2 Resolved closed
UML22-54 ClassifierInState not supported in UML2.0 ? UML 1.4.2 UML 2.2 Resolved closed
UML22-53 Association specialization semantics UML 1.4.2 UML 2.2 Resolved closed
UML15-10 UML2 super/Profile/Unconsistent association extension description UML 1.4.2 UML 1.5 Resolved closed
UML15-12 Correction to 7336 UML 1.4.2 UML 1.5 Resolved closed
UML15-11 Dependency errors UML 1.4.2 UML 1.5 Resolved closed
UML15-9 UML2 super/Profile/Unconsistent Profile extension description UML 1.4.2 UML 1.5 Resolved closed
UML15-8 UML 2 Super Issue re: DI compliance UML 1.4.2 UML 1.5 Resolved closed
UML15-7 UML 2/ Inconsistencies in usage of package merge UML 1.4.2 UML 1.5 Resolved closed
UML15-6 UML 2 Super/Infra: no notation for "isQuery" characteristic of Operations UML 1.4.2 UML 1.5 Resolved closed
UML15-5 UML 2 Super/Infra: return type of an operation UML 1.4.2 UML 1.5 Resolved closed
UML15-4 Need to documetn diagramming conventions for association ends UML 1.4.2 UML 1.5 Resolved closed
UML15-3 Remove Package Templates? Feedback requested UML 1.4.2 UML 1.5 Resolved closed
UML15-2 UML 2 Super/state machines/Maximum one region UML 1.4.2 UML 1.5 Resolved closed
UML15-1 StartOwnedBehaviorAction UML 1.4.2 UML 1.5 Resolved closed

Issues Descriptions

UML 2 Super/Templates/Inconsistent organization

  • Key: UML25-607
  • Legacy Issue Number: 7831
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

  • Reported: UML 1.4.2 — Fri, 1 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Superstructure -Incompatible use of term link

  • Key: UML25-606
  • Legacy Issue Number: 7825
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The Semantics of Association says:

    "An association declares that there can be links between instances of the
    associated types. A link is a tuple with one value for
    each end of the assocaition, where each value is an instance of the type of
    the end."

    but in Semantics of Connector the spec states:

    "Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or
    it may represent the possibility of the instances being able to communicate
    because their identities are known by virtue of
    being passed in as parameters, held in variables or slots, or because the
    communicating instances are the same instance."

    The small issue is that link is used in incompatible ways which is
    confusing. The bigger issue is that Connectors may be typed by Associations
    and even if there is no actual type, one is "inferred". I would have thought
    that an instance of a Connector (a link) typed by an Association would have
    to be an Association Instance; one possible interpretation of this is that
    an instance of a Connector is only an Association Instance if it has a
    "non-inferred" type, although the value of "inferring" a type seems dubious
    if that is the case. The spec should clarify the situation.

  • Reported: UML 1.4.2 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2.0 Issue: Semantics of Provided and Required Interfaces

  • Key: UML25-604
  • Legacy Issue Number: 7779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In your presentation in Bertinoro you had
    a figure representing the mapping of the classic 'lollipop-notation' for
    provided and required interfaces into stereotyped dependencies between
    the port and the interfaces. I would like to propose that a similar
    picture be included in the specification to make the intent of the
    specification clearer. A good place for this figure would probably be
    9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

  • Reported: UML 1.4.2 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

9.3.11 Port (from Ports)

  • Key: UML25-615
  • Legacy Issue Number: 7858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A. All associations here are defined without multiplicity

    the multiplicity is given in the syntax diagram as * so [*] should be added to the text spec.

    B. redefinedPort : Port – subsets Element.redefinedElement.
    Element does not have member ‘redefinedElement’, must changed to be RedefinableElement::redefinedElement or (better yet) Property::redefinedProperty

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

.3.44 Property (from Kernel)

  • Key: UML25-614
  • Legacy Issue Number: 7857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Attribute:

    isReadOnly : Boolean

    This is redundant. Superclass of Property – StructuralFeature (from Kernel) has the same attribute with same default value. I think member isReadOnly can be inherited from StructuralFeature, and no needs define it in the Property.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15781

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

UML2 super/CommonBehavior/Opaque behavior : bad OO modelling

  • Key: UML25-610
  • Legacy Issue Number: 7850
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    When we see the attributes of OpaqueBehavior :
    • body : String [1..*] Specifies the behavior in one or more languages.
    • language : String [*] Languages the body strings use in the same order as
    the body strings.

    We can state that this is bad modelling practice : two attributes are sets,
    which elements have to be related 2 by 2 according to an ordering rule. This
    is even bad database modeling practice (violation of the 1st normal form
    rule).

    Proposition :
    Create an additional class "Language expression", having 2 attributes :
    Language and Body, and relate it to "OpaqueBehavior" instead of these two
    guilty attributes.

  • Reported: UML 1.4.2 — Wed, 13 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The proposed change may be better OO modeling practice, but it would cause a significant backward incompatibility
    for model interchange. Note that the patter of parallel body and language attributes is used not only for OpaqueBehavior,
    but also for OpaqueExpression and OpaqueAction. The cost of making such a change in all these cases does
    not seem worth the benefit of a marginal improvement in modeling practice.
    Disposition: Closed - No Change

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

7.3.24 Interface (from Interfaces)

  • Key: UML25-611
  • Legacy Issue Number: 7854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A.

    Association:

    redefinedInterface : Interface – subsets Element :: redefinedElement

    Element does not have member redefinedElement. Must be: “RedefinableElement :: redefinedElement”.
    Or better yet, change to “Classifier :: redefinedClassifier”.

    B.

    Association:

    ownedAttribute : Property – subsets Namespace.ownedMember and Classifier.feature

    instead of Classifier.feature, ownedAttribute subsets Classifier.attribute. See Figure 9 where Classifier.attribute:Property is annotated as

    {subsets feature}

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Superstructure - cross-hair notation for nested classes

  • Key: UML25-605
  • Legacy Issue Number: 7784
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The cross-hair notation is specified as an alternate notation for showing
    the containment of classifiers in packages, but there is no mention of the
    use of this notation for nesting classifiers within classes - this notation
    was present in UML 1.4 and so for backwards compatibility reasons should be
    in 2.0 also. I also note that the cross-hair notation does not appear in the
    diagrams section of Classes.

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

9.3.6 Connector (from InternalStructures)

  • Key: UML25-612
  • Legacy Issue Number: 7855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association

    redefinedConnector : Connector [0..*] – subsets Element.redefinedElement

    Element has no redefinedElement association. Change to RedefinableElement::redefinedElement

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

8.3.1 Component (from BasicComponents, PackagingComponents)

  • Key: UML25-613
  • Legacy Issue Number: 7856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association:

    ownedMember : PackageableElement [*]

    Conflicts with Namespace :: ownedMember. Perhaps add a word about redefine?

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

inconsistent Generalization subsections in spec format

  • Key: UML25-622
  • Legacy Issue Number: 7875
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reviewing of the new "generalization" subsections in the UML 2 spec, some are pointing down the inheritance hiearchy and some are pointing up.

    Section 6.5.1 Specification format says these sections are supposed to list the direct generalizations of a concept (see page 14, all the concepts "immediately above" in the hierarchy), yet I find many examples where metaclasses listed in Generalization subsections are the specializations of the concept.

    For example, Section 7.3.3 for Association correctly lists Classifier among its Generalizations, but 7.3.6 BehavioredClassifier(from Interfaces) lists BehavioredClassifier(from BasicBehaviors) thereby pointing down the hierarchy.

    Other examples are too numerous to list. The issue reported below may be another instance of this broader issue.

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

notational standard for {subsets x} in textual contexts

  • Key: UML25-621
  • Legacy Issue Number: 7865
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The text of the UML 2 Finalized Superstructure spec randomly uses dots and doubled-colons, as separator characters, in specifying the metaattribute of a metaassociation end,

    {subsets <x>}


    It also randomly uses or does not use (a) capitalization, as in 'Subsets' and 'subsets', and (b) curly braces. These issues may seem trivial to some human readers but are of consequence wrt any attempt to programmatically navigate structured text..

    Details:

    The dot sometimes used as a navigation path separator, as is correct for OCL, and in other contexts the UML namespace separator, the double-colon, is used.

    Instances of the usage of the dot are at 7.3.5 BehavioralFeature, Association, ownedParameter (which also shows random variation, in not including the curly braces that sometimes set off the subsets property in the textual spec), and of the doubled-colons, at 17.2.1 InformationFlow, Associations target:NamedElement[ ]

    {Subsets DirectedRelationship::target}

    which also shows the occasional use of the curly braces.

    It seems that, since subsets is a relationship between the sets of instances that can qualify for occupying an end of an association, the dot notation, which is used for instance navigation in OCL and in familiar OO programming languages, is correct.

    Another reason for thinking the dot is correct is that the namespace separator implies that the named association end is part of the namespace of the Classifier at the other end, and that seems to imply that the end is navigable. There are some instances in the spec where the namespace separator is used, but wrt a non-navigable end.

    Question:
    what is the "standard" notation in the context of text outside of diagrams?
    Proposal:
    Revise the notation section for Association to make it explicit that the notational standards given there apply in both diagrams and text, and revise the text for consistency. The problem may be that the notational standard does not say whether it applies to text, diagrams, or both.

  • Reported: UML 1.4.2 — Fri, 15 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

"Class" should read "Classifier" in Generalization subsection for Behaviore

  • Key: UML25-623
  • Legacy Issue Number: 7876
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference to the October 2005 UML 2 Superstructure Specification as delivered out of the FTF.

    Issue name: "Class" should read "Classifier" in Generalization subsection for BehavioredClassifier.

    Description:

    BehavioredClassifier text specification on page 468 lists generalization as Class (from Kernel)

    However, the syntax diagram Figure 311 on page 459 shows the generalization of BehavioredClassifer as Classifier(from Kernel)

    Figure 314 shows Class as a specialization, not a generalization, for Behaviored Classifier.

    I suspect 'Generalization Class (from Kernel)' on page 468 is an error in the text and it should read 'Generalization Classifier' (from Kernel).

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

15.3.10 Region (from BehaviorStateMachines)

  • Key: UML25-619
  • Legacy Issue Number: 7863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.10 Region (from BehaviorStateMachines)

    Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML2 Super / Templates / ordering of subExpressions

  • Key: UML25-626
  • Legacy Issue Number: 7882
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StringExpression:subExpression should be ordered

  • Reported: UML 1.4.2 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, it seems that ordering was incorrectly applied to the opposite property StringExpression:: owning-
    Expression instead of StringExpression::subExpression. This should be corrected.

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

15.3.16 Vertex (from BehaviorStateMachines)

  • Key: UML25-617
  • Legacy Issue Number: 7860
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.16 Vertex (from BehaviorStateMachines)

    Associations:

    container : Region [0..1] – subsets Element::owner

    This is a mistake, because Element::owner is already subsetted in parent of Vertex – NamedElement::namespace.

    Must be “subsets NamedElement::namespace”

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Artifact (from Artifacts)

  • Key: UML25-616
  • Legacy Issue Number: 7859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    P#224 – Figure 127 – Artifact (from Artifacts)

    P#769 – Figure 467 – Artifact (from Artifacts)

    Must be “Artifact (from Artifacts, Nodes)” because there is no “Artifact (from Artifacts)” in this document.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Super/ Classes / issue with Property::isComposite

  • Key: UML25-625
  • Legacy Issue Number: 7881
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious inconcistency in the specification with respect to Property::isComposite.

    In the description of Association, it states that "Composition is represented by the isComposite attribute on the part end of the association being set to true".

    But in the discussion of structured classifier parts or the discussion of profile extensions it implies the opposite. isComposite should be true for the end that is owned by the whole.

    This will have a serious impact on interchange (among other things) if different implementations put the "black diamond" on different ends of the composition...

  • Reported: UML 1.4.2 — Tue, 26 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

15.3.8 Pseudostate (from BehaviorStateMachines)

  • Key: UML25-618
  • Legacy Issue Number: 7861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.8 Pseudostate (from BehaviorStateMachines)

    Associations:

    stateMachine : Statemachine [0..1] – subsets Element::owner

    Like above: must be “subsets Vertex::container”.
    Type of stateMachine must be StateMachine (letter ‘M’ must be capital).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Super and Infra/ defualt property of Parameter::effect

  • Key: UML25-601
  • Legacy Issue Number: 7758
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I think it makes sense that the default value of Parameter::effect be 'read' (currently it is not specified).

  • Reported: UML 1.4.2 — Sun, 19 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    There is no need for any default value because Parameter::effect is 0..1.
    Disposition: Closed - No Change

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

Associations between interfaces

  • Key: UML25-602
  • Legacy Issue Number: 7777
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows
    an association between example interfaces IAlarm, ISensor, and has this
    caption:

    IAlarm is the required interface for any classifier implementing
    Isensor; conversely, Isensor is the required interface for any
    classifier implementing IAlarm.

    The text description says:

    A set of interfaces constituting a protocol may be depicted as
    interfaces with associations between them

    Is this just notation, or are associations really in the model?

    • If it is just notation, what is the model?
    • If it is the model, isn't it overly restrictive? The modeler's
      intention might be that these are both required interfaces,
      declaring that the two support classes will include an association
      between them. I thought interface were extended in UML 2 to include
      associations generally.
  • Reported: UML 1.4.2 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Super/Components/missing description of Connector::contract

  • Key: UML25-582
  • Legacy Issue Number: 7622
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association end Connector::contract, specified in figure 78 on page 135 is not documented in the description for Connector

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Super/Interactions/notation for accessing a static feature

  • Key: UML25-581
  • Legacy Issue Number: 7621
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Context:

    Invoking static or class methods on classes is incredibly common. If you look at a typical Java or .NET app (or the libraries themselves), or even Smalltalk, between 5-10% of the calls are class method calls. If you reverse engineer any Java or C# code to a sequence diagram, one should be able to see what’s a class method call on class X, versus instance calls. When you creatively draw an interaction diagram, the reader (a human or tool) should be able to know when something is a static call on a class.

    There are literally thousands of class methods in the Java and .NET core libraries. Any significant java app makes thousands of calls to these many library class methods, in addition to hundreds or thousands of calls to app-defined class methods.

    Problem:

    This is basic stuff, but the interaction diagram notation is not clear on how to show this. Tool vendors need a solution ASAP; many are in beta, and want to know the “correct” way asap, during rev eng of java code to a seq dgm, to show such calls. E.g., given the basic java code that i show in the attached example picture, how to rev eng the code to a seq dgm.
    And my book, that teaches intro OOA/D, has to show the solution – i’ve got an aug 30 publishing deadline.

    UML 1 had a way to solve this in interaction diagrams, with underlined/not underlined labels in the boxes, where not underlined indicated it was a class, and thus a class method call. But of course, that convention doesn’t work with UML 2 lifeline boxes.

    The problem can probably be solved with the appropriate label in a lifeline box, and ensuring that the context composite structure diagram relates appropriately.

    Solution:

    I’ve asked this question to Jim Rumbuagh, who gave a “convention” solution i very much like, for the lifeline box label: “ClassName : Class ”

    e.g. “Font : Class”, “Collections : Class” or perhaps “Font : Type” if reverse engineering from C#.

    e.g.., going meta and viewing the class as an instance of class Class.

    In Java and Smalltalk (for example) all classes are indeed instances of class Class. In .NET, they are instances of class Type.

    Then the lifeline box still represents an instance (of class Class or Type or whatever), and the “class messages” are still instance messages.

    I attach a diagram that gives a sequence diagram example.

    And–and i consider this important–the solution should be obviously understandable and straightforward to a novice, as is Jim’s. It corresponds to an OO programmer’s mental model. I encourage the committee members to choose a solution that is simple and obvious, that maps straightforward to the language most OO developers are working in – Java or C#, not an obscure solution.

    An outstanding problem, with bigger ramifications, is the names “Font” and “Class” in the related context diagram. Where are they defined? Of course, most of these classes will be from the core Java or .NET libraries (each have about 20,000 classes). I propose being able to declare a convention something like “assume that in this composite structure diagram there is an implicit import of the classes needed from the java libraries (or other libraries).”

    Well, some convention like that is needed in any event, because we are frequently calling instance methods on instances of java library classes – in a typical java app, 30-50% of the calls are to objects from the library. You can’t expect (because it would be too fussy/awkward/unusable) a UML modeler working in Java to re-create or have to explicit import specific parts of the Java libraries (or various common 3rd party libraries) every time they want to refer to library objects – which is frequently.

    i attach a picture to illustrate.

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

    The issue here is to be able to describe calls on static methods.
    Static Operations are defined on Types, with the property “isStatic” declared as true.
    It needs to be clarified, that every connectable element can receive messages with signatures associated with
    its static operations.

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

Missing notation for Behaviors in a BehavioredClassifier

  • Key: UML25-584
  • Legacy Issue Number: 7625
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    There's no notation specified for showing the ownedBehaviors of a BehavioredClassifier. This could be done by using another compartment in the context classifier, but this is not mentioned, nor is the syntax for the behavior and its parameters specified that I could find.

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Name without a colon for Property in Composite Structures

  • Key: UML25-583
  • Legacy Issue Number: 7624
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    In Composite Structures, under 9.3.12 Property, the following
    paragraph under "Presentation Options" under "Notation" is
    inconsistent with the rest of UML in creating a special
    interpretation of a missing notation element:

    "A property symbol may be shown containing just a single name
    (without the colon) in its name string. This implies the
    definition of an anonymously named class nested within the
    namespace of the containing class. The part has this anonymous
    class as its type. Every occurrence of an anonymous class is
    different from any other occurrence. The anonymously defined
    class has the properties specified with the part symbol. It is
    allowed to show compartments defining attributes and operations
    of the anonymously named class."

    The simple omission of notation elements is part of the option
    in virtually all UML diagrams to elide elements that aren't
    relevant or are defined and shown on other diagram views.
    Implying something to be created by the absence of an
    element breaks from user expectations.

    In this case, the most natural expectation of a simple name on
    a property box, without any colon, is that the string is just
    the name of the part or property, and that the type for the
    name, ordinarily shown using a ":Type" string, has been omitted
    from the diagram.

    The simplest way to resolve this issue is just to remove this
    paragraph from the specification. The specification would then
    revert to the default interpretation of a missing notation
    element, which is just that it isn't shown on a particular
    diagram view, not that it doesn't exist.

    The application of Composite Structure diagrams to systems
    engineering, in response to the UML for Systems Engineering
    RFP, expects to use all the flexibility that UML provides to
    include or not include diagram elements on particular views
    of a complex system, to avoid cluttering the many partial
    views that might be needed. Resolution of this issue is
    essential to avoid having a different rule for a name without
    a colon in standard UML vs. its application to systems
    engineering.

  • Reported: UML 1.4.2 — Fri, 6 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The BNF for Property does make the [’:’ <prop-type>] optional, so this is indeed an inconsistency in the
    spec. Delete the offending paragraph

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

Profiles in Compliance Level 1?

  • Key: UML25-586
  • Legacy Issue Number: 7627
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It has been suggested that Profiles should be part of Compliance Level 1 (Basic Level) rather than part of Compliance Level 2 (Intermediate Level) as currently defined. The rationale is that it gives any UML user the ability to specialize UML. We already know from experience that UML is almost ALWAYS specialized when it is used – implicitly or explicitly. Given that, we might as well provide users at all levels with the ability to use profiles. I feel that this is a reasonable suggestion.

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Redundant parameter specifications for Operation and Behavior

  • Key: UML25-585
  • Legacy Issue Number: 7626
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A Behavior can be defined in the context of a BehavioredClassifier where it must have a specification BehavioralFeature which defines its parameters and return value. A Behavior may also stand alone in order to represent procedural-based models in which case the Behavior specifies its own parameters and return result.

    There is a constraint that specifies the parameters of a Behavior in the context of a BehavioredClassifier must match the parameters of its specification BehavioralFeature. However, parameter matching is not explicitly defined. Is it match in mode, name, type, multiplicity, constraints, etc., or just type?

    A better solution would be to disallow behavior parameters if the behavior has a specification. This would eliminate the need to redundantly specify the parameters for a behavior if it has a specification, and then enforce a constraint to have them match.

    Specifically:

    1. section 13.3.3, remove constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature.

    2. add a new (second) constraint: [2] A Behavior with a specification BehavioralFeature obtains its parameters from the BehavioralFeature and cannot specify its own parameters.

    3. add a new constraint: [3] A Behavior with a specification BehavioralFeature cannot have any redefinedBehaviors. The redefinitions come from the BehavioralFeature.

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

    Discussion
    The UML 2.5 specification is clear now (in 13.2.3, under “Behavioral Features and Methods”) that how the
    parameters of a method are matched to its specifying behavioral feature is intentionally not formalized, in
    order to allow for different possible approaches to this in different user models.
    Disposition: Closed - No Change

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

UML 2 Super/Activities/Class-Activity association missing

  • Key: UML25-579
  • Legacy Issue Number: 7607
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    An activity diagram is a graphical form of method, however there is no way to assign them to a class that would contain such a method. This may be more general than activity diagrams. For example, the same could apply to sequence diagrams. Since organizing structure and behavior by class is a fundamental OO concept, we need to have a way to associate UML-expressed methods to the “organizing” class.

  • Reported: UML 1.4.2 — Fri, 30 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML2 super&infra/Profiles/ownership of Image

  • Key: UML25-578
  • Legacy Issue Number: 7598
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    In the current UML2metamodel, the ownership of the new Image metaclass is
    not specified.

  • Reported: UML 1.4.2 — Fri, 23 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Figures 103 and 121 use <> dependencies

  • Key: UML25-588
  • Legacy Issue Number: 7645
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 103 and 121 use <<create>> dependencies, which do not apply to
    the example. Standard stereotypes defines <<create>> for
    BehavioralFeature as:

    "Specifies that the designated feature creates an instance of
    the classifier to which the feature is attached. May be
    promoted to the Classifier containing the feature."

  • Reported: UML 1.4.2 — Fri, 20 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

. <> on Usage

  • Key: UML25-587
  • Legacy Issue Number: 7644
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    1. <<create>> on Usage is defined in the standard stereotypes and in the
    retired stereotypes. It is used in Figure 103 and 121 of the FAS.

  • Reported: UML 1.4.2 — Fri, 20 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

UML 2 Super/Templates/Template substitution symbol problematic

  • Key: UML25-580
  • Legacy Issue Number: 7618
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Templates use an arrow symbol inline with the text to show a binding of a template parameter

    Problem: typographic problem. the arrow symbol is not present in many common fonts (times, arial, Helvetica, …). Therefore, one must use another font for this character (e.g., ZapfDingbats). That will create some fuss at several levels, related to fonts, usability, and tools. It also creates more dependency on printing with commercial printers; if you’re a book author, you know that adding more fonts to a book is another source of error. Yes, solvable, but nice to simplify.

    Solution: use a simple symbol part of the basic character fonts (e.g., in Arial, …). I suggest ‘= ™

    Example: ArrayList<T = Person>

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Port should specialize featuringClassifier

  • Key: UML25-577
  • Legacy Issue Number: 7567
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Apparently a structural feature can be on more than one classifier,
    because the multiplicity of /featuringClassifier is 1..*. Not all the
    subtypes of StructuralFeature narrow this to one, or change it to strong
    ownership (eg, Port).

    Is it intentional that structural feature have more than one
    featuringClassifier, and not be owned by that classifier? If not, Bran,
    please assign this to classes. Otherwise, it is problem for Ports as
    well.

  • Reported: UML 1.4.2 — Wed, 7 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Active and passive

  • Key: UML25-595
  • Legacy Issue Number: 7673
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes:

    1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?)
    1a. Which may be single or possibly multiple (not sure if this is relevant)
    1b. Which may start automatically or may be explicitly started (but why whom??)

    2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke)

    3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive")

    4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary)

    Note that various combinations of these are possible, so an object could be both "active" and "passive".

    But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all?

    The current specification has a lousy definition of the terms, one that is circular.

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

    Discussion
    It may or may not be better to not use the phrases “active” and “passive”, but this is well established now in UML. The
    2.5 specification is clear that an “active” class is precisely one with “isActive=true”, and the OCL constraintsmake it
    clear what this entails. The other points discussed in the issue are also now more clearly addressed in the specification.
    Disposition: Closed - No Change

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

P.58 Missing closing bracket in second constraint

  • Key: UML25-594
  • Legacy Issue Number: 7669
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    Missing closing bracket in second constraint on P.58

    It reads:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1)

    )

    And should read:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1))

    )

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Compliance points - Diagram Interchange

  • Key: UML25-591
  • Legacy Issue Number: 7651
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    From letters from Bran Selic and Pete Rivett I learn that the Superstructure
    FTF plans to revoke Diagram Interchange as a compliance point to UML 2
    compliance. As the Chair of the Diagram Interchange FTF I urge you to make
    compliance Diagram Interchange a necessity for full compliance.

    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.

    The Diagram Interchange specification is of high quality. It is fully
    implemented by Gentleware to provide a reference, we have made cross checks
    with various other vendors that confirm high quality and interchangability.
    May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has
    implemented an XSLT transformation from XMI to SVG. It is available on his
    web site at www.jeckle.de.

  • Reported: UML 1.4.2 — Fri, 20 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

included use case wrongly referred to as the including use case

  • Key: UML25-598
  • Legacy Issue Number: 7683
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Section 16.3.5 Include (from UseCases)

    The Semantics section for Inlcude, page 603 in the 042808.pdf convenience document, says "An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case."

    For "including" read "included (or addition) " and for "base" read "base (or including)".

    The parenthetical "addition" is needed because this is the term used in the abstract syntax, which does not have "included" as a rolename. Likewise, the abstract syntax does not recognize a role called "base use case" but calls it the "includingCase".

  • Reported: UML 1.4.2 — Tue, 7 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

check the BNF example given in the text

  • Key: UML25-597
  • Legacy Issue Number: 7676
  • Status: closed  
  • Source: Merrill Lynch ( Michael Anderson)
  • Summary:

    I'd check the BNF example given in the text. While an order designator can be used with the grammer shown, the uniqueness designator seems to just be hanging out in limbo.

  • Reported: UML 1.4.2 — Sun, 5 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Bidirectional messages to a port object

  • Key: UML25-590
  • Legacy Issue Number: 7650
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How do required and provided interfaces on a port support messages from
    both inside and outside the composite? Messages to a port object sent
    from the inside of the containing composite must be declared in the
    required interface of the port object, but usually messages sent to an
    object must also be declared in the provided interfaces. Is there a
    special case for ports? Didn't see anything in the spec explaining
    this.

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Figures 120 and 121

  • Key: UML25-589
  • Legacy Issue Number: 7646
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 120 and 121 underline the association names, which doesn't
    seem consistent with the notation for instances in Figure 21.

  • Reported: UML 1.4.2 — Fri, 20 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

P.35 Typo in OCL definition of isDistinguishableFrom query

  • Key: UML25-593
  • Legacy Issue Number: 7668
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    There is a typo in the OCL definition of the isDistinguishableFrom query. The 2nd line of the definition states:

    isDistinguishable =

    This should read as:

    isDistinguishableFrom =

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

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Section: 12

  • Key: UML22-935
  • Legacy Issue Number: 8680
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "Any object nodes declared as outputs are passed out of the containing activity." Only tokens can be passed, not nodes. I suggest: "The last token from each output Activity Parameter Node is offered on the corresponding output of the calling action."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

token

  • Key: UML22-934
  • Legacy Issue Number: 8679
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "All tokens offered on the incoming edges are accepted." 1- The edges of of the terminated Activity or of the Activity Final Node? 2- In general, it is not possible to accept all tokens offered. For instance, a same token in an ObjectNode could cause two token offers throughtwo forks. Yet, only one of these offered tokens can be accepted, causing the other to be no longer offered. I suggest to delete this sentence.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

``conditional node or conditional node'' delete one.

  • Key: UML22-937
  • Legacy Issue Number: 8683
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``conditional node or conditional node'' delete one.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

add the rule of ``natural termination''

  • Key: UML22-936
  • Legacy Issue Number: 8681
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    I suggest to add the rule of ``natural termination'': An activity terminates when it has a token in each of its output Activity Parameter Nodes. This removes the need for Activity Final Nodes in most cases, and makes UML less error-prone, since it is an error to terminate without a token in each output Activity Parameter Node. It also makes the languages more consistent, since this rule is used for loops.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Delete sentence

  • Key: UML22-938
  • Legacy Issue Number: 8685
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " One frequent case is a total ordering of clauses, in which case the result is determinate." The clauses themselves can be nondeterministic, making this sentence false (although the idea is clear). Delete.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 -- Need explanations of XMI structure and usage

  • Key: UML22-933
  • Legacy Issue Number: 8678
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Appendix G is intended to contain the XMI for UML. However, there is no explanation of the meaning of its various parts, or its structure, or how it is to be used. This information should be included in the introduction to the XMI appendix in both the Infrastructure (Appendix A) and the Superstructure (Appendix G).

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

token movement

  • Key: UML22-932
  • Legacy Issue Number: 8677
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The verbs ``flow'', ``pass'', ``traverse'' seem used interchangeably to describe token movement. I suggest to reserve ``flow'' for a complex path (So e.g. p.309 should be: ``Activity edges are directed connections, that is, they have a source and a target, along which tokens may

    {\bf pass}

    ). , ``pass'' for an elementary move, and to replace ``traverse'' by ``pass''. (p.303, 304, 309, 310, etc.)

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

output tokens (02)

  • Key: UML22-931
  • Legacy Issue Number: 8676
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    In, e.g.: [4] The output tokens are now available Replace ``available'' by ``offered''. Also p.310, p.330, p.342, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: UML22-927
  • Legacy Issue Number: 8670
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    there should be a consistent convention as whether unused Paragraphs must be omitted or filled with ``None''. We suggest the first, and thus to delete the Paragraphs pp.110, 163, 216, 217, 220-262, 280, 285, 298, 301, 304, 311-320, 323, 331, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

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

text p.297

  • Key: UML22-930
  • Legacy Issue Number: 8674
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The text p.297: [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. contains, I believe, the problems: 1. Flows need not be connected by input pins, so ``inputs'' must replace ``input pins''. 2. The current text implies that all offered tokens are consumed when an action starts, which is not intended, we believe (specially if two offers are incompatible). 3. ``precluding them from being consumed by any other actions'' does not belong here. We suggest: To start, the action must have at least one token per input. When starting, it accepts simultaneously exactly one token per input, then creates an action execution.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section 12 (03)

  • Key: UML22-929
  • Legacy Issue Number: 8672
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``Result pin'', ``Output pin'' or even ``Result output pin'' seem used interchangeably throughout the text. Replace by ``Output pin''.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section 12 (02)

  • Key: UML22-928
  • Legacy Issue Number: 8671
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A section ``Use'' containing methodological indications about the use of the construct should be added. Currently, such remarks are randomly spread into ``Description'', ``Semantics'', etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: UML is methodology independent; there should not be any methodological advice in the spec at all. Revised Text: N/A Disposition: Closed, no change

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

UML 2 Super / Conformance / inconsistencies

  • Key: UML22-853
  • Legacy Issue Number: 8459
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Summary:

    There are two fundamental inconsistencies in the way that conformance is defined:
    · BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2.
    · Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level.

    Recommendation:

    For the first item, move CommonBehaviors::Communications from L2 to L1

    For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 335 - 336 of ptc/2006-04-01

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

UML 2 Super / General / missing merges

  • Key: UML22-852
  • Legacy Issue Number: 8458
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Compliance level L3 references, but does not merge:

    Superstructure::Logical View::UML::CommonBehaviors

    Superstructure::Logical View::UML::CompositeStructures

    There are a number of diagrams in the UML2 Rose model that contain unlabeled dependencies between packages. In particular, Activities, Interactions, StateMachines, and UseCases have dependencies to CommonBehaviors that are unlabeled. See diagram UML/Behavior Packages and UML/UML Top-Level Packages.

    Since CommonBehaviors does not contain any classes, it does not necessarily need to be merged into any compliance level. Instead, the packages it contains are merged as needed.

    Recommendation:

    Remove all unlabeled dependencies between packages, or mark them as either package imports or package merges as needed.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Super / General / improper subsetting

  • Key: UML22-851
  • Legacy Issue Number: 8457
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge.

    Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier

    {subsets classifier}

    Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization

    {subsets clientDependency}

    Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency}

    Recommendation:

    These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 330 - 333 of ptc/2006-04-01

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

UML 2 Super / General / invalid subset rule too strict

  • Key: UML22-855
  • Legacy Issue Number: 8462
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model.

    Recommendation:

    As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Super / Kernel / excessive restriction on redefinition

  • Key: UML22-854
  • Legacy Issue Number: 8461
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In section 7.3.44 on pg. 130 of ptc/04-10-02 there is a constraint that states: “All redefinitions shall be made explicit with the use of a

    {redefines <x>}

    property string.” Unfortunately, this is violated in numerous places in the metamodel. This results in numerous inconsistencies in the metamodel.

    Recommendation:

    As a practical resolution with minimal impact, it is recommended that this restriction be removed. This means that the use of the same association end name for a given association end implies a redefinition of the corresponding association end in an ancestor class.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Super / Common Behaviors / missing multiplicites

  • Key: UML22-856
  • Legacy Issue Number: 8463
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 318 on page 463, the multiplicities of DurationObservationAction::duration and TimeObservationAction::now are not specified. This results in violations of the redefinition rules for these association ends.

    Recommendation:

    Set the multiplicities for these association ends to 1, to conform to the multiplicity of WriteStructuralfeatureAction::value association end that they redefine

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Action Semantics Section: 9.5

  • Key: UML22-835
  • Legacy Issue Number: 8413
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    The JumpAction->Inputs section documents jumpOccurrence:RuntimeInstance[1..1]. The second sentence of the documentation contains a typo that makes the meaning of the documentation unclear. Please re-write the second sentence.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Specification: Action Semantics Section: 9.5

  • Key: UML22-834
  • Legacy Issue Number: 8412
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    Figure 27 illustrates a directed association from JumpHandler to HandlerAction. Yet the documentation on page 115 says there is a reference from HandlerAction to JumpHandler (jumpHandler 1..1). Where is the association from HandlerAction to JumpHandler? The multiplicity at the (non-navigable) JumpHandler end of A_HandlerAction_JumpHandler is 0..*.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Collaborations / improper subset

  • Key: UML22-850
  • Legacy Issue Number: 8456
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets “Classifier::occurrence” and should subset “Classifier::collaborationUse”. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175.

    Recommendation:

    Change figure 100 as specified above.

    In the entry for Associations of Classifier on page 175, replace the parenthesized expression:

    Subsets Classifier.occurrence

    By the expression:

    Subsets Classifier.collaborationUse

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Profiles::ObjectNode has wrong default multiplicity

  • Key: UML22-849
  • Legacy Issue Number: 8454
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

    Recommendation:

    Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Profiles::ExtensionEnd has wrong default multiplicity

  • Key: UML22-848
  • Legacy Issue Number: 8453
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default.

    Recommendation:

    Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OK, that is a more accurate specification.

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

Should Profiles::Image be an Element?

  • Key: UML22-845
  • Legacy Issue Number: 8449
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation.

    Recommendation:

    Make Profiles::Image a subclass of Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 323/324 of ptc/2006-04-01

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

Remove redundant superclass for Element

  • Key: UML22-847
  • Legacy Issue Number: 8452
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Abstractions::Comments::Comment is a subclass of Abstractions::Comments::Element which is a subclass of Abstractions::Ownerships::Element. The resolution to issue 6279 redefines package merges such that the Element superclass of Element should be removed.

    Recommendation:

    Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

OCL for Property::opposite() is incorrect:

  • Key: UML22-846
  • Legacy Issue Number: 8451
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() should it be:

    opposite =

    if owningAssociation->empty() and association.memberEnd->size() = 2 then

    let otherEnd = (association.memberEnd - self)->any() in

    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif

    else Set {}

    endif

    Recommendation:

    Fix the operation definition.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 14.3.24

  • Key: UML22-815
  • Legacy Issue Number: 8348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Change the name of the enumeration list to MessageSortKind on fig. 329, as the section heading, and in sub-section Description

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Profiles:Extension End

  • Key: UML22-756
  • Legacy Issue Number: 8256
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Profiles:Extension End - the spec needs to be clear on the behaviour of the

    {required}

    property of an extension if the extending stereotype in question
    has subclasses. Are those sub-stereotypes also required?

  • Reported: UML 1.4.2 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 super/templates/

  • Key: UML22-763
  • Legacy Issue Number: 8265
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of Classifier and ClassifierTemplateParameter indicates that there may be additional constraint placed on the parameter. Examples and notation also indicate that. However, there is no defined way to express that constraint in the metamodel (at the very least it is not obvious and is very open for interpretation). The metamodel must provide a meta-association from ClassifierTemplateParameter to Classifier to represent the constraining classifier.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 232/233 of ptc/2006-04-01

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

UML 2 Super/templates/inexplicable constraint on defaults

  • Key: UML22-762
  • Legacy Issue Number: 8264
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of TemplateParameter states that the parameter cannot own at the same time its parametered element and default element. The ownership of those two elements is mutually exclusive. It is also expressed as an OCL constraint. However, there is no justification offered in the spec for this constraint and one is not obvious. The constraint should be removed.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed, cannot see any justification for this. Remove the constraint.

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

MultiplicityElement BNF too restrictive

  • Key: UML22-731
  • Legacy Issue Number: 8226
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of uniqueness-designator without preceding order-designator.
    This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super which just shows

    {unique}

    .

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Used of "Redefines ...from Abstractions" in descriptions is misleading

  • Key: UML22-734
  • Legacy Issue Number: 8229
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example 11.7.2 of Infra: the name property states
    Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement.

    However there is no redefinition occurring; nor would it make sense.

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

BNF Notation for Operation is too restrictive

  • Key: UML22-733
  • Legacy Issue Number: 8228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 11.8.2 (Infra) and 7.3.36 (Super) the notation BNF requires a

    {<oper-property}

    any time there is a ':' after the operation name

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Incomplete BNF for Property

  • Key: UML22-732
  • Legacy Issue Number: 8227
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In BNF Notation for Property (11.3.4 of Infra, 7.3.44 of Super), <prop-modifier> is defined but never refered to

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section: 9.3.3

  • Key: UML22-636
  • Legacy Issue Number: 8110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect page number for reference for "Property" under Description

  • Reported: UML 1.4.2 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

InfrastructureLibrary defines, but should not use package merge

  • Key: UML22-561
  • Legacy Issue Number: 7956
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2.

    Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

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

section 2.10.4.1 detailed semantics of collaborations

  • Key: UML22-557
  • Legacy Issue Number: 7948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:

    "However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."

    Allow me to illustrate my interpretation of this section by means of an example.

    Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
    Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?

    Then, the spec goes on:

    "Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."

    So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.

    Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Interactions

  • Key: UML22-559
  • Legacy Issue Number: 7950
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the description of the Graphic Paths for a Communication Diagram I can
    find no mention of what the lines between the Lifelines correspond to -
    although I did find this in the description of Message: "On Communication
    Diagrams, the Messages are decorated by a small arrow along the connector
    close to the Message
    name and sequence number in the direction of the Message." I assume this
    means that the lines correspond to a Connector model element.

    The Graphic Paths section should be updated to include this information and
    justification added as to why a Connector is needed in order for Messages to
    be shown between two lifelines on a Communication Diagram (this seems an
    overly tight constraint to me).

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Section: 7.3.44 - OCL incorrect

  • Key: UML22-558
  • Legacy Issue Number: 7949
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [1] If this property is owned by a class, associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6201 for disposition

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

Section: 7.2.8

  • Key: UML22-555
  • Legacy Issue Number: 7946
  • Status: closed  
  • Source: INSA ( Jean Louis Sourrouille)
  • Summary:

    In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel.

  • Reported: UML 1.4.2 — Tue, 23 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Super Basic Interactions

  • Key: UML22-560
  • Legacy Issue Number: 7951
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Basic Interactions includes SendOperationEvent whose superclass is
    MessageEvent, which is in CommonBehaviors::Communications.

    The problem is that the Basic Interactions package is in Level 1, but
    CommonBehaviors::Communications is in Level 2.

    The same is true for SendSignalEvent. In fact Event itself is also in
    Communications so there's a problem with the whole set of Event subtypes
    defined in BasicInteractions.

    Also BasicActions::SendSignalAction references Communications::Signal

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change

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

Classes

  • Key: UML22-556
  • Legacy Issue Number: 7947
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8069 for disposition

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

Stereotypes applying in UML 2.0

  • Key: UML22-623
  • Legacy Issue Number: 8094
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I have some questions regarding stereotypes using in UML 2.0.

    1. How to declare user defined stereotype in the model? Should class with stereotype <<metaclass>> and metaclass name be created in the model? How to declare stereotype <<metaclass>>?

    2. Is some relationship between stereotyped model element and stereotype instance exist? Where stereotype instance should be created (contained) and how model element can collect all applied stereotypes?

  • Reported: UML 1.4.2 — Mon, 17 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Terminology Issue

  • Key: UML22-593
  • Legacy Issue Number: 8042
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    When we build a state machine (nee State chart diagram) to define the behavior of a Dog, say, each dog instance has its own state.

    In other words, each copy of the state machine diagram has it's own state. What is the official term for each-copy-of-the-state-machine, the entity that has state. We need to be able to say "The <state machine thing> for Fido is in the state 'Barking'" and "The <state machine thing> for Rover is in the state Sleeping".

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The submitter does not raise an issue against the specification, but asks a question for clarification. Such terminology might be useful in explaining the semantics, but is not required for the specification. Disposition: Closed, no change

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

Section: 10.4

  • Key: UML22-657
  • Legacy Issue Number: 8143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 8 Node Reference says Node has keyword options <<device>> and <<execution environment>> but these are not mentioned in the Node section nor are they diagrammed anywhere.

  • Reported: UML 1.4.2 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

ReduceAction

  • Key: UML22-565
  • Legacy Issue Number: 7977
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    It has come to my attention that the removal of the ReduceAction (fair
    enough) requires the use of a variable (a very bad idea) to construct an
    alternative specification.

    To do something like Reduce(<data expression>, Add) in UML 1.5, you
    would have to say:

    • An activity/structure node with variable Sum.
    • The expansion region takes the collection as input and has no
      output. In this case, the output collection will have only one
      element in it.
    • In the region, edges coming from/going to the inputs/outputs take
      elements from the input collections and put elements in the output
      collections.
    • The region uses CallOperationAction with operation timeofLastCall to
      get the time and CallBehaviorAction on the (primitive)
      FunctionBehavior for addition and updates the variable.
    • After the region is complete, the variable has the sum in it.

    The 1.5 Action Model included variables so that those who "needed" them
    could have them. However, the introduction of variables changes the
    static-single-assignemnt nature of the language and would now require
    data-flow analysis of a developer model to work out what is happening.
    Before all we had to do was scan for Variable Actions and reject the
    developer model so proposed.

    In other words, those of us in the translation business did not need
    variables, and we could ignore those models that used them. Now we're
    stuck.

    Topic: ReduceAction

    UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
    to elements of a collection until only only element is left. It did not
    constrain order or concurrency of application. It was replaced with
    ExpansionRegion UML 2, which requires commitment to order and
    concurrency.

  • Reported: UML 1.4.2 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Corrections to issue description:

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

UML 2 Super / Incorrect statement on port visibility

  • Key: UML22-564
  • Legacy Issue Number: 7973
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The updated UML spec p162 states:

    "UML Superstructure 2.0 Draft Adopted Specification

    A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port
    symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its
    visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it
    is protected by default)."

    This text was supposed to be removed by the FTF – the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #).

  • Reported: UML 1.4.2 — Fri, 10 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-553
  • Legacy Issue Number: 7939
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Inconsistent use of 'Element' between MOF and UML

  • Key: UML22-549
  • Legacy Issue Number: 7889
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
    MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.

    Proposed resolution:

    MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.

  • Reported: UML 1.4.2 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Missing XMI tags in spec and XMI rendition of metamodel

  • Key: UML22-548
  • Legacy Issue Number: 7783
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue applies to Infrastructure, Superstructure and MOF

    In the XMI for Superstructure for example (in OMG document ad/03-04-02),
    while this does use the nsuri for MOF (using the correct form
    xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
    contain any XMI tags to define for UML what its nsuri and prefix should
    be: which are needed in order to generate the UML xsd.
    Neither does the XMI for the MOF Core itself contain an XMI tag to
    define that the nsuri and prefix should be as just quoted.

    In any case these important values should be included in the
    specification documents as well as being buried in tags in the XMI
    files.

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

    No Data Available

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

Move Comment into Basic and add Kind

  • Key: UML22-547
  • Legacy Issue Number: 7782
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Move Comment into Basic and add Kind
    The ability to annotate and describe elements and diagrams is pretty
    fundamental so should be included in Basic.
    There should also be the recognition that there are different kinds of
    comment: for example most tools have a dialog allowing people to enter a
    Description for an Element; and separately may allow the element to be
    annotated on diagrams in a particular context. At the moment there is no
    way to distinguish these.
    The UML Metamodel itself is an example of the need for different kinds
    of Comment: each Class has a number of distinct sections (e.g.
    Description, Semantics, Notation).
    Hence there should be a 'kind' attribute on Comment to reflect this.

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

    Disposition: Closed, no change

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

Unconsistent Profile extension description (02)

  • Key: UML22-546
  • Legacy Issue Number: 7757
  • 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.
    .

    Discussion

    In Profiles:Profile:semantics, change the first sentence

    A profile by definition extends a reference metamodel or another profile.

    Into

    A profile by definition extends a reference metamodel.

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

    No Data Available

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

Unconsistent association extension description

  • Key: UML22-545
  • Legacy Issue Number: 7756
  • 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.
    .

    Discussion

    In Profiles:Profile:semantics, change the paragraph

    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.

    Into

    As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.

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

    No Data Available

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

Problem with diagram references in Profiles section

  • Key: UML22-551
  • Legacy Issue Number: 7909
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
    An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").

    But the 2 references should be to Figure 456 and Figure 461 respectively.

  • Reported: UML 1.4.2 — Sun, 14 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Design principles

  • Key: UML22-550
  • Legacy Issue Number: 7908
  • Status: closed  
  • Source: none ( Markus Flueckiger)
  • Summary:

    have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is

  • Reported: UML 1.4.2 — Wed, 10 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-552
  • Legacy Issue Number: 7938
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7939 for disposition

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

Meaning of navigability

  • Key: UML22-140
  • Legacy Issue Number: 8921
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean.

    It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient.

    I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability.

  • Reported: UML 1.4.2 — Fri, 1 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

page 134, Chapter 11.4.1

  • Key: UML22-138
  • Legacy Issue Number: 8904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    on page 134, Chapter 11.4.1, you write:

    "Constructs::Classifier merges the definitions of Classifier from Basic and
    Abstractions. It adds specializations from Constructs::Namespace and
    Constructs::Type."

    In Basic there is no definition for "Classifier".

  • Reported: UML 1.4.2 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

page 97, Chapter 10.2.2. MultiplicityElement

  • Key: UML22-137
  • Legacy Issue Number: 8903
  • Status: closed  
  • Source: Anonymous
  • Summary:

    On page 97, Chapter 10.2.2. MultiplicityElement, you write

    "Constructs::Relationship reuses the definition of Relationship from
    Abstractions::Relationships. It adds a specialization to
    Constructs::Element."

    which seems to be a little mislead copy-paste-action.

  • Reported: UML 1.4.2 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

ObjectNode

  • Key: UML22-135
  • Legacy Issue Number: 8895
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ObjectNode is abstract, so CentralBuffer or DataStore should be always used in Activity diagram. It is normal?
    CentralBuffer and DataStore are described as "special cases of ObjectNodes", but simple ObjectNode can't exist.

  • Reported: UML 1.4.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ObjectNode is a general abstraction. Only its subclasses (which include ActivityParameterNode, InputPin and OutputPin, in addition to CentralBufferNode and DataStore) have concrete syntax and semantics.
    Revised Text:
    None
    Disposition: Close, no change

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

UseCase and Actors

  • Key: UML22-134
  • Legacy Issue Number: 8893
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association.

  • Reported: UML 1.4.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Section: 10.1 Types Diagram

  • Key: UML22-128
  • Legacy Issue Number: 8882
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    The Elements Type, NamedElement and TypedElement of the package Core::Basic are (ambiguous and redundant) redefinitions of the types Type, TypedElement (Core::Abstractions::TypedElements), and NamedElement (Core::Abstractions::Namespaces). Why is that?

  • Reported: UML 1.4.2 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Figure 179 (Control nodes)

  • Key: UML22-93
  • Legacy Issue Number: 8673
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    Figure 179 (Control nodes) is not a complete partition of ControlNode: ForkNode, JoinNode, etc. are missing.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was resolved by the resolution to issue 7319 (during the UML 2.0 FTF), which added the FundamentalActivities package and resulted in changes to related diagrams.
    Revised Text:
    None
    Disposition: Duplicate

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

Section: Actions

  • Key: UML22-101
  • Legacy Issue Number: 8702
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add OCL to constraints in Actions chapter

  • Reported: UML 1.4.2 — Tue, 26 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints that can be specified in OCL have been in UML 2.5.
    Disposition: Closed - No Change

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

CombinedFragment Loop notation

  • Key: UML22-100
  • Legacy Issue Number: 8698
  • Status: closed  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    There seems to be some confusion about how to show the notation for the loop combinedFragment. Some tools show only the minint and maxint for the loop InteractionOperator but do not allow you to show the full specification in the InteractionOperand. This is a limitation that allows for the modeling of simple for loops without an additional guard to model do while and do until types of loop constructs. I would suggest the UML Superstructure 2.0 be updated with the following:

    In Section 14.3.3 in Notation with header Loop:
    Place a simple example of a loop combined fragment with a InteractionOperand guard as well as a minint and maxint
    Add a paragraph that says something like, "In those cases where more control over the number of passes through the CombinedFragment is necessary use a separate InteractionConstraint. This InteractionConstraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing Loop InteractionOperand. If this separate InteractionConstraint is true, the loop continues, otherwise the loop terminates."

  • Reported: UML 1.4.2 — Thu, 21 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

editorial in section 12

  • Key: UML22-98
  • Legacy Issue Number: 8689
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "... is eligible for execution when it receives control tokens from each of its predecessor clauses. " Should read ``a control token''

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2 Different constraints for Property in Super and Infra

  • Key: UML22-97
  • Legacy Issue Number: 8688
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Infrastructure has an additional constraint on Constructs::Property (pg. 128):

    [2] A specialization of a composite aggregation is also a composite aggregation.

    that does not exist in the Superstructure. These two should be made consistent; either the constraint appears in both places or in neither.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It appears a sentence was removed from superstructure but not InfrastructureLibarary.
    Revised Text:
    In section 11.3.5, subsection Constraints, change:
    [2] A specialization of a composite aggregation is also a composite aggregation.A multiplicity of a composite aggregation must not have an upper bound greater than 1.
    To:
    [2] A multiplicity of a composite aggregation must not have an upper bound greater than 1.

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

rewording isuse?

  • Key: UML22-96
  • Legacy Issue Number: 8687
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "When an execution of an activity makes a token available to the input of an expansion region, the expansion region consumes the token and begins execution." ``the input'' is ill-defined, since an expansion region has several inputs, see Examples in the same subsection. It should read: "When an execution of an activity makes a token available to each of the inputs of an expansion region (implicit join), the expansion region consumes these tokens and begins execution."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This should be merged with Issue 8725.
    Revised Text:
    None
    Disposition: Duplicate/merged

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

reword sentence

  • Key: UML22-95
  • Legacy Issue Number: 8686
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " Any test section with a predecessorClause " Should be: " Any test section whose parent clause has a predecessorClause "

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

A test cannot be empty

  • Key: UML22-94
  • Legacy Issue Number: 8682
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A test cannot be empty since it has at least a decider: 0..* should be changed to 1..*.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Events in Sequence diagram

  • Key: UML22-114
  • Legacy Issue Number: 8760
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd are MessageOccurrenceSpecification that redefines "event"
    > as MessageEvent.
    > DestructionEvent and CreationEvent are not subclasses of
    > MessageEvent, so can't be on message end, so how to map "create
    > message" and "destroy message"?

    This is an open item. The one thing that was highly contested in the FTF was that there be explicit create and destroy messages. So, they are no longer in MessageKind.

    > Also unclear how to map Reply
    > message, what kind of events should be in reply message ends?

    You should check with Oystein.

    > Events are owned by package, it's very uncomfortable (at least two
    > nesting levels from Interaction), it think they should be owned by
    > Interaction.

    No, because the whole idea of events is that they have to be shared by the sender's and reciever's behaviors. It makes little sense to define them in an Interaction.

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

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

1. Deployment

  • Key: UML22-113
  • Legacy Issue Number: 8757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    1. Deployment
    > What is client and what is supplier for this relationship?
    > Why DeploymentTARGET has word "target" in name but subsets "source"
    > for Dependency?

    The meaning of "client" and "supplier" in Dependency is pretty arbitrary and depends on one's point of view. I don't recall the reasoning behind this particular choice, but it may have to do with the direction of the arrow more than anything else. Guus probably wanted the arrow to go from the artifact to the node because it looked more natural to him. Perhaps Guus can explain – I've copied him on this reply.

    However, there is definitely a bug here since "client" and "supplier" are not derived unions, hence, they cannot be subset as shown in figure 126. This may have already been raised as an issue. I'll have to check. I suggest that you raise a formal issue in any case.

    > And why notation examples are from Artifact to Node (arrow near
    > Node, but Node is "client" in model).

    Ostensibly, this is explained by what I wrote above. However, there seems to be a deeper problem here: note that Dependency::supplier and Dependency::client are not specializations of DirectedRelationship::target and DirectedRelationship::source respectively, as I would have expected (otherwise it does not seem to make sense to subclass DirectedRelationship at all). I do not understand why this is so, it does not seem to make sense. It may have to do with the constraints that Dependency did not want to impose on supplier and client, but I am not sure. This needs further study and, likely, an issue to be raised.

    > "Location" attribute of Deployment should be DeploymentTarget, not Node.

    You are correct. Please raise an official issue on this through issues@omg.org

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Questions about the appropriateness of the use of Dependency and the directionality of theway its ends are connected
    are covered by other issues, such as 10781. In any case, such changes require modifications to the metamodel and are
    thereby out of scope for the UML 2.5 FTF.
    There no requirement that client and supplier must be, or must subset, derived unions. In Clause 19.5, the location
    attribute of Deployment is clearly identified as type DeploymentTarget.
    Disposition: Merged with 10781

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

Nested Nodes

  • Key: UML22-115
  • Legacy Issue Number: 8763
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Node has nestedNodes collection that redefines "nestedClassifier",
    > but Node have Generalizations to Class from StructuredClasses that
    > has no Generalization to Class from Core package, so Nodes don't
    > inherits "nestedClassifier".

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Return message

  • Key: UML22-120
  • Legacy Issue Number: 8785
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    How return message should be mapped into model? What kind of events are on message ends, how return values should be mapped? Should return values be arguments of message? How return message can be recognized in the model?
    How variable assignment should be mapped and related with message?

  • Reported: UML 1.4.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There has never been anything called a "return message", but the issue is probably about "reply message" which we had forgotten to give a messageSort, but that has been fixed. The other issues are related, but are also asking for clarification of metamodel encoding. This should eventually be picked up again if necessary during a major revision.
    Disposition: ClosedOutOfScope

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

multiplicity should not be used/shown in an communicates association

  • Key: UML22-121
  • Legacy Issue Number: 8854
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 404 - Example of the use cases and actors for an ATM system
    (The ATM example is repeated in Figure 410.)

    If you think multiplicity gives value to this diagram, please add additional text and explain the usage of multiplicity (1, 0..1, 0..*) in this diagram.

  • Reported: UML 1.4.2 — Fri, 3 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18072

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

inconsistent description

  • Key: UML22-73
  • Legacy Issue Number: 8332
  • Status: closed  
  • Source: none ( Rui Xu)
  • Summary:

    There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    An internal transition IS a self-transition. It does not exit or enter the state to which it is attached. Internal transitions
    belong to states and not to regions, as seemed to be implied by the issue summary. This is explicitly stated in the
    specification. From the point of view of firing rules, they are no different than for any other transition. If there are
    conflicts (and, there CAN be conflicts between two internal transitions), they are resolved the same way as all other
    conflicts based on the firing rules for such cases. Hence, the ambiguity discussed in the summary of the issue does not
    exist.
    (However, after reading the text, it seems that there is no explicit statement on how the issue of conflicting transitions
    of the same priority is resolved. Presumably, this is one of those “intentionally left unspecified” cases; i.e., it is an
    implementation choice. But, this is a different and more general issue that needs to be dealt with separately.)
    Disposition: Closed - No Change

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

UML 2 Super / Kernel / invalid restriction in isConsistentWith()

  • Key: UML22-80
  • Legacy Issue Number: 8460
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A derived union association end represents a union of all of its subsets. The leaf subsets clearly have to be non-derived. However, in operation Property::isConsistentWith(), defined on page 127 of ptc/-04-10-02, it is stated that a derived property cannot be redefined by a non-derived property. This means that all such subsets of derived unions will be incorrect. Clearly, this restriction should be removed.

    Recommendation:

    Remove the constraint:

    (prop.isDerived implies isDerived)

    from the operation Property::isConsistentWith() (on pg. 127)

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see below

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

namespace

  • Key: UML22-67
  • Legacy Issue Number: 8246
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

  • Reported: UML 1.4.2 — Sat, 5 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

Figure 89 on page 158 is incorrect

  • Key: UML22-66
  • Legacy Issue Number: 8168
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way.

    More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7.

    Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes"

  • Reported: UML 1.4.2 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text.
    Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2.
    The third aspect of this issue is a duplicate of 12236, already resolved.

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

UML2/Infra section 11.6.2/ Enumerations should not have attributes

  • Key: UML22-70
  • Legacy Issue Number: 8274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
    below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
    The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).

    Proposed resolution:
    Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

  • Reported: UML 1.4.2 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Enumeration literals are immutable, so writeable attributes do not make sense. But read-only attributes do
    make sense: they don’t need to be derived. The current description of equality of EnumerationLiterals needs
    improvement. Operations on enumerations are allowed.
    This also resolves 17933

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

Default values for ValueSpecification are not specified properly

  • Key: UML22-79
  • Legacy Issue Number: 8450
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are a few cases when the default is documented as a ValueExpression, as follows:

    • JoinNode.joinSpec = {default value is" and"}
    • ActivityEdge.guard= {default value is "true"}

    These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification.

    They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be:

    +guard = LiteralBoolean(true)

    The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true.

    Recommendation:

    Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

isComposite inconsistency in UML 2.0 and MOF 2.0

  • Key: UML22-46
  • Legacy Issue Number: 7910
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: – isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. – However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()>isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()>isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

  • Reported: UML 1.4.2 — Mon, 15 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

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

should retain Comment and its associations to Element

  • Key: UML22-47
  • Legacy Issue Number: 7958
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

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

Use case extension inconsistencies

  • Key: UML22-49
  • Legacy Issue Number: 7993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
    Therefore it seems that the Extend.extendedCase property is redundant and should be derived.

    Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the

    {subset}

    .

    Proposed resolution
    -----------------------------

    1) Update Figure 401 to replace +extendedCase by +/extendedCase

    2) Update Figure 401 to replace +useCase by +useCase

    {subsets owner}

    .

    3) Section 16.3.3 Extend: update the Associations section to replace:
    extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

    by

    /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

    4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
    No additional associations

    by

    useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)

  • Reported: UML 1.4.2 — Mon, 20 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

ClassifierInState not supported in UML2.0 ?

  • Key: UML22-54
  • Legacy Issue Number: 8071
  • Status: closed  
  • Source: GOO Tech ( Birol Berkem)
  • Summary:

    In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.

    Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

  • Reported: UML 1.4.2 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance.

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

Association specialization semantics

  • Key: UML22-53
  • Legacy Issue Number: 8023
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean?

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 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

Correction to 7336

  • Key: UML15-12
  • Legacy Issue Number: 7671
  • Status: closed  
  • Source: NIST ( Mr. 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 ( Mr. 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 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 ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Mr. 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