${taskforce.name} Avatar
  1. OMG Task Force

UML 2.4 RTF — All Issues

  • Key: UML24
  • Issues Count: 131
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML24-152 navigation only possible to generalization but not to specializations of elements UML 2.3 UML 2.4 Closed; No Change closed
UML24-127 Statement mistake UML 2.3 UML 2.4 Resolved closed
UML24-126 Constraint is Wrong UML 2.3 UML 2.4 Resolved closed
UML24-130 MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-128 Figure 7.31 propose an “association-like” notation for attributes UML 2.3 UML 2.4 Resolved closed
UML24-129 Section numbering UML 2.3 UML 2.4 Resolved closed
UML24-124 UML 2.4: “Figure 7.31 shows the dot at the wrong end.” UML 2.3 UML 2.4 Resolved closed
UML24-125 Wrong Classifier Name UML 2.3 UML 2.4 Resolved closed
UML24-123 UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified UML 2.3 UML 2.4 Resolved closed
UML24-118 Property.isReadOnly is redundant with StructuralFeature.isReadOnly UML 2.3 UML 2.4 Resolved closed
UML24-120 Deep history for orthogonal states UML 2.3 UML 2.4 Resolved closed
UML24-121 Big UML 2.4 problem: missing defaults in XMI UML 2.3 UML 2.4 Resolved closed
UML24-119 Parameter semantics related to Behavior and BehavioralFeature UML 2.3 UML 2.4 Resolved closed
UML24-122 Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions UML 2.3 UML 2.4 Resolved closed
UML24-116 Fix minor inconsistencies between infrastructure specification document & metamodel UML 2.3 UML 2.4 Resolved closed
UML24-117 Be explicit that type does not need to be set for LiteralBoolean etc. UML 2.3 UML 2.4 Resolved closed
UML24-113 Wrong constraint on Operation::bodyCondition UML 2.3 UML 2.4 Resolved closed
UML24-114 Operation with multiple return parameter UML 2.3 UML 2.4 Resolved closed
UML24-115 Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)? UML 2.3 UML 2.4 Resolved closed
UML24-111 Problem with ExtensionEnd::lower UML 2.3 UML 2.4 Resolved closed
UML24-108 UML state machines: inconsistent subset of StateMachine::extendedStatemachine UML 2.3 UML 2.4 Resolved closed
UML24-110 UML 2.4 - ConditionalNode - Semantics UML 2.3 UML 2.4 Resolved closed
UML24-112 stereotype <> for defining parameterized classes is nowhere defined UML 2.3 UML 2.4 Resolved closed
UML24-109 DecisionNode at all guards evaluated to false UML 2.3 UML 2.4 Resolved closed
UML24-107 isDerived with DefaultValue UML 2.3 UML 2.4 Resolved closed
UML24-101 EnumerationHasOperations : UML::VisibilityKind::bestVisibility UML 2.3 UML 2.4 Resolved closed
UML24-103 Give all constraints unique names within their context. UML 2.3 UML 2.4 Resolved closed
UML24-99 InstanceValue has no type UML 2.3 UML 2.4 Resolved closed
UML24-105 UML 2.4 - Interaction UML 2.3 UML 2.4 Resolved closed
UML24-100 Parameter have Effects UML 2.3 UML 2.4 Resolved closed
UML24-97 Derived properties that are not marked read-only UML 2.3 UML 2.4 Resolved closed
UML24-98 Multiplicity Element Is MultiValued With Default Value UML 2.3 UML 2.4 Resolved closed
UML24-102 The metamodel contains instances of Model UML 2.3 UML 2.4 Resolved closed
UML24-106 Property::isID should not be optional UML 2.3 UML 2.4 Resolved closed
UML24-104 Change all properties typed by data types to aggregation=none UML 2.3 UML 2.4 Resolved closed
UML24-96 Redefinition of association-owned ends requires association generalization UML 2.3 UML 2.4 Resolved closed
UML24-94 Fix association end multiplicities UML 2.3 UML 2.4 Resolved closed
UML24-93 Fix 14977 vs. 14638 UML 2.3 UML 2.4 Resolved closed
UML24-92 Association-owned association end name changes UML 2.3 UML 2.4 Resolved closed
UML24-95 Association conflicts with MemberEnds IsDerived flags UML 2.3 UML 2.4 Resolved closed
UML24-88 UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format UML 2.3 UML 2.4 Resolved closed
UML24-91 DestructionOccurenceSpecification text in Semantics still refers to events UML 2.3 UML 2.4 Resolved closed
UML24-87 The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake UML 2.3 UML 2.4 Resolved closed
UML24-90 DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification UML 2.3 UML 2.4 Resolved closed
UML24-89 Message's signature is still derived property (in text only): UML 2.3 UML 2.4 Resolved closed
UML24-86 Missing subsetting of redefinitionContext by Property::owningAssociation UML 2.3 UML 2.4 Resolved closed
UML24-83 isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-85 redefinitionContext of Property UML 2.3 UML 2.4 Resolved closed
UML24-81 UML2.4: StandardProfileL2 & L3 are incomplete as delivered UML 2.3 UML 2.4 Resolved closed
UML24-79 "isStatic" property of Feature no longer appears in any diagram UML 2.3 UML 2.4 Resolved closed
UML24-84 bodyCondition and isQuery UML 2.3 UML 2.4 Resolved closed
UML24-78 coveredBy : InteractionFragment [0..1] should be [*] UML 2.3 UML 2.4 Resolved closed
UML24-82 Operation::isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-80 xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element UML 2.3 UML 2.4 Resolved closed
UML24-77 The stereotype «Create» and keyword «create» are both defined in the UML 4 document UML 2.3 UML 2.4 Resolved closed
UML24-76 Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency UML 2.3 UML 2.4 Resolved closed
UML24-75 Qualified name is incorrectly claimed to be unambiguous UML 2.3 UML 2.4 Resolved closed
UML24-74 "unique" annotation UML 2.3 UML 2.4 Resolved closed
UML24-73 Ambiguous constraints for transitions UML 2.3 UML 2.4 Resolved closed
UML24-71 UML 2.4: Inconsistent rendering of OCL in UML metamodel UML 2.3 UML 2.4 Resolved closed
UML24-69 UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype UML 2.3 UML 2.4 Resolved closed
UML24-72 Typo: isStric => isStrict UML 2.3 UML 2.4 Resolved closed
UML24-70 Over-general sentence about MOF and Profiles UML 2.3 UML 2.4 Resolved closed
UML24-68 UML 2.4: Add package:URI UML 2.3 UML 2.4 Resolved closed
UML24-67 UML 2.4: Add Property::isId UML 2.3 UML 2.4 Resolved closed
UML24-65 NamedElement::clientDependency constrained to subset DirectedRelationship::source UML 2.3 UML 2.4 Resolved closed
UML24-66 UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds UML 2.3 UML 2.4 Resolved closed
UML24-61 Create UML 2.3 UML 2.4 Resolved closed
UML24-59 split the addition of generalization relationships among association in 14977 in two parts UML 2.3 UML 2.4 Resolved closed
UML24-64 Figure 7.10 shows Feature::isStatic as abstract UML 2.3 UML 2.4 Resolved closed
UML24-62 It seems odd to say that Service “computes a value”. UML 2.3 UML 2.4 Resolved closed
UML24-63 issues relating to Figure 7.14 - The Packages diagram of the Kernel package UML 2.3 UML 2.4 Resolved closed
UML24-60 Auxiliary UML 2.3 UML 2.4 Resolved closed
UML24-58 UML 2.3, Figure 18.1 UML 2.3 UML 2.4 Resolved closed
UML24-56 UML2 Issue: OCL in resolution 11114 is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-57 Term "method activation" deprecated? UML 2.3 UML 2.4 Resolved closed
UML24-55 Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied. UML 2.3 UML 2.4 Resolved closed
UML24-54 UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine UML 2.3 UML 2.4 Resolved closed
UML24-53 Resolution to issue 14063 UML 2.3 UML 2.4 Resolved closed
UML24-52 UML 2 issue - misleadingly named associations UML 2.3 UML 2.4 Resolved closed
UML24-51 Meaning of BodyCondition and its alignment with OCL UML 2.3 UML 2.4 Resolved closed
UML24-50 composite tags UML 2.3 UML 2.4 Resolved closed
UML24-49 UML2 - Invalid constraint for Actor UML 2.3 UML 2.4 Resolved closed
UML24-47 MessageEvents UML 2.3 UML 2.4 Resolved closed
UML24-48 Detailed modeling of the Standard Profiles UML 2.3 UML 2.4 Resolved closed
UML24-43 Activity vs Action completion UML 2.3 UML 2.4 Resolved closed
UML24-41 Figure 7.15 UML 2.3 UML 2.4 Resolved closed
UML24-45 UML2.3 definition of Classifier::hasVisibilityOf is circular UML 2.3 UML 2.4 Resolved closed
UML24-46 Association owned derived union UML 2.3 UML 2.4 Resolved closed
UML24-38 serialization of a profile should always include the nsURI and nsPrefix tags UML 2.3 UML 2.4 Resolved closed
UML24-44 UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI UML 2.3 UML 2.4 Resolved closed
UML24-42 Enumeration Literal UML 2.3 UML 2.4 Resolved closed
UML24-37 Incomplete resolution to 10826 UML 2.3 UML 2.4 Resolved closed
UML24-39 Poor example of Dependency notation UML 2.3 UML 2.4 Resolved closed
UML24-40 Lack of graphical example of multi-element Dependency Notation UML 2.3 UML 2.4 Resolved closed
UML24-36 Subsetting clauses should show the subsetted property fully qualified. UML 2.3 UML 2.4 Resolved closed
UML24-29 loopVariable ownership UML 2.3 UML 2.4 Resolved closed
UML24-31 Definition of Behavior::context is not correct UML 2.3 UML 2.4 Resolved closed
UML24-30 Context of a behavior owned as a nested classifier UML 2.3 UML 2.4 Resolved closed
UML24-34 UML 2: property redefinitions should be symmetric across associations UML 2.3 UML 2.4 Resolved closed
UML24-35 The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting UML 2.3 UML 2.4 Resolved closed
UML24-32 Matching subsettting across association ends UML 2.3 UML 2.4 Resolved closed
UML24-33 Expansion nodes using all the tokens in them as a single collection FUML 1.0b2 UML 2.4 Resolved closed
UML24-5 Parameter type of MultiplicityElement::includesMultiplicity() UML 2.3 UML 2.4 Resolved closed
UML24-1 typo in new attribute name UML 2.3 UML 2.4 Resolved closed
UML24-2 CMOF missing several redefined property relationships UML 2.3 UML 2.4 Resolved closed
UML24-4 Constraint [3] on TestIdentityAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-3 Constraint [1] for WriteStructuralFeatureAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-6 UML2 - non-unique association names in L3.merged.cmof UML 2.3 UML 2.4 Resolved closed
UML24-11 Some owned operations with OCL expression bodies but without their "isQuery" set to "true" UML 2.3 UML 2.4 Resolved closed
UML24-8 UML2 - definition of Property.opposite is wrong UML 2.3 UML 2.4 Resolved closed
UML24-7 UML2 - derivation for DeploymentTarget.deployedElement is invalid UML 2.3 UML 2.4 Resolved closed
UML24-27 UML is vague about which Element should own Comments UML 2.3 UML 2.4 Resolved closed
UML24-28 Unclear constraint on stereotype associations UML 2.3 UML 2.4 Resolved closed
UML24-25 lowered multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-26 remove BehavioredClassifier::ownedTrigger UML 2.3 UML 2.4 Resolved closed
UML24-24 is composite and subsets not derived composite property: UML 2.3 UML 2.4 Resolved closed
UML24-22 wrong Actor's constraint [1]" UML 2.3 UML 2.4 Resolved closed
UML24-23 is composite, but does not subset ownedElement UML 2.3 UML 2.4 Resolved closed
UML24-21 Issue on generalization UML 2.3 UML 2.4 Resolved closed
UML24-20 AcceptEventAction notation UML 2.3 UML 2.4 Resolved closed
UML24-19 Some associations in the normative XMI has one memberEnd UML 2.3 UML 2.4 Resolved closed
UML24-17 Cycles in package imports UML 2.3 UML 2.4 Resolved closed
UML24-18 Namespace collission due to package import UML 2.3 UML 2.4 Resolved closed
UML24-14 Attributes without a type UML 2.3 UML 2.4 Resolved closed
UML24-16 Errors with types of association ends not conforming to their subsetted ends UML 2.3 UML 2.4 Resolved closed
UML24-15 Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform UML 2.3 UML 2.4 Resolved closed
UML24-12 All enumertion literals in the model have their "classifier" collections empty UML 2.3 UML 2.4 Resolved closed
UML24-9 UML2: Incomplete definition for Activity.structuredNode UML 2.3 UML 2.4 Resolved closed
UML24-13 Associations with same name that live in different packages violate unique name constraint UML 2.3 UML 2.4 Resolved closed
UML24-10 UML 2 Events referred to by OccurrenceSpecifications should be optional UML 2.3 UML 2.4 Resolved closed

Issues Descriptions

navigation only possible to generalization but not to specializations of elements

  • Key: UML24-152
  • Legacy Issue Number: 15766
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    I am using the UML specification very often and I am navigating a lot through specific elements. One thing which bothers me most is that I can only hop to the generalization of elements but not to their specializations. For example for activity diagrams, if I go to Section 12.3.16 CentralBufferNode (p. 360) I know that it is a sub-type of an ObjectNode. But now I have no chance to see which sub-types of a CentralBufferNode exists (e.g. a DataStoreNode). So I have to navigate back to p. 312 to see the dependencies of a CentralBufferNode.

    In my point of view would displaying not only generalizations but also specializations of elements directly at an element's description be a great advantage to the readability of the specification.

    It would certainly be a great surplus to me, maybe others have thought the same way, too.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Closed; No Change — UML 2.4
  • Disposition Summary:

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

  • Updated: Sun, 8 Mar 2015 15:04 GMT

Statement mistake

  • Key: UML24-127
  • Legacy Issue Number: 15898
  • Status: closed  
  • Source: CGI ( Wayne Li)
  • Summary:

    On page 613, the section of "Semantic", the first sentence of "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." , the "including" should be "included"

  • Reported: UML 2.3 — Mon, 13 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Constraint is Wrong

  • Key: UML24-126
  • Legacy Issue Number: 15881
  • Status: closed  
  • Source: motorola ( bruce lu)
  • Summary:

    In the first item of the 'Constraints' clause,
    (self.name->isEmpty() or self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

    should be
    self.name->isEmpty() or (self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

  • Reported: UML 2.3 — Wed, 8 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity

  • Key: UML24-130
  • Legacy Issue Number: 16595
  • Status: closed  
  • Source: gmail.com ( Joost Doesburg)
  • Summary:

    In the description of a MultiplicityElement in the superstructure, constraint 1 claims that
    'upperBound()->notEmpty() implies upperBound() > 0', while in the last paragraph of the semantics, it is declared that a multiplicity of [0..0] is possible.
    These statements are in conflict with each other.

  • Reported: UML 2.3 — Thu, 13 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 7.31 propose an “association-like” notation for attributes

  • Key: UML24-128
  • Legacy Issue Number: 15899
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Figure 7.31 propose an “association-like” notation for attributes:

    • clarifying whether aggregation kind can be shown
    • the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired.
  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15237

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

Section numbering

  • Key: UML24-129
  • Legacy Issue Number: 16043
  • Status: closed  
  • Source: web.de ( Kay Weihmann)
  • Summary:

    In my opinion section 9.2 should be numbered as section 9.1.2. That would match to the rest of the numbering scheme.

  • Reported: UML 2.3 — Thu, 24 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML 2.4: “Figure 7.31 shows the dot at the wrong end.”

  • Key: UML24-124
  • Legacy Issue Number: 15873
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML 2.4: “Figure 7.31 shows the dot at the wrong end.” From: Pete Rivett pete.rivett@adaptive.com
    Sent: 14 December 2010 17:50
    To: Steve Cook
    Cc: Maged Elaasar; andrew@omg.org
    Subject: RE: New notation for attribute

    No it did not come from me: I think it was Jim or Bran or Ed (see attached).

    However attached is an updated figure I drew from scratch.

    Pete

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Tuesday, December 14, 2010 4:44 AM
    To: Pete Rivett
    Cc: Maged Elaasar; Andrew Watson (andrew@omg.org)
    Subject: RE: New notation for attribute

    Pete – I believe you made that figure. Is it possible to supply a correct one?

    From: Pete Rivett pete.rivett@adaptive.com
    Sent: 13 December 2010 20:10
    To: Ed Seidewitz; Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure.

    In terms of the concepts, it seems that navigability is the thing we should lose – specifically for metamodeling.

    What does it mean to say that it’s not possible (‘efficiently’) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information?

    That’s not to say navigability has no value for other types of model. I don’t feel qualified to comment. Clearly some people like it.

    However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) – since it’s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability.

    This will make no difference at all to the XMI for model interchange – since it’s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5.

    Pete

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: Monday, December 13, 2010 10:21 AM
    To: Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Steve –

    I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the “dot on the wrong end” is the right way to show an attribute using “association-like notation”, which will just cause even more confusion!

    As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don’t think it has), I don’t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved!

    – Ed

    --------------------------------------------------------------------------------

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Monday, December 13, 2010 1:09 PM
    To: Ed Seidewitz; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I’ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML.

    The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example.

    I don’t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5.

    – Steve

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: 13 December 2010 17:55
    To: Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Bran –

    You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 “to show dot-notation”. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??).

    In any case, I think the intention was that this notation alternative look exactly like association notation – that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue.

    – Ed

    --------------------------------------------------------------------------------

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:42 PM
    To: Ed Seidewitz
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot – which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) – which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention).

    Ugh! Overloading notations is a bad idea.

    Cheers...Bran

    On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz <ed-s@modeldriven.com> wrote:

    Bran –

    I don’t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association.

    – Ed

    --------------------------------------------------------------------------------

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:14 PM
    To: Steve Cook
    Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org

    Subject: Re: New notation for attribute

    Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong?

    In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion – such as the case above (regardless of whether I am right or wrong above).

    Cheers...Bran

    On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook <Steve.Cook@microsoft.com> wrote:

    I believe this option is already there: see figure 7.31.

    From: Rouquette, Nicolas F (316A) nicolas.f.rouquette@jpl.nasa.gov
    Sent: 11 December 2010 11:59
    To: BERNARD, Yves
    Cc: uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    Yves,

    This idea makes sense as part of the Diagram Definition for UML.

    • Nicolas.

    On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote:

    According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:

    Capability to get a modular diagram thanks to the “link notation”
    Capability to show the aggregation kind

    However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

    What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Replace the offending diagrams.

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

Wrong Classifier Name

  • Key: UML24-125
  • Legacy Issue Number: 15880
  • Status: closed  
  • Source: NSN ( bruce lu)
  • Summary:

    In the 'Associations' clause of section 9.10.3, the last association 'value : InstanceSpecification [*]' is wrong. It should be 'value : ValueSpecification [*]

  • Reported: UML 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified

  • Key: UML24-123
  • Legacy Issue Number: 15870
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 2.3, UML 2.4 Superstructure spec, "14.3.17 Lifeline" section, coveredBy is
    marked with [0..1] multiplicity. In the corresponding figure in the
    beginning of the Interactions chapter it is marked *.

    coveredBy : InteractionFragment [0..1]

  • Reported: UML 2.3 — Fri, 3 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Property.isReadOnly is redundant with StructuralFeature.isReadOnly

  • Key: UML24-118
  • Legacy Issue Number: 15781
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    According to figure 7.12, Property.isReadOnly redefines StructuralFeature.isReadOnly. But the redefinition is not mentioned in 7.3.45.

    Both of these properties have the same name, type, multiplicity and default, so Property.isReadOnly is unnecessary.

    The resolution will be to delete Property.isReadOnly from metamodel, text and diagram.

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    We decided to delete Property::isReadOnly and move the words used to specify it to StructuralFeature::isReadOnly.
    This will not affect interoperability.
    This also resolves 7857.

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

Deep history for orthogonal states

  • Key: UML24-120
  • Legacy Issue Number: 15791
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    "A region may have at most one deep history vertex." (pg 564)
    "A composite state may have at most one deep history vertex." (pg 557)

    This implies that only one region of a composite state may have a deep history vertex. There is no formal constraint to the effect. Please clarify.

    "deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate" (pg 557)
    This implies that all regions of a orthogonal composite state are returned to the the most recent active configuration of the composite state but...at the bottom of page 570 it asserts the other regions are entered "by default" which has a different semantic. Please clarify.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The second quoted sentence is no longer there, but there is still some text that implies that history vertices
    are State based rather than Region based. These should be fixed.
    Fix all places where it is implied that history vertices belong to States rather than Regions.

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

Big UML 2.4 problem: missing defaults in XMI

  • Key: UML24-121
  • Legacy Issue Number: 15804
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This came up in the MIWG testing (though that was for UML 2.2)

    There seem to be several cases where the specification has defaults that are not represented in the XMI.

    Examples of this are as follows:

    ActivityEdge::guard : ValueSpecification [1..1] = true

    ActivityEdge::weight : ValueSpecification [1..1] = 1

    ObjectNode::upperBound : ValueSpecification [1..1] = *

    They all seem to be ValueSpecifications so I’m sure there are others.

    BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Parameter semantics related to Behavior and BehavioralFeature

  • Key: UML24-119
  • Legacy Issue Number: 15787
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors.

    ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says “See semantics of ParameterSet”. But all 12.3.43 says is “A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.” 12.3.13 also says “See notation for ParameterSet” – that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that’s the topic of a separate discussion).

    ParameterEffectKind, as well, talks exclusively about Behaviors.

    So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors.

    Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel.

    There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others.

    The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature.

    One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18.

    Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter?

  • Reported: UML 2.3 — Wed, 27 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 it has been made clear that there is only one metaclass Parameter and its semantics are now defined in one
    place.
    Disposition: Closed - No Change

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

Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions

  • Key: UML24-122
  • Legacy Issue Number: 15822
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    UML 2.3 RTF resolved ISSUE 14277 as follows:

    Japan Superstructure PAS Ballot Comments - comment 20
    Summary:
    Part I, II, III,, IV This is a multipart standard, use of "Part I,
    II, III, IV" make confusion. Delete unnecessary Part IV and Make others
    rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and
    renumber other clauses.
    Resolution:
    Agree to change word “Part” to “Sub Part” throughout document.

    PTC/9-9-10 , the UML 2.3 Infrastructure convenience document has the changes of the
    tem “Part” to “Subpart”, as per the resolution to ISSUE 14277 by the UML 2.3 RTF.

    However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

    Also, ISO document templates do not allow hanging text.

    The introductory text for each is not in any numbered clause.

    Proposed Resolution:

    Change term “Part” to “Subpart”, as in PTC/9-9-10.

    Change title of section 6.2 to be “How to Read this Specificaton” as in PTC/9-9-10, and
    to be consistent with Superstructure.

    Add a new section

    6.2.2 Contents of Subparts

    6.2.2.1 Contents of Subpart I ­ Introduction

    <move the hanging intro from Part I into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.2 Contents of Subpart II ­ Infrastructure Library

    <move the hanging intro from Part II into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.3 Contents of Subpart III - Annexes

    <move the hanging intro from Part II into this subclause,>

  • Reported: UML 2.3 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Fix minor inconsistencies between infrastructure specification document & metamodel

  • Key: UML24-116
  • Legacy Issue Number: 15778
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Description: To ensure that the UML2.4 metamodel is consistent with the specification document, the following inconsistencies must be resolved:

    1) NamedElement::qualifiedName()

    InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement::qualifiedName()

    ? this corresponds to 9.14.1 constraint [2] – OK

    InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    ? no description of this in clause 11 for Core::Constructs – OK per current conventions that clause 11 does not duplicate the constraints/operations from the merged increments shown in 11.2

    For the superstructure:

    ? the description in super 7.3.34 constraint [2] is copied from 9.14.1 constraint [2] ? OK

    ? UML::Classes::Kernel::NamedElement::qualifiedName() is missing ? not OK per current conventionss that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    2) DataType::inherit()

    ? No description anywhere of InfrastructureLibrary::Core::Constructs::DataType::inherit() in infra 11.6.1 or super 7.3.11

    ? UML::Classes::Kernel::DataType::inherit() is missing ? not OKK per current conventions that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    1.a) figure 11.2 is only in the document, the package merge relationships are not in the infrastructure at all.

    ? add the relationships as described in infra 11.2

    ? add a package merge relationship from Core::Constructs to Core::Abstractions::Element, which other merge increments in Core::Abstractions import.

    2) DataType::inherit()

    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()

    In Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section:

    Additional Operations

    [1] The inherit operation is overridden to exclude redefined properties.

    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);

    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue summary is a bit garbled, but here is a summary of what it proposes, in order to make the metamodel and specification document consistent.
    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()
    In the metamodel change infrastructure figure 11.2 so that Constructs does not merge Basic, and instead Constructs does merge Core::Abstractions::Elements. The merge to Basic is conceptually flawed because Basic has a different and conflicting definition and semantics for Operation.
    Note that these merges remain purely conceptual – they are not explicit in the metamodel.
    In the metamodel, delete the association Core::Abstractions::BehavioralFeatures::A_parameter::behavioralFeature, because if this association was actually merged according to figure 11.2 it would be an orphaned derived union, with no subsets in the metamodel.
    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()
    In Infrastructure 11.6.1 and Superstructure 7.3.11, add the following section:
    Additional Operations
    [1] The inherit operation is overridden to exclude redefined properties.
    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);
    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

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

Be explicit that type does not need to be set for LiteralBoolean etc.

  • Key: UML24-117
  • Legacy Issue Number: 15779
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Today we are inconsistent in the metamodel about whether the type of a LiteralBoolean value is set or not. Some are; most are not, and there is no guidance in the spec about which is correct. Since the type is completely obvious, we can be explicit about this:

    LiteralBoolean

    Constraints:

    [1] Since the type of a LiteralBoolean is by definition a Boolean, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralInteger

    Constraints:

    [1] Since the type of a LiteralInteger is by definition an Integer, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralReal

    Constraints:

    [1] Since the type of a LiteralReal is by definition a Real, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralString

    Constraints:

    [1] Since the type of a LiteralString is by definition a String, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralUnlimitedNatural

    Constraints:

    [1] Since the type of a LiteralUnlimitedNatural is by definition an UnlimitedNatural, it would be redundant to specify the type explicitly.

    type->isEmpty()

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After discussion the RTF resolved that making changes of this kind to the spec is too controversial. Instead, we simply go through the metamodel making sure that all instances of subtypes of LiteralSpecification have their type set to null, in order to make the metamodel consistent.

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

Wrong constraint on Operation::bodyCondition

  • Key: UML24-113
  • Legacy Issue Number: 15768
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The spec says:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    couple this with:

    The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that
    the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during
    redefinition.

    Also, in the current MM, the defined operations logic is implemented as a body Condition.

    Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation

    Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it.

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15501

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

Operation with multiple return parameter

  • Key: UML24-114
  • Legacy Issue Number: 15769
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    We are talking about an operation declared in the UML metamodel, so

    Operation::returnResult() : Parameter [0..1]

    is definitely valid UML notation.

    while

    Operation::returnResult() : Set(Parameter)

    which is the way it is now in spec is definitely not valid UML notation, it is supposed to be:

    Operation::returnResult() : Parameter [*]

    In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it.

    Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type.

    However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result.

    OperationHasSingularReturnResult : 16
    operation = <Operation> UML::Vertex::containingStateMachine () : StateMachine
    operation = <Operation> UML::Transition::redefinitionContext () : Classifier
    operation = <Operation> UML::Transition::containingStateMachine () : StateMachine
    operation = <Operation> UML::Stereotype::profile () : Profile
    operation = <Operation> UML::Stereotype::containingProfile () : Profile
    operation = <Operation> UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace
    operation = <Operation> UML::State::redefinitionContext () : Classifier
    operation = <Operation> UML::State::containingStateMachine () : StateMachine
    operation = <Operation> UML::Region::redefinitionContext () : Classifier
    operation = <Operation> UML::Region::containingStateMachine () : StateMachine
    operation = <Operation> UML::Property::opposite () : Property
    operation = <Operation> UML::Package::containingProfile () : Profile [0..1]
    operation = <Operation> UML::Operation::type () : Type
    operation = <Operation> UML::LinkAction::association () : Association
    operation = <Operation> UML::Extension::metaclassEnd () : Property
    operation = <Operation> UML::Extension::metaclass () : Class

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue is obsolete. The generated Operation descriptions are now correct.
    Disposition: Closed - No Change

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

Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)?

  • Key: UML24-115
  • Legacy Issue Number: 15774
  • Status: closed  
  • Source: TU Darmstadt ( Martin Wieber)
  • Summary:

    Compare "Figure 9.37 - The Namespaces package" on page 71 of same document.

  • Reported: UML 2.3 — Fri, 22 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Problem with ExtensionEnd::lower

  • Key: UML24-111
  • Legacy Issue Number: 15762
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0. The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent. The same is true in 2.3.

    This seems to be a significant issue with regard to profile interchange, so I’d like to fix it in 2.4. Juergen, could we have an issue number please?

    Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

    MultiplicityElement::/lower is marked as derived. It does not have a default value. Instead, there is a derivation constraint:

    lower = lowerBound(); and operation

    lowerBound() = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0. What is this supposed to mean? If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived. But it does not. So there is no well-defined derivation.

    If we regarded the derivation in MultiplicityElement to be somehow “inherited” across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower.

    I think to fix this what we ought to do is the following. Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

    lower = lowerBound(); and

    lowerBound() = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

    This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal.

    <packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

    <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

    </ownedEnd>

    </packagedElement>

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources:

    • the fact that it is derived is from AuxiliaryConstructs::Profiles
    • the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement
    • the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound().
      However, the [0..1] multiplicity of lower() – the operation which gives the derivation for ExtensionEnd::/lower in the metamodel – conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement – it represents a “widening” of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML state machines: inconsistent subset of StateMachine::extendedStatemachine

  • Key: UML24-108
  • Legacy Issue Number: 15669
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    Issue 15265 proclaimed that StateMachine::extendedStatemachine should subset Classifier::redefinedClassifier. However, while the text entry for this field does this, the diagram in Figure 15.3 subsets Behavior::redefinedBehavior instead. It seems that the fix was not applied properly. Note that Behavior::redefinedBehavior is not a derived union property, so Figure 15.3 is just plain wrong – although it could be argued that the proper fix is to make it a derived union and have StateMachine::extendedStatemachine redefine Behavior::redefinedBehavior

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Figure 15.3 (referring to the version of 2.4 published in September 2010) is not wrong – it is valid for a property to subset a non-derived one. However the semantic question here is what exactly extendedStateMachine is supposed to mean that cannot be accomplished by using redefinedBehavior.
    It is wrong, however, in the sense that resolution 15265 was not correctly or consistently applied.
    At this point we need at least to make the resolution consistent.
    I propose to do this by making extendedStateMachine redefine behavior::redefinedBehavior, having the effect that only a state machine may redefine a state machine.

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

UML 2.4 - ConditionalNode - Semantics

  • Key: UML24-110
  • Legacy Issue Number: 15711
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The last paragraph of the semantics section of 12.3.18 ConditionalNode, states

    Within the body section, variables defined in the loop node or in some higher-level enclosing node may be accessed and updated with new values. Values that are used in a data flow manner must be created or updated in all clauses of the conditional; otherwise, undefined values would be accessed.

    I assume that the reference to ‘loop node’ is incorrect.

  • Reported: UML 2.3 — Sat, 9 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The quoted text is no longer used in the UML 2.5 beta specification.
    Disposition: Closed - No Change

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

stereotype <> for defining parameterized classes is nowhere defined

  • Key: UML24-112
  • Legacy Issue Number: 15765
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    Usage of <<bind>> to define parameterized classes in object diagrams is nowhere defined in the UML specification. Not as a keyword in Annex B (p. 707) and also not as a standard stereotype (Annex C, p. 713).

    I just wondered what the actual definition of <<bind>> may be. Maybe it would be good to define it somewhere.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

DecisionNode at all guards evaluated to false

  • Key: UML24-109
  • Legacy Issue Number: 15708
  • Status: closed  
  • Source: gmx.net ( Stephan Grund)
  • Summary:

    DecisionNode's behaviour when a token cannot pass any edge at the moment it arrives and the guards are evaluated is not specified.
    When will the guards be evaluated next time?

  • Reported: UML 2.3 — Thu, 7 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered in the UML 2.5 beta specification in Subclause 15.3.3 under “Decision Nodes”. The specification
    states: “If any of the outgoing edges of a DecisionNode have guards, then these are evaluated for each incoming
    token.” and “A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge
    for which the guard evaluates to false.” So, if no guards evaluate to true, the token will not traverse any of the outgoing
    edges. The next time the guards are evaluated is when the next token is offered to the DecisionNode.
    Disposition: Closed - No Change

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

isDerived with DefaultValue

  • Key: UML24-107
  • Legacy Issue Number: 15668
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values.

    Here is a list of such derived properties in the metamodel:

    PropertyIsDerivedWithDefaultValue : 13
    property = <Property> UML::State::/ isSubmachineState : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isSimple : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::State::/ isOrthogonal : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isComposite : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::Operation::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural> 1
    property = <Property> UML::Operation::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Operation::/ isUnique : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::Operation::/ isOrdered : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural > 1
    property = <Property> UML::MultiplicityElement::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Message::/ messageKind : MessageKind
    defaultValue = <Instance Value> unknown
    property = <Property> UML::ExtensionEnd::/ lower : Integer [0..1]
    defaultValue = <Literal Integer > 0
    property = <Property> UML::Extension::/ isRequired : Boolean
    defaultValue = <Literal Boolean> false

    do we need to fix them?

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The FTF agrees that these default values are meaningless, and in many cases confusing. Remove them

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

EnumerationHasOperations : UML::VisibilityKind::bestVisibility

  • Key: UML24-101
  • Legacy Issue Number: 15572
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    This is disallowed by MOF. [8] Enumerations may not have attributes or operations. This operation is not used – remove it.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed: the operation is defined in both Infrastructure 9.21.2 (and index) and Superstructure 7.3.56 but is not used anywhere.

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

Give all constraints unique names within their context.

  • Key: UML24-103
  • Legacy Issue Number: 15574
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Several constraints have no names. A couple of constraints have different names in different merge increments, but are the same constraint:

    UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,

    UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the constraints with no names.
    UML::Transition::isConsistentWith::
    UML::RedefinableTemplateSignature::isConsistentWith::
    UML::RedefinableElement::isConsistentWith::
    UML::Property::isConsistentWith::
    UML::Package::makesVisible::
    UML::Operation::isConsistentWith::
    UML::OpaqueExpression::value::
    UML::OpaqueExpression::isPositive::
    UML::OpaqueExpression::isNonNegative::
    UML::MultiplicityElement::isMultivalued::
    UML::MultiplicityElement::includesMultiplicity::
    UML::MultiplicityElement::includesCardinality::
    UML::Classifier::inheritableMembers::
    UML::Classifier::hasVisibilityOf::
    These are all preconditions of operations. All of the bodies are named “spec” so I propose that all of the preconditions are named “pre”. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition.

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

InstanceValue has no type

  • Key: UML24-99
  • Legacy Issue Number: 15570
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There are many cases where the default value of a property is represented by an InstanceValue, which is a TypedElement, but has no type. These types should be inserted.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In fact there are four cases where this is true for an InstanceValue that refers to an EnumerationLiteral. Other cases are instances of LiteralInteger, LiteralBoolean, etc and it seems completely redundant to mark the type of these as Integer, Boolean etc.
    UML::Classes::Kernel::Property::aggregation
    UML::Classes::Kernel::Parameter::direction
    UML::Activities::CompleteActivities::ObjectNode::ordering
    InfrastructureLibrary::Core::Constructs::Parameter::direction

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

UML 2.4 - Interaction

  • Key: UML24-105
  • Legacy Issue Number: 15622
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    In the semantics section of MessageEnd it says “Subclasses of MessageEnd define the specific semantics appropriate to the concept they represent.”

    However, in the semantics section of MessageOccurrenceSpecification, a subclass of MessageEnd, it says “No additional semantics”

    So it’s not clear what the semantics of MessageOccurrenceSpecification are.

  • Reported: UML 2.3 — Tue, 21 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Parameter have Effects

  • Key: UML24-100
  • Legacy Issue Number: 15571
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    These are attributes in the metamodel, but are not included in MOF 2.4, so should be removed.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the parameters that have effect set in the metamodel. Parameter::effect is defined with multiplicity [0..1], and in metamodels should be set to null.
    UML::Classifier::maySpecializeType::c
    UML::Classifier::inheritableMembers::c
    UML::Property::isAttribute:
    UML::Region::isRedefinitionContextValid::redefined
    UML::State::isRedefinitionContextValid::redefined
    UML::Component::usedInterfaces::classifier
    UML::Component::realizedInterfaces::classifier
    UML::StateMachine::isRedefinitionContextValid::redefined
    UML::RedefinableElement::isRedefinitionContextValid::redefined

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

Derived properties that are not marked read-only

  • Key: UML24-97
  • Legacy Issue Number: 15568
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only. There are 24 exceptions to this convention.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent.
    Vertex::outgoing
    Vertex::incoming
    Stereotype::profile (Infra fig 12.2, Super fig 18.2)
    Property::opposite (Super fig 7.12)
    Property::isComposite (Super fig 7.12)
    Property::default (Super fig 7.12)
    Parameter::default (Super fig 7.11)
    Package::ownedType (Infra fig 11.26, Super fig 7.14)
    Package::ownedStereotype (Infra fig 12.2, Super fig 18.2)
    Package::nestedPackage (Infra fig 11.26, Super fig 7.14)
    Operation::upper (Super fig 7.11)
    Operation::type (Super fig 7.11)
    Operation::lower (Super fig 7.11)
    Operation::isUnique (Super fig 7.11)
    Operation::isOrdered (Super fig 7.11)
    MultiplicityElement::upper
    MultiplicityElement::lower
    EnumerationLiteral::classifier (Super fig 7.13)
    EncapsulatedClassifier::ownedPort
    Connector::kind (Super fig 8.3)
    ConnectableElement::end (Super fig 8.3)
    Classifier::general
    Class::superClass (Super fig 7.12)
    ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense.
    Another reason not to make them all readonly is the following paragraph in Superstructure 2.3:
    ¡°Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.¡±
    This implies that properties writable at L0 should be writeable at L3.
    The properties affected by this are:
    Property::opposite
    Property::isComposite
    Property::default
    Parameter::default
    Package::ownedType
    Package::nestedPackage
    MultiplicityElement::upper
    MultiplicityElement::lower
    Classifier::general
    Class::superClass
    We are allowed by the notation not to show

    {readOnly} on the diagrams. We will show {readOnly}

    on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ¡°all or nothing¡± rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.

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

Multiplicity Element Is MultiValued With Default Value

  • Key: UML24-98
  • Legacy Issue Number: 15569
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    This applies to DurationObservation::firstEvent[0..2] default = true, and DurationConstraint::firstEvent[0..2], defaultValue = true. This conflicts with CMOF constraint [9] Multivalued properties cannot have defaults, and is also meaningless because firstEvent size is constrained to be 0 or 2.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove the default as it violates a CMOF constraint

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

The metamodel contains instances of Model

  • Key: UML24-102
  • Legacy Issue Number: 15573
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    InfrastructureLibrary and UML are instances of Model, and MOF does not include Model.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Change Models to Packages

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

Property::isID should not be optional

  • Key: UML24-106
  • Legacy Issue Number: 15664
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Property::isID should not be optional”. The summary is “Property::isID should have multiplicity 1..1 and default value = false. There is no additional useful semantic provided by making it optional

  • Reported: UML 2.3 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

Change all properties typed by data types to aggregation=none

  • Key: UML24-104
  • Legacy Issue Number: 15575
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is no semantic for making a property with a data type composite, so remove these markings

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    UML::OpaqueAction::language
    UML::OpaqueAction::body
    UML::OpaqueBehavior::language
    UML::OpaqueBehavior::body
    UML::OpaqueExpression::language
    UML::OpaqueExpression::body

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

Redefinition of association-owned ends requires association generalization

  • Key: UML24-96
  • Legacy Issue Number: 15567
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There are 21 examples of association generalizations that need to be introduced in order to make association-owned end redefinition valid

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The redefinition context for an association-owned end is the association itself. Hence in order for redefinition of such ends to be well-formed, the associations must participate in appropriate generalizations.
    Here are the problematic redefinitions:
    redefiningElement = A_specification_timeConstraint::timeConstraint
    redefinitionContext = A_specification_timeConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_specification_intervalConstraint::intervalConstraint
    redefinitionContext = A_specification_intervalConstraint
    redefinedElement = A_specification_owningConstraint::owningConstraint
    redefinedContext = A_specification_owningConstraint
    redefiningElement = A_specification_durationConstraint::durationConstraint
    redefinitionContext = A_specification_durationConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_request_sendObjectAction::sendObjectAction
    redefinitionContext = A_request_sendObjectAction
    redefinedElement = A_argument_invocationAction::invocationAction
    redefinedContext = A_argument_invocationAction
    redefiningElement = A_representation_classifier::classifier redefinitionContext = A_representation_classifier
    redefinedElement = A_collaborationUse_classifier::classifier
    redefinedContext = A_collaborationUse_classifier
    redefiningElement = A_redefinitionContext_transition::transition
    redefinitionContext = A_redefinitionContext_transition
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_state::state
    redefinitionContext = A_redefinitionContext_state
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_region::region
    redefinitionContext = A_redefinitionContext_region
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_preCondition_protocolTransition::protocolTransition
    redefinitionContext = A_preCondition_protocolTransition
    redefinedElement = A_guard_transition::transition
    redefinedContext = A_guard_transition
    redefiningElement = A_ownedStereotype_owningPackage::owningPackage
    redefinitionContext = A_ownedStereotype_owningPackage
    redefinedElement = A_packagedElement_owningPackage::owningPackage
    redefinedContext = A_packagedElement_owningPackage
    redefiningElement = A_ownedDefault_templateParameter::templateParameter
    redefinitionContext = A_ownedDefault_templateParameter
    redefinedElement = A_default_templateParameter::templateParameter
    redefinedContext = A_default_templateParameter
    redefiningElement = A_ownedAttribute_structuredClassifier::structuredClassifier
    redefinitionContext = A_ownedAttribute_structuredClassifier
    redefinedElement = A_role_structuredClassifier::structuredClassifier
    redefinedContext = A_role_structuredClassifier
    redefiningElement = A_ownedActual_templateParameterSubstitution::templateParameterSubstitution
    redefinitionContext = A_ownedActual_templateParameterSubstitution
    redefinedElement = A_actual_templateParameterSubstitution::templateParameterSubstitution
    redefinedContext = A_actual_templateParameterSubstitution redefiningElement = A_min_timeInterval::timeInterval
    redefinitionContext = A_min_timeInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_min_durationInterval::durationInterval
    redefinitionContext = A_min_durationInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_max_timeInterval::timeInterval
    redefinitionContext = A_max_timeInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_max_durationInterval::durationInterval
    redefinitionContext = A_max_durationInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_endData_destroyLinkAction::destroyLinkAction
    redefinitionContext = A_endData_destroyLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_endData_createLinkAction::createLinkAction
    redefinitionContext = A_endData_createLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_classifier_enumerationLiteral::enumerationLiteral
    redefinitionContext = A_classifier_enumerationLiteral
    redefinedElement = A_classifier_instanceSpecification::instanceSpecification
    redefinedContext = A_classifier_instanceSpecification
    redefiningElement = A_classifierBehavior_behavioredClassifier::behavioredClassifier
    redefinitionContext = A_classifierBehavior_behavioredClassifier
    redefinedElement = A_ownedBehavior_behavioredClassifier::behavioredClassifier
    redefinedContext = A_ownedBehavior_behavioredClassifier

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

Fix association end multiplicities

  • Key: UML24-94
  • Legacy Issue Number: 15565
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    InfrastructureLibrary::Profiles::A_metamodelReference_profile::profile from [1] to [0..1]

    InfrastructureLibrary::Profiles::A_metaclassReference_profile::profile from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeInput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeOutput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The first change is needed because otherwise a PackageImport and an ElementImport must be owned by a profile, which is bad.
    The second change is needed because otherwise InputPins and OutputPins must be the inputs and outputs of StructuredActivityNode (fig 12.22), which is also bad.

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

Fix 14977 vs. 14638

  • Key: UML24-93
  • Legacy Issue Number: 15564
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is an inconsistency between 14977 and 14638 that results in inconsistent association end subsets due to incomplete copy-down from Kernel to InternalStructures.

    The resolution is to introduce 2 new generalizations

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The generalizations that need to be added are between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. This enables the ends of A_ownedConnector_structuredClassifier to subset all the things they need to, especially redefinitionContext/redefinableElement. This becomes obvious when you look at the draft figure 9.2. The root cause of this was an attempt to apply both 14638 and 14977 which led to the error.

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

Association-owned association end name changes

  • Key: UML24-92
  • Legacy Issue Number: 15563
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Kernel & Infrastructure:

    A_member_namespace => A_member_memberNamespace

    Change the association-owned association end from 'namespace' to 'memberNamespace'

    Interactions::BasicInteractions

    Change:

    A_sendEvent_message => A_sendEvent_endMessage

    A_receiveEvent_message => A_receiveEvent_endMessage

    + association-owned association end: 'message' => 'endMessage'

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The reason for the first change can be understood by looking at figure 7.4. This shows importedMember subsets member. The other end of this association, non-navigable and un-named on the diagram, is called namespace in the metamodel. This needs, by symmetry, to subset the other end of the association A_member_namespace. That cannot be called namespace, because of the constraint “A Property cannot be subset by a Property with the same name”. Hence we change its name to member_Namespace, and change the association name to follow the convention.
    The second change is for similar reasons. It is actually reflected in the current figure 14.4 but the association name has not been changed to match, and the change has not been introduced in any existing resolution.

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

Association conflicts with MemberEnds IsDerived flags

  • Key: UML24-95
  • Legacy Issue Number: 15566
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML::CompositeStructures::InternalStructures::A_feature_featuringClassifier

    UML::Activities::FundamentalActivities::A_subgroup_superGroup

    UML::Activities::FundamentalActivities::A_containedNode_inGroup

    UML::Activities::CompleteStructuredActivities::A_containedEdge_inGroup

    UML::Activities::StructuredActivities::A_containedNode_inGroup

    UML::Activities::CompleteActivities::A_containedNode_inGroup

    UML::Activities::IntermediateActivities::A_subgroup_superGroup

    UML::Activities::IntermediateActivities::A_containedEdge_inGroup

    UML::Activities::IntermediateActivities::A_containedNode_inGroup

    InfrastructureLibrary::Core::Abstractions::Constraints::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Classifiers::A_feature_featuringClassifier

    InfrastructureLibrary::Core::Abstractions::Namespaces::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Ownerships::A_ownedElement_owner

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These are associations with both ends derived. There is a MOF constraint: An Association is derived if all its Properties are derived. Hence all of these associations should be marked as derived. In addition, there is currently inconsistency elsewhere in the metamodel about which associations should be marked as derived. For example, A_redefinitionContext_region, with derived=false, and A_redefinitionContext_state, with derived=true. These are obviously inconsistent.
    In order to correct this we?ll apply the following additional constraint:
    ? An association in which all navigable (class-owned) ends are derived is derived
    The reasoning behind this is as follows.
    If you take the meaning of an association to be a set of links, and the meaning of an association end to be a set of instances of the type at the end of the association, then “derived” means that these sets can be calculated from other information. The other ingredient is whether the set can be altered “by hand”, as it were: and I am assuming that non-navigable ends cannot be altered by hand, i.e. they do not correspond to a settable API on a class. I don?t believe there is anything formal to substantiate this assumption, but it seems to be current practice for the metamodel to be constructed according to it. In this sense, all non-navigable ends are “derived”, whether you say so or not.
    The following are violations of this additional constraint:
    InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Abstractions::Constraints::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier
    InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Super::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_attribute_classifier
    InfrastructureLibrary::Core::Constructs::A_endType_association
    InfrastructureLibrary::Core::Constructs::A_importedMember_namespace
    InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_member_memberNamespace
    InfrastructureLibrary::Core::Constructs::A_opposite_property
    InfrastructureLibrary::Core::Constructs::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship
    InfrastructureLibrary::Core::Constructs::A_source_directedRelationship InfrastructureLibrary::Core::Constructs::A_target_directedRelationship
    InfrastructureLibrary::Core::Constructs::A_type_operation
    InfrastructureLibrary::Profiles::A_ownedStereotype_owningPackage
    InfrastructureLibrary::Profiles::A_profile_stereotype
    UML::Actions::BasicActions::A_input_action
    UML::Actions::BasicActions::A_output_action
    UML::Activities::CompleteStructuredActivities::A_input_action
    UML::Activities::CompleteStructuredActivities::A_output_action
    UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature
    UML::AuxiliaryConstructs::Templates::A_redefinitionContext_redefinableElement
    UML::Classes::Interfaces::A_attribute_classifier
    UML::Classes::Kernel::A_attribute_classifier
    UML::Classes::Kernel::A_classifier_enumerationLiteral
    UML::Classes::Kernel::A_endType_association
    UML::Classes::Kernel::A_general_classifier
    UML::Classes::Kernel::A_importedMember_namespace
    UML::Classes::Kernel::A_inheritedMember_classifier
    UML::Classes::Kernel::A_member_memberNamespace
    UML::Classes::Kernel::A_opposite_property
    UML::Classes::Kernel::A_parameter_behavioralFeature
    UML::Classes::Kernel::A_redefinedElement_redefinableElement
    UML::Classes::Kernel::A_redefinitionContext_redefinableElement
    UML::Classes::Kernel::A_relatedElement_relationship
    UML::Classes::Kernel::A_source_directedRelationship
    UML::Classes::Kernel::A_superClass_class
    UML::Classes::Kernel::A_target_directedRelationship
    UML::Classes::Kernel::A_type_operation
    UML::CommonBehaviors::BasicBehaviors::A_context_behavior
    UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression
    UML::Components::BasicComponents::A_provided_component
    UML::Components::BasicComponents::A_required_component
    UML::CompositeStructures::InternalStructures::A_attribute_classifier
    UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd
    UML::CompositeStructures::InternalStructures::A_part_structuredClassifier
    UML::CompositeStructures::InternalStructures::A_role_structuredClassifier
    UML::CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier
    UML::CompositeStructures::Ports::A_provided_port
    UML::CompositeStructures::Ports::A_required_port
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_transition
    UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition

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

UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format

  • Key: UML24-88
  • Legacy Issue Number: 15530
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove all of the cmof files from the published set of artifacts for UML 2.4. Instead, publish the following normative artifacts in MOF2.4/XMI2.4 format:
    Infrastructure.xmi
    Superstructure.xmi
    L0.xmi
    L1.xmi
    L2.xmi
    L3.xmi
    LM.xmi
    PrimitiveTypes.xmi
    UML.xmi (the merged L3 model)
    StandardProfileL2.xmi
    StandardProfileL3.xmi
    Also publish the following non-normative artifacts in MOF2.4/XMI2.4 format:
    L0.merged.xmi
    LM.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    Change all references to MOF 2 and XMI 2 in the specification text accordingly.

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

DestructionOccurenceSpecification text in Semantics still refers to events

  • Key: UML24-91
  • Legacy Issue Number: 15562
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    DestructionOccurenceSpecification text in Semantics still refers to events:
    "A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. "

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It should not refer to events.

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

The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake

  • Key: UML24-87
  • Legacy Issue Number: 15529
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake. It specified deleting the import from InfrastructureLibrary::Core::Abstractions to PrimitiveTypes. This is incorrect. Instead it should have specified retargeting the import from InfrastructureLibrary::Core::Abstractions to the new PrimitiveTypes package, to be consistent with the new figure 7.3.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

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

DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification

  • Key: UML24-90
  • Legacy Issue Number: 15561
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    That means, it can't be set as message end of delete message (message with "cross" sign at end). Critical bug I think

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following existing text describes the notation:
    The form of the line or arrowhead reflects properties of the message: …
    • Object deletion Message should end in a DestructionOccurrenceSpecification.
    This clearly implies that a DestructionOccurrenceSpecification must be a possible message end, so the issue is correct.

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

Message's signature is still derived property (in text only):

  • Key: UML24-89
  • Legacy Issue Number: 15560
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    /signature:NamedElement[0..1] The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is as a result of an incomplete application of resolution 14629, which was formulated slightly ambiguously.

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

Missing subsetting of redefinitionContext by Property::owningAssociation

  • Key: UML24-86
  • Legacy Issue Number: 15526
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure version 2.4 (ptc/2010-08-02)

    Subclause: 7.3.45 Property

    In Subclause 7.3.45, the description of Property::owningAssociation indicates that it subsets RedefinableElement::redefinitionContext. However, this is not shown in Figure 7.12. This subsetting relationship is necessary if an owned end of an association is to be able to redefine the ends of parent associations.

    Since this is a metamodel error, it should be fixed in UML 2.4.

  • Reported: UML 2.3 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

isConsistentWith

  • Key: UML24-83
  • Legacy Issue Number: 15500
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The operation RedefinableElement::isConsistentWith(redefinee : RedefinableElement) has the documentation:

    "The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is possible, whether redefinition would be logically consistent. By default, this is false"

    It is not clear from this description above whether the parameter "redefinee" is the redefining or the redefined element.

    A look at some of the overrides of this operation like Property::isConsistentwith(redefinee : RedefinableElement):

    " A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. "

    The description suggests that the "redefinee" is probably the "redefined" property.

    On the other hand, the precondition provided in OCL suggests that "refinee" is definitely the "redefining" property:

    pre: redefinee.isRedefinitionContextValid(self)

    since RedefinableElement::isRedefinitionContext(redefined : RedefinableElement) has the description:

    "...at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element."

    In summary, this means RedefinableElement has the two operations:

    RedefinableElement::isConsistentWith(redefining : RedefinableElement)
    RedefinableElement::isRedefinitionContext(redefined : RedefinableElement)

    At least "redefinee" should be renamed to "redfining" since this is the term used in the descriptions. However, having the two closely related operations taking opposite parameters make it very confusing and inconsistent.

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue has identified a serious problem of understanding with the operations that define what consistency
    between RedefinableElements means. Does A.isConsistentWith(B) get calculated when A is redefining, or
    when A is being redefined? The parameter name “redefinee” seems to imply that it gets calculated when A
    is redefining. But this turns out not to be the case. According to constraint redefinition_consistent, it is when A is being redefined. This also applies to the
    logic of Property::inConsistentWith and Operation::isConsistentWith (although see also 15499). For all
    other definitions of isConsistentWith the direction does not matter. So the logic consistently states that the
    parameter is the redefining element. Make this clear by renaming the parameter as redefiningElement.
    Now isRedefinitionContextValid is the other way around, as evidenced by the precondition for inConsistentWith:
    redefinee.isRedefinitionContextValid(self).
    Make this clearer by naming the parameter redefinedElement.
    It would perhaps be better to systematically reverse the sense of one of these operations, but that seems
    overly disruptive at this point. The constraint redefinition_context_valid is wrong. It omits the term “self”,
    rendering the constraint tautological. All of the constraints in RedefinableElement are too cryptic to be clear.

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

redefinitionContext of Property

  • Key: UML24-85
  • Legacy Issue Number: 15525
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Constraint [4] in Property implies an owned end can redefine any end of any ancestor of its owning association, whether that end is association owned or not.

    However in the case of an association-owned end redefining a (non-association) classifier-owned end, whose association is an ancesor (of the owning association), the redefinitionContexts are stil:

    the owningAssociation for the redefining proeprty
    the classifier for the redefined property

    Doesn't this violate constraint [1] of RedefinableElement

    [1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the redefinition contexts for each redefined element.
    self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))

    where

    RedefinableElement::isRedefinitionContextValid(redefined: RedefinableElement): Boolean;
    result = self.redefinitionContext->exists(c | c.allParents()->includes(redefined.redefinitionContext))

    since the classifier can never be an ancestor of the association?

  • Reported: UML 2.3 — Wed, 15 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There was an earlier discussion in the RTF that agreed that this constraint is inconsistent with the operation
    isRedefinitionContextValid, and proposed that the operation isRedefinitionContextValid should be redefined
    for Property, to give the correct logic, which is that a property may redefine another in the inheritance
    hierarchy regardless of whether the property is association-owned or class-owned. This is the same logic as
    for subsetting.

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

UML2.4: StandardProfileL2 & L3 are incomplete as delivered

  • Key: UML24-81
  • Legacy Issue Number: 15439
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    1) the deliverables below are not well formed; each of StandardProfileL2 and StandardProfileL3 below is missing a reference to the UML2.4 metamodel as a PackageImport element.

    Filename: StandardProfileL2.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L2 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-22
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi

    Filename: StandardProfileL3.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L3 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-23
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL3.xmi

    2) the inventory is missing the StandardProfileL2 & StandardProfileL3 as an instance of UML2.4 using XMI2.4.

    The artifacts on the UML2.xRTF SVN for StandardProfileL2/L3 as UML2.4/XMI2.4 have the same problem as the artifacts in (1).

  • Reported: UML 2.3 — Mon, 30 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

"isStatic" property of Feature no longer appears in any diagram

  • Key: UML24-79
  • Legacy Issue Number: 15429
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    I noticed that the "isStatic" property of Feature no longer appears in any diagram. There may be others missing meta-attributes, but this is the one I detected. I realize that the XMI is the definitive spec of the metamodel, but, nonetheless, I think that the diagrams should be complete and not partial. Diagrams are for human readers and XMI for machines (unless, of course, you are Pete Rivett – just kidding, Pete!).

    Also, I am disappointed that you retained the practically useless notion of navigability in the metamodel, even though we now have the dot notation supported in diagrams. Given the fact that navigability is a run-time concept, I see no value in keeping it in the metamodel, which is, after all, a static definition. (But, I am pretty sure I will now be deluged with people who will try to convince me that navigability arrows are still useful (my response: no, they are not).)

    Perhaps the "isStatic" problem can be fixed as an editorial fix prior to the meeting?

  • Reported: UML 2.3 — Wed, 25 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Show the isStatic property. In addition, this is a systematic error, and there are other cases where the metamodel has content that does not show on any diagram.

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

bodyCondition and isQuery

  • Key: UML24-84
  • Legacy Issue Number: 15501
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Constraint [7] in Kernel::Operation says:

    "A bodyCondition can only be specified for a query operation"

    Let us look at the definition of isQuery and bodyCondition:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation.

    isQuery : Boolean
    Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false).

    Question:

    I am not sure why specifying a condition on the result of an operation is only limited to operations with no side effects. What is wrong with specifying a condition on the result of a non-query operation?

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Body conditions are already a major source of logical uncertainty and inconsistency between OCL and UML. Relaxing
    their usage would only make this worse: the OCL spec states “An OCL expression may be used to indicate the result
    of a query operation”.
    This also resolves 15768.
    Disposition: Closed - No Change

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

coveredBy : InteractionFragment [0..1] should be [*]

  • Key: UML24-78
  • Legacy Issue Number: 15427
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    coveredBy holds a number of MessageOccurenceSpecifications and so on. It mustn't be [0..1] but be [*].

  • Reported: UML 2.3 — Tue, 24 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Operation::isConsistentWith

  • Key: UML24-82
  • Legacy Issue Number: 15499
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent

    "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result."

    However, the OCL provided does not check that the "direction" of parameters is consistent.

    Operation::isConsistentWith(redefinee: RedefinableElement): Boolean;

    pre: redefinee.isRedefinitionContextValid(self)

    result = redefinee.oclIsKindOf(Operation) and
    let op: Operation = redefinee.oclAsType(Operation) in
    self.ownedParameter->size() = op.ownedParameter->size() and
    Sequence

    {1..self.ownedParameter->size()}

    ->
    forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type))

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9.6.3 currently says “This redefinition may specialize the types of the owned Parameters. . . ” and,
    contradicting this, says “In UML, such rules for type conformance are intentionally not specified.”
    We do not mandate either covariance or contravariance for parameters in operation definition, explicitly
    allowing either. We will require parameter direction, uniqueness and ordering to be the same. We will
    require a multiplicity for which one of the following is true:
    • The same as the redefined parameter
    • For an in parameter, multiplicity including (wider than) that of the redefined parameter
    • For an out or return parameter, the redefined parameter’s multiplicity includes (is wider than) that of
    the redefining parameter.
    This also resolves Issues 17924 and 17612.

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

xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element

  • Key: UML24-80
  • Legacy Issue Number: 15438
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element. Was it intentional that the current UML format XMI files use MOF/2.4 and
    XMI/2.4 in their namespaces, even though these namespaces won't actually be correct? There is also an error in the structure of the .xmi files. A non xmi:XMI root element has been used that includes a cmof:Tag element, which is incorrect. The following files are affected:
    10-08-17.xmi
    10-08-18.xmi
    10-08-22.xmi
    10-08-23.xmi
    10-08-27.xmi
    10-08-28.xmi
    10-08-29.xmi
    L0.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    LM.merged.xmi

    Example:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </uml:Package> Should be:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    </uml:Package>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </xmi:XMI>

    I've also just noticed that the most recent package resolution added a property named "URI" rather than "uri", which is inconsistent with the old MOF property and is slightly unusual capitalisation for a property.
    However that's a minor point.

  • Reported: UML 2.3 — Thu, 26 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It was intentional to use the 2.4 namespaces, see 15530.
    Publish all of the xmi files that include cmof:Tag elements with a top-level XMI tag.
    Leave the property named URI as it is.
    Fix the profile XMI examples to conform to the normative specs.

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

The stereotype «Create» and keyword «create» are both defined in the UML 4 document

  • Key: UML24-77
  • Legacy Issue Number: 15419
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The stereotype «Create» and keyword «create» are both defined in the UML 4 document

    a. Figure 9.10 uses «create»

    b. Figure 9.27 uses «create»

    c. In appendix B, 2nd page, the «create» keyword is defined to apply to an operation that is a constructor, and to apply to a usage dependency, both uses of «create» appear in the Table B.1. This is consistent with items a and b above.

    d. In table C.1, both these uses are also defined as stereotypes, but with «Create». However, as stereotype matching is case insensitive, this is also consistent with items a and b above. So are the usages in a and b, keywords or stereotypes?

    e. In the last (and unlabeled) table in section C of obsolete elements, «create» is obsolete when applying to a CallEvent or Usage. How does this fit in?

    similar problems apply to several elements in table B.1 which are both stereotypes and keywords

  • Reported: UML 2.3 — Tue, 17 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency

  • Key: UML24-76
  • Legacy Issue Number: 15413
  • Status: closed  
  • Source: gmail.com ( Dmitry Semikin)
  • Summary:

    On the figure 9.2 "The Abstractions package contains several subpackages, all of which are specified in this clause" (shows all dependencies of Abstractions package subpackages)the Namespaces package do not depend on any others. But actually it depends on Ownerships package. Note: it is shown in right way in section "9.14 Namespaces Package".

    Side effect:
    Classifiers package depends (directly) on Namespaces package (which is shown in right way in chapter "9.4 Classifiers Package". And it depends on Ownerships package only indirectly (through Namespaces package). But on "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause" both dependencies are shown (which is not correct).

    To be fixed:
    on the "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause"
    1. Add dependency "Namespaces ---> Ownerships"
    2. Remove dependency "Classifiers ---> Ownerships"

  • Reported: UML 2.3 — Thu, 12 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Qualified name is incorrectly claimed to be unambiguous

  • Key: UML24-75
  • Legacy Issue Number: 15401
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of NamedElement claims that:

    A named element also has a qualified name that allows it to be
    unambiguously identified within a hierarchy of nested namespaces.

    However the validation rules for names within a namespace take, by default, the type into account and, for a behavioral feature, parameters. The qualified name uses only the name and thus isn't unambiguous as claimed.

  • Reported: UML 2.3 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15400

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

"unique" annotation

  • Key: UML24-74
  • Legacy Issue Number: 15399
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Since the "isUnique" and "isOrdered" properties have default values, do we need to have both 'unique'/'nonunique' and 'ordered'/'unordered' textual annotations? or do we only need ones for non-default values?

    I noticed that in some presentation option sections in the spec both annotation values are mentioned, while in other sections only one value is mentioned (diagrams in the spec also use them inconsistently):

    Superstructure:

    7.3.3 Association has 'nonunique' and 'ordered <= This seems to be the most correct
    7.3.32 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    7.3.36 Operation has 'unique' and 'ordered'
    7.3.44 Property have 'unique'/ 'nonunique' and 'ordered'

    Infrastructure:

    9.12.1 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    11.8.2 Operation has 'unique' and 'ordered'
    11.3.5 Property have 'unique' and 'ordered'

    What made me notice that is the addition of 'id' by resolution 15369, do we need to log an issue to fix this later?

  • Reported: UML 2.3 — Thu, 5 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The inconsistency is still there as specified in the issue. The general notation is defined in MultiplicityElement.
    It does have to be repeated for Property because the syntax allows the insertion of ‘=’ <default>
    between the multiplicity and prop-modifiers, and for Operation because the <oper-property> can be intermingled
    with others. The ‘sequence’ option is present for Property but inconsistently absent for Operation.
    The <parm-property> term is currently undefined and needs to have the same options.

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

Ambiguous constraints for transitions

  • Key: UML24-73
  • Legacy Issue Number: 15394
  • Status: closed  
  • Source: Safran Engineering Services ( Samuel Rochet)
  • Summary:

    Current UML specification use the two following constraints:

    15.3.8 Pseudostate (from BehaviorStateMachines)
    Constraint [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard
    (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty())

    15.3.14 Transition (from BehaviorStateMachines)
    Constraint [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate)
    (source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty()

    These constraints are not really contradictory but it is not clear to know if an initial pseudostate can or cannot have a trigger.

  • Reported: UML 2.3 — Tue, 3 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 these constraints have been removed. In fact, there is now a constraint “initial_transition” that makes it
    explicit that an initial pseudostate cannot have a trigger.
    Disposition: Closed - No Change

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

UML 2.4: Inconsistent rendering of OCL in UML metamodel

  • Key: UML24-71
  • Legacy Issue Number: 15378
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    This is a UML 2.4 issue please:

    Inconsistent rendering of OCL in UML metamodel.

    According to the conventions mostly applied in the UML metamodel, the specifications of the body conditions of operations have the form “result = <OCL expression>” and the operation is specified to have a return parameter named “result”. Invariants, pre- and post-conditions, on the other hand, are simply Boolean expressions with no “result = “. Note that many invariants are specified in OCL as “true”, being placeholders for invariants that are currently only specified in text. There are some placeholder operations, for which the specification should be “result = <default value for the type of result>”, i.e. result = false, result = 0, or result = null.

    Applying these conventions consistently will greatly enable future generation of specification documents. This means making the following changes:

    All operations in the metamodel should be changed to have a return parameter named “result”.

    The following operation and constraint specifications should be changed as indicated by changeto:

    InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    UML::Classes::Kernel::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::OpaqueExpression::value()

    “true” changeto “result = 0”

    UML::Classes::Kernel::VisibilityKind::bestVisibility()

    “pre: not vis->includes(#protected) and not vis->includes(#package)” changeto “not vis->includes(#protected) and not vis->includes(#package)”

    UML::Deployments::ComponentDeployments::DeploymentSpecification

    “result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))” changeto “self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))”

    UML::Deployments::Nodes::CommunicationPath

    “result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))” changeto “self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))”

    UML::Interactions::Fragments::InteractionUse

    Two placeholder invariants specified as “N/A” –changeto- “true”

    UML::StateMachines::BehaviorStateMachines::StateMachine::LCA()

    “true” – changeto- “result = null”

  • Reported: UML 2.3 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the changes proposed in the summary, except for OpaqueExpression::value() and StateMachine::LCA(). For these operations the result is undefined so it is incorrect to return a defined result. Instead a body of true is actually correct: it is logically equivalent to result=result.

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

UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype

  • Key: UML24-69
  • Legacy Issue Number: 15371
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The description for the stereotype in Annex C contains significant semantics which are not reflected anywhere else in the specification, nor as Constraints associated with the stereotype. Because this is a stereotype, not a keyword, these are not warranted.

    The full text is as follows:

    A package that contains model elements that are intended to be reused by other packages. Model libraries are frequently used in conjunction with applied profiles. This is expressed by defining a dependency between a profile and a model library package, or by defining a model library as contained in a profile package.

    The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is analogous to a class library in some programming languages. When a model library is defined as a part of a profile, it is imported or deleted with the application or removal of the profile. The profile is implicitly applied to its model library. In the other case, when the model library is defined as an external package imported by a profile, the profile requires that the model library be there in the model at the stage of the profile application. The application or the removal of the profile does not affect the presence of the model library elements

    Specifically the problems are:

    a) More specifics should be given for “This is expressed by for a dependency between a profile and a model library package” – such as the direction and name.

    b) Replace ‘tagged definitions’ by ‘properties’ or at least ‘tag definition’

    c) The text ‘is imported or deleted’ is vague and goes beyond anything in Profile semantics (for example does it mean a PackageImport is implicitly created?)

    d) “The profile is implicitly applied to its model library” does not make sense except in the specific case that the model library is a set of stereotyped elements, regardless of whether the model library owned by the profile: if the model library is for use within or with the profile why would it be necessary to apply stereotypes to its elements? And it goes beyond Profile semantics as well as resulting in a circular dependency between library and profile.

    e) “In the other case, when the model library is defined as an external package imported by a profile,” is inconsistent with the earlier description of ‘the other case’ which is as defined via a Dependency (not an import).

    f) “the profile requires that the model library be there in the model at the stage of the profile application” is both vague (‘be there’) and beyond profile semantics.

    Proposed resolution

    Replace the paragraph with the following:

    A package that contains model elements that are intended to be reused by other packages. Though model libraries are frequently used in conjunction with applied profiles, the classes in a model library are not stereotypes extending the metamodel. A model library is analogous to a class library in some programming languages.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Accept the proposal

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

Typo: isStric => isStrict

  • Key: UML24-72
  • Legacy Issue Number: 15384
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Typo in third paragraph below fig. 18.8: isStric should be isStrict

  • Reported: UML 2.3 — Wed, 28 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Over-general sentence about MOF and Profiles

  • Key: UML24-70
  • Legacy Issue Number: 15372
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    18.3.6 Semantics contains the following untrue sentence which should be deleted

    “The profile mechanism may be used with any metamodel that is created from MOF, including UML and CWM.”

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML 2.4: Add package:URI

  • Key: UML24-68
  • Legacy Issue Number: 15370
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it has been requested that UML have ability to uniquely reference external elements in order to support:

    Federated models

    References to libraries of datatypes

    Profiles

    At the moment, although XMI does support such references, there is no way in the model itself, to specify the URI that should be used.

    This has been a specific problem for Profile definition where there is no standard way in UML to specify the URI to be used for XMI interchange.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.77, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 7.3.77, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 7.3.77, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 7.63 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 7.14 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

    Infrastructure

    Add the following to the Attributes section of 11.9.2, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 11.9.2, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 11.9.2, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 11.27 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 11.26 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

UML 2.4: Add Property::isId

  • Key: UML24-67
  • Legacy Issue Number: 15369
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it is a fundamental capability missing from UML in being able to model various data structures for languages such as SQL and XML Schema which all have the notion of identifier.

    Although MOF restricts classes to have only one Property with isId = true, for generality the proposal does not restrict this in UML.

    Should this issue be applied to UML, a mirror issue will be applied to MOF.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.44, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading ‘Package AssociationClasses’:

    A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figure 7.12 to include isID : Boolean[0..1] in class Property

    Update the definition of the attribute ‘qualifiedName’ in section 7.3.33, NamedElement, from:

    / qualifiedName: String [0..1]

    To:

    / qualifiedName: String [0..1]

    {id}

    Infrastructure

    Add the following to the Attributes section of 10.2.5, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 10.2.5, Property:

    A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

NamedElement::clientDependency constrained to subset DirectedRelationship::source

  • Key: UML24-65
  • Legacy Issue Number: 15288
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.15, NamedElement::clientDependency is constrained to subset DirectedRelationship::source. Should be Dependency::client constrained, similarly Dependency::supplier should subset target.

  • Reported: UML 2.3 — Thu, 10 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds

  • Key: UML24-66
  • Legacy Issue Number: 15356
  • Status: closed  
  • Source: NIST ( Peter Denno)
  • Summary:

    Section 17.2.1 of the superstructure document, InformationFlow

    The text of the constraint reads "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link)."

    The OCL reads:
    (self.informationSource->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or ...

    the "p->" is missing from the second term above (should be "p->oclIsKindOf(Node)") and from all subsequent terms.

  • Reported: UML 2.3 — Wed, 7 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Create

  • Key: UML24-61
  • Legacy Issue Number: 15279
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

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

split the addition of generalization relationships among association in 14977 in two parts

  • Key: UML24-59
  • Legacy Issue Number: 15274
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Please create a new issue number to split the addition of generalization relationships among association in 14977 in two parts.

    Cases 2 and 3 below will remain in 14977 and the generalization relationships added for case 1 below will be moved to a resolution for this new issue number.

    This will give everyone in the RTF an opportunity to vote on the relationship between association end subsetting & association generalization separately from the fixes to the association end subsets.

  • Reported: UML 2.3 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 7.10 shows Feature::isStatic as abstract

  • Key: UML24-64
  • Legacy Issue Number: 15285
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.10, Feature::isStatic is shown as an abstract attribute. Also StructuralFeature::isReadOnly and all attributes of MultiplicityElement in Figure 7.5, p27

  • Reported: UML 2.3 — Wed, 9 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

It seems odd to say that Service “computes a value”.

  • Key: UML24-62
  • Legacy Issue Number: 15280
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    It seems odd to say that Service “computes a value”.

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Delete the offending phrase

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

issues relating to Figure 7.14 - The Packages diagram of the Kernel package

  • Key: UML24-63
  • Legacy Issue Number: 15283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1 A_owningPackage_packagedElement shown as directional
    2 owningPackage shown as public member of association, not declared as an association of PackageableElement (7.3.38)
    3 A_package_ownedType shown as bidirectional, but package not declared as an association of Type (7.3.51)
    4 PackageableElement::visibility:VisibilityKind default value is 'false' (7.3.38) - already submitted

  • Reported: UML 2.3 — Tue, 8 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Auxiliary

  • Key: UML24-60
  • Legacy Issue Number: 15278
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

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

UML 2.3, Figure 18.1

  • Key: UML24-58
  • Legacy Issue Number: 15269
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In UML 2.3, Figure 18.1 shows that InfrastructureLibrary::Profiles imports InfrastructureLibrary::Core::Constructs; however, this relationship should be a merge, not an import because:
    1) the InfrastructureLibrary::Profiles package adds merge increments to several metaclasses from Core::Constructs, e.g., Class, Package.
    2) the InfrastructureLibrary::Profiles package copies metaclasses from Core::Constructs without adding any content, e.g., NamedElement.

    Although UML merges Profiles at L2, the use of (1) and (2) requires a package merge relationship betwen Profiles & Constructs to reflect the intended semantics of merge increment for (1) and copy-down for (2).

    Resolution:

    Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in:

    • figure 13.1 of the infrastructure specification
    • the infrastructure metamodel
    • figure 18.1 of the superstructure specification.
  • Reported: UML 2.3 — Thu, 27 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    as suggested

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

UML2 Issue: OCL in resolution 11114 is incorrect

  • Key: UML24-56
  • Legacy Issue Number: 15267
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The OCL is the resolution is:

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    It has two problems:

    1- It is missing a closing ")" needed to balance the brackets, correcting this yields

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))))

    2- the "collect" operation above returns a Bag, and since "inherit" operation expects a Set as input, the cast "toSet()" is needed, correcting this yields:

    self.inheritedMember->includesAll(self.inherit( self.parents()>collect(p | p.inheritableMembers(self))>asSet() ))

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As the summary says

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

Term "method activation" deprecated?

  • Key: UML24-57
  • Legacy Issue Number: 15268
  • Status: closed  
  • Source: Technische UniversitäMü Institut füormatik I1 ( Florian Schneider)
  • Summary:

    In the section describing Lifelines, the term "method activations" is used twice, both times on page 508.

    (1) "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line."
    (2) "See Figure 14.12 to see method activations."

    Having had a look at Figure 14.12 and having read section 14.3.10 ExecutionSpecification, I believe that the term "method activation" is deprecated and should be substituted by the term "execution specification".

  • Reported: UML 2.3 — Fri, 28 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree that "method activation" should be changed to "execution specification" in 17.3.4 and 17.3.5

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

Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied.

  • Key: UML24-55
  • Legacy Issue Number: 15266
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    13330, resolved in UML 2.3, was not correctly applied to the specification diagrams. The following instructions were not carried out:

    Show the association name label in Figure 17.18

    Show the association name label in Figure 17.29

    Show the association name label in Figure 17.30

    Perhaps as a consequence of this, 14287 in 2.4 should have been resolved as a dup of 13330, not as an inconsistent set of changes.

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Do not make the changes to association names as proposed in 13287. Instead, leave the names as resolved in 13330 and in the UML 2.3 metamodel.
    Show the names in the diagrams as specified by 13330.

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

UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine

  • Key: UML24-54
  • Legacy Issue Number: 15265
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine. In particular, Behavior::redefinedBehavior should subset Classifier::redefinedClassifier, not Element::redefinedElement; and StateMachine::extendedStateMachine should subset Classifier::redefinedClassifier, not Element::redefinedElement. These are exactly analogous to the problem raised in issue 14554.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the suggested changes.

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

Resolution to issue 14063

  • Key: UML24-53
  • Legacy Issue Number: 15264
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Accepted resolution in UML 2.4 Ballot 8 for issue 14063 has a problem because ActivityGroup::inActivity needs to refer to StructuredActivities::Activity

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The accepted resolution for 14063 in Ballot 8 states the following:
    “In the UML 2.3 Superstructure Specification, Subclause 12.2 Abstract Syntax, in Figures 12.21 and 12.22, replace the unqualified ActivityGroup classes on the diagrams with the qualified UML::Activities::FundamentalActivities::ActivityGroup class. Remove the StructuredActivities::ActivityGroup and CompleteStructuredActivities::ActivityGroup classes from the metamodel.”
    The problem is that ActivityGroup in StructuredActivities refers, via its property inActivity, to Activity in StructuredActivities. Removing StructuredActivities::ActivityGroup deprives this property of a home. Hence we need to reinstate the copies of ActivityGroup.
    Then we also need to copy down Action into CompleteStructuredActivities, and its associations input and output, so that the structuredNodeInput

    {subsets input}

    and structuredNodeOutput

    { subsets output}

    work correctly, i.e. subset the correct types of InputPin and OutputPin.
    Note than none of this will have any effect on the merged definition of UML.

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

UML 2 issue - misleadingly named associations

  • Key: UML24-52
  • Legacy Issue Number: 15263
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The association between Package and Stereotype called “A_ownedStereotype_profile” is misleadingly named. It should be called “A_ownedStereotype_package”.

    The association between BehavioredClassifier and Behavior called “A_ownedParameter_behavioredClassifier” is misleadingly named. It should be called “A_ownedBehavior_behavioredClassifier”.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the changes as suggested.

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

Meaning of BodyCondition and its alignment with OCL

  • Key: UML24-51
  • Legacy Issue Number: 15259
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The UML superstructure allows an Operation to have:

    bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint):

    [1] The value specification for a constraint must evaluate to a Boolean value.

    Now, the OCL spec states in 7.3.6 that an operation body expression has the form:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: – some expression

    and gives an example:

    context Person::getCurrentSpouse() : Person
    pre: self.isMarried = true
    body: self.mariages->select( m | m.ended = false ).spouse

    Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid.

    Am I missing something?

    in RSA, we got around this by requiring the expression to be of the format:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: result = some expression

    Is the keyword "result" legal in the expression of bodyCondition?

  • Reported: UML 2.3 — Wed, 19 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    OCL body expressions and UML bodyConditions are inconsistently specified. For the UML spec, the
    bodyConditions need to be Boolean. The way we do this is by naming the result parameter of all of the
    operations as “result”. Then the body expressions should be of the form “result = <expression>”.
    Unfortunately, doing this in RSA causes type errors because RSA gives a well-typed expression its internal
    Boolean type which is not the same type as the UML 2.5 PrimitiveType Boolean.
    So in order to keep RSA as happy as possible, and reduce error-prone work, we’ll keep the body expressions
    in the metamodel in the OCL-like form (without the “result =”) and cause the XMI generation process to
    wrap result = (. . . ) around all of the body expressions.
    This also resolves 13258.

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

composite tags

  • Key: UML24-50
  • Legacy Issue Number: 15167
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    Are composite tag definitions allowed?

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    A Stereotype is a kind of Class and the semantics of a Property defined on a Stereotype is the same as
    that of a Property defined on a Class. Therefore, a Stereotype Property can have composite aggregation.
    The value of a composite Stereotype Property will be owned by an instance of such Stereotype. The type
    of such Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass
    (since instances of metaclasses are owned by other instantances of metaclasses); however, the type of such
    Property can be a Class defined in the Profile or a DataType defined in the Profile or accessible via import
    or via the Profile’s metamodel reference.

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

UML2 - Invalid constraint for Actor

  • Key: UML24-49
  • Legacy Issue Number: 15162
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    16.3.1 Actor says: [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary. self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    But an Actor does not have any ownedAttribute property, so this constraint is invalid.

  • Reported: UML 2.3 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

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

MessageEvents

  • Key: UML24-47
  • Legacy Issue Number: 15136
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    Could you guys shed some light in this area?
    Every tool vendor has different ideas (and implementation) what event types should be used at message ends for call message, reply message, create message or destroy message.

  • Reported: UML 2.3 — Tue, 9 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14629 for disposition

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

Detailed modeling of the Standard Profiles

  • Key: UML24-48
  • Legacy Issue Number: 15144
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof.

    Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI

    BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel.

    Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions.

    If for no other reason these need to be updated to reference other stereotypes using their upper case name.

    The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues:

    1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

    2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target

    3. Likewise for Create (when applied to Dependencies) they must both be Classifiers.

    4. There are 2 rows for Create – I presume this is one Stereotype that extends 2 metaclasses.

    5. I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

    6. The Derive stereotype should have a computation Property to ‘specify the computation’. I suggest this should be of type OpaqueExpression?

    7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency?

    8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description?

    9. Executable is a subclass of File. And I guess it should have the same constraint?

    10. Library is a subclass of File

    11. ModelLibrary needs to be cleaned up - I will raise a separate issue

    12. Description of Process seems a bit lacking

    13. It seems Realization and ImplementationClass cannot both be applied to the same element?

    14. Script is a subclass of File.

    15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target

    16. It seems odd to say that Service “computes a value”.

    17. Source is a subclass of File.

    18. It seems Specification and Type cannot both be applied to the same element?

    19. The description of Utility “A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped” – not sure what it means by ‘non-member’, but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances).

  • Reported: UML 2.3 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is quite a lot of things in one issue, most of which have already been resolved by explicitly modeling
    the profile. Some of the points suggest adding constraints to stereotypes, which I propose not to resolve
    here but instead to submit a new issue to capture the proposal. Some of the points require rewording for
    clarification, and the current resolution does this.
    The point about Derive is incorrect: Abstraction already has a mapping in the model.
    I am averse to copying the definitions into the metamodel because it will introduce redundancy and run the
    risk of future inconsistency.
    This also resolves 15278 and 15279.

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

Activity vs Action completion

  • Key: UML24-43
  • Legacy Issue Number: 15120
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved

  • Reported: UML 2.3 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered for Activities in the UML 2.5 beta specification this is now covered in Subclause 15.2.3 under “Activity
    Execution”:
    “The execution of an Activity with no streaming Parameters completes when it has no nodes executing and no nodes
    enabled for execution, or when it is explicitly terminated using an ActivityFinalNode (see sub clause 15.3). The
    execution of an Activity with streaming input Parameters shall not terminate until the cumulative number of values
    posted to each of those input Parameters (by the invoker of the Activity) is at least equal to the Parametermultiplicity
    lower bound. The execution of an Activity with streaming output Parameters shall not terminate until the cumulative
    number of values posted to each of those output Parameters (by the Activity itself) is at least equal to the Parameter
    multiplicity lower bound.”
    A StateMachine that does not reach a final state simply does not terminate (unless it is terminated by an explicit
    external action, such as the destruction of its context object).
    Disposition: Closed - No Change

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

Figure 7.15

  • Key: UML24-41
  • Legacy Issue Number: 15056
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    There are non-derived properties at both ends - clientDependency and supplierDependency.

    One association is non-navigable, that means supplierDependency is owned by Association, but what does it mean in UML metamodel implementation? How it should be implemented?

    Eclipse has no associations at all, we (MD) simply added this property into NamedElement, but not serializing it into XMI.

    I would suggest to make this property derived or remove at all (if it is not serialized, it does not affect backward compatibility).

  • Reported: UML 2.3 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Regarding the implementation of supplierDependency as an owned end of an Association, the specification
    does not give implementations, but in the metamodels, it means the supplierDependency property is owned
    by the corresponding association between NamedElement and Dependency (the one with supplier on the
    other end). One-way associations in UML are modeled this way.
    Make NamedElement::clientDependency derived to avoid modifying the client.

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

UML2.3 definition of Classifier::hasVisibilityOf is circular

  • Key: UML24-45
  • Legacy Issue Number: 15126
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    If we consider class A inherits from class B, and we have an instance of A called a, and a property in B called p. Let’s calculate the visibility of p in a, assuming p is private. I’m doing substitutions, a bit loosely, but you’ll get the point.

    a::hasVisibilityOf(p) : Boolean if (a.inheritedMember->includes(p)) then hasVisibilityOf = false else hasVisibilityOf = true

    -> we need to calculate a.inheritedMember

    a.inheritedMember->includesAll(a.inherit(

    {B.inheritableMembers(a) }

    ))

    -> we need to calculate B.inheritableMembers(a)

    B.inheritableMembers(a) =

    {p}

    ->select(m | a.hasVisibilityOf(m)) …. a.hasVisibilityOf(p)

    -> we are in a loop!

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 10006 for disposition

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

Association owned derived union

  • Key: UML24-46
  • Legacy Issue Number: 15128
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Is it really illegal to define a non-navigable association-owned property as derived union?

    When I try that I invalidate the following constraint in section 7.3.44 the metamodel:

    [6]Only a navigable property can be marked as readOnly.
    isReadOnly implies isNavigable()

    Why "efficiency of access" (as implied by navigability) restrics read-only access?

    One way to get around that is to make the property owned in the "navigableOwnerEnd" vs. "ownedEnd" of the association? do we have any precedence of doing that in an abstract syntax?

  • Reported: UML 2.3 — Mon, 22 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This constraint seems to be an old constraint from UML 1.x when navigability meant the same as ownership of property. It is not consistent with the meaning of navigability now, which is about “efficiency of access”.

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

serialization of a profile should always include the nsURI and nsPrefix tags

  • Key: UML24-38
  • Legacy Issue Number: 15006
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The UML Superstructure Specification (in Subclause 18.3.6) says that the

    serialization for a profile "should" (not "shall") specify the values for the

    nsURI and nsPrefix XMI tags and makes recommendations for what these values

    should be. However, this is not normative and "the exact specification of these

    tags is a semantic variation point".

    For the purposes of maximizing successful interchange, however, the

    serialization of a profile should always include the nsURI and nsPrefix tags,

    set as recommended in the specification. The serialization of any application

    of such a profile must then use the recommended forms for the URI and namespace

    prefix for any stereotype applications.

  • Reported: UML 2.3 — Mon, 25 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is altered to make the nsURI and nsPrefix tags mandatory. Also phrases such as “CMOF package corresponding to the” is deleted because we are not serializing a CMOF package; we are serializing a profile as a UML model.
    We do not make the format of the tags mandatory, because organizations are at liberty to create their own formats for proprietary profiles, as long as they follow XMI rules.
    The XMI examples are modified to be up to date and to follow the rules, in resolution 14448.

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

UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI

  • Key: UML24-44
  • Legacy Issue Number: 15125
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The XMI for A_redefinitionContext_redefinableElement is this:

    <ownedMember xmi:type="cmof:Association" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier" name="A_redefinedClassifier_classifier" memberEnd="Classes-Kernel-Classifier-redefinedClassifier Classes-Kernel-A_redefinedClassifier_classifier-classifier">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier-classifier" name="classifier" type="Classes-Kernel-Classifier" upper="*" lower="0" owningAssociation="Classes-Kernel-A_redefinedClassifier_classifier" association="Classes-Kernel-A_redefinedClassifier_classifier"/>
    </ownedMember>

    In the spec, classifier is shown as

    {subsets redefinitionContext}

    . This is missing from the XMI.

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

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

Enumeration Literal

  • Key: UML24-42
  • Legacy Issue Number: 15107
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement

    This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.

    is it another case of unintended inheritance?

    Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement?

  • Reported: UML 2.3 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There is another related problem. The derivation of EnumerationLiteral::/classifier is simply “enumeration”,
    but EnumerationLiteral::/classifier is [1..1] and EnumerationLiteral::enumeration is [0..1]. Creating a literal
    in a package and then asking for its classifier would cause some kind of unpleasant run-type exception.
    Since an EnumerationLiteral surely must be owned by an Enumeration, fix this by changing the multiplicity
    of EnumerationLiteral::enumeration to [1..1].
    As for the visibility, unless we change the metamodel we are stuck with it. Indeed, the constraint namespace_
    needs_visibility forces the visibility to be present.

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

Incomplete resolution to 10826

  • Key: UML24-37
  • Legacy Issue Number: 15001
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Issue 10826 was asking for two things:

    what is an applied stereotype, as opposed to the definition of the stereotype that was applied
    what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs

    The resolution for 10826 added the following paragraph:

    An instance “S” of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather
    than generalization/specialization. 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 in Figure 18.13). At the model level (such as in Figure 18.18) instances of “S” are related to
    “C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”).

    Up to the last sentence, the paragraph refers to ‘an instance “S” of Stereotype’ – i.e., the definition of “S”, a stereotype, in a profile — as illustrated in figure 18.13.

    The last sentence is relevant to question (1) of 10826; however, the resolution doesn’t actually answer the question — i.e., it doesn’t explain what ‘an instance of “S”’ actually is. >From Figure 18.18, the notation suggests that ‘an instance of “S”’ is some kind of instance specification but the resolution doesn’t actually say so and doesn’t address question (2) of 10826 either.

    I propose then to file a new issue about this and include Ed’s suggestion below as well as clarifying that in Figure 18.18, ‘an instance of “S”’ is actually an instance specification whose classifier happens to be ‘an instance “S” of Stereotype’, i.e., the definition of “S”, a kind of Class since Stereotype extends Class.

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The UML 2.5 specification and in particular the resolution to issue 17160 make this issue obsolete.
    Disposition: Closed - No Change

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

Poor example of Dependency notation

  • Key: UML24-39
  • Legacy Issue Number: 15046
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Figure 7.37 shows an example of Dependency with <<dependencyName>> in guillemets.

    The Notation text above it states:” The arrow may be labeled with an optional stereotype and an optional name.” However surely the name of the Dependency itself should not be in guillemets – only that of the stereotype.

    Note that (subclasses of) Dependency are notated using a keyword instead of a stereotype so this should also be allowed for in the text.

    Proposed resolution: the Figure should be revised to show the dependencyName not in guillemets and possibly with a stereotype name in guillemets.

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The corresponding figure in UML 2.5 is Figure 7.18. The proposed resolution is accepted.

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

Lack of graphical example of multi-element Dependency Notation

  • Key: UML24-40
  • Legacy Issue Number: 15047
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The Notation part of section 7.3.12 includes the following text but no graphical example. Furthermore the text seems less than clear (for example whether there must be a ‘junction’ (and whether shown as a point or a line) and whether each arrow entering the junction is required to have its own (open?) arrow head.

    I think that as a result of this few, if any, tools support this notation.

    “ It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.”

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 12511

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

Subsetting clauses should show the subsetted property fully qualified.

  • Key: UML24-36
  • Legacy Issue Number: 14995
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In addition to the current notation:

    {subsets activity, subsets inActivity}

    Add a notation where subsetted/redefined properties can be qualified by their owning classifier, i.e.:

    {subsets ActivityNode::activity, subsets ActivityGroup::inActivity}

    And use this notation throughout the metamodel.

    This would make it clear where to look for the subsetted/redefined properties when trying to understand the spec.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The qualified names from the metamodel are now used correctly throughout the generated definitions. Make
    clear that this is allowed in the notation for Property. Do the same for Operation

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

loopVariable ownership

  • Key: UML24-29
  • Legacy Issue Number: 14962
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 12.3.35 LoopNode

    The loopVariables of a LoopNode are OutputNodes, but they are not part of the outputs of the LoopNode. Therefore, they need to be independently owned by the LoopNode.

    The propery LoopNode::loopVariable should subset Element::ownedElement, and the association should be shown as composite on Figure 12.22. Otherwise the mustBeOwned constraint will be violated for loopVariables.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. loopVariables are owned by LoopNodes in UML 2.5.
    Disposition: Closed - No Change

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

Definition of Behavior::context is not correct

  • Key: UML24-31
  • Legacy Issue Number: 14964
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Behavior::context is a derived association, with its derivation given by:

    “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships. For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine.”

    However, an entry behavior is owned by a state which is owned by a region which must be owned (directly or indirectly) by a state machine. But a state machine is a behavior, which is a class, which is a behaviored classifier. Therefore, by the given algorithm, it is the state machine that is the context of the entry behavior, not the owner of the state machine, even if the state machine is a classifier behavior.

    This is a serious problem, since the definition for Behavior::context further says “The features of the context classifier as well as the elements visible to the

    context classifier are visible to the behavior.” And it is generally assumed in state machine modeling that an entry behavior in a state machine that is a classifier behavior has visibility to the elements of the owner of the state machine. Similarly, the semantics of a read self action is determined by the context of the activity that contains that action, and if that activity is the entry behavior of a state machine that is a classifier behavior, then the result of this action should be the owner of the state machine, not the state machine.

    In summary, the second sentence given in the first quote above seems to be the true intent of Behavior::context. The first sentence should be changed to:

    “To determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.”

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed, except that a slight change to the proposed text will also resolve Issue 14963

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

Context of a behavior owned as a nested classifier

  • Key: UML24-30
  • Legacy Issue Number: 14963
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Since a behavior is a classifier, and a class is a behaviored classifier, it is possible for a class to own a behavior either as an ownedBehavior (inherited from BehavioredClassifier), or as a nestedClassifier (defined specifically for Class). The intended semantics of nestedClassifier is simply that a classifier is a member of the owning class as a namespace. On would not expect this to imply the additional semantics given later for owned behaviors.

    However, the derivation for Behavior::context is based on the ownership of the behavior, directly or indirectly, by a behaviored classifier, regardless of how this ownership happens. Thus it would seem that a behavior owned as a nestedClassifier would have the owning class as its context, even though it is not an ownedBehavior. It would seem better to have behaviors owned as nestedClassifiers not have the owner as a context, allowing normal visibility rules to apply for access from within the behavior to elements of its owning namespace

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14964 for disposition

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

UML 2: property redefinitions should be symmetric across associations

  • Key: UML24-34
  • Legacy Issue Number: 14993
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    When one end of an association is redefined in the metamodel, the other end should be redefined as well. Otherwise the semantics are ill-defined.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

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

The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting

  • Key: UML24-35
  • Legacy Issue Number: 14994
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The containment between Activity and StructuredActivityNode has one end redefining (wrong) and the other subsetting (right). Because redefining and subsetting should be symmetric, this means that both ends are both redefining and subsetting. This is clearly wrong, because it would mean that all nodes and groups are StructuredActivityNodes. The

    {redefines activity, redefines inactivity}

    should be turned into subsetting.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is incorrect. The redefinition is necessary, per the revisions made for UML/MOF/XMI 2.4.1.
    Disposition: Closed - No Change

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

Matching subsettting across association ends

  • Key: UML24-32
  • Legacy Issue Number: 14977
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    What’s our position about matching subsetting across association ends? I’m looking, for example, at the property Extend::Extension. This subsets source; but its other end subsets ownedMember. This clearly implies that Extend::Extension also subsets namespace (and owner); and the ownerMember end should also subset ownedElement.

    There are plenty of examples of this all over the spec.

    It would be nice to get this right for 2.4. Is this something we’ve already identified?

  • Reported: UML 2.3 — Thu, 14 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following OCL query is designed to find all associations that have asymmetric subsetting of their association ends:
    https://dev.enterprisecomponent.com/repository/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/associationsWithAsymmetricSubsetting.ocl
    For the UML 2.4 metamodel created from the UML 2.3 metamodel, this query found 182 cases of asymmetric subsetting.
    Here is a proof that subsetting is symmetric (refer to fig 16.2 for the example, but the proof applies to any example):
    Consider UseCase u and Extend e, such that u ? e.extension.
    Then e ? u.extend [because of association invariant: c2 ? c1.p implies c1 ? c2.(p.opposite)]
    It is given that e ? u.ownedMember [ because extend subsets ownedMember ]
    Therefore u ? e.namespace [ because of association invariant ]
    Hence u ? e.extension implies u ? e.namespace, i.e. extension subsets namespace.
    For a redefined association end, the redefinition means that the same set of links are traversed by the redefining property as the redefined property. The same set of links is a special case of subsetting, and the argument then follows as for subsetting. (See 14993 which is resolved as a duplicate of this).
    Where classes and associations have needed to be copied down into a package in order to enable these changes, it has been done. We minimize changes to the current specification diagrams and text by applying the following rules:

    • Where a subsetted property is owned by an association, it is not shown in either diagram or text.
    • Where a subset constraint can be deduced, it does not need to be shown in the diagrams or text.
    • Redundant subsetted properties whose presence can be inferred from others, that are currently in the diagrams and/or text, are left there.
      We anticipate that a future version of UML may apply different conventions to its diagrams to make it simpler to reason about property subsetting.
      The vast majority of the changes involved in this resolution only occur in the metamodel and XMI, where missing subset constraints have been introduced.
      In a few cases documented in this resolution, changes are needed to the diagrams and text to show where metaclasses and/or associations are introduced into a package to make the model merge correctly. Changes are also needed to the diagrams and text wherever a material “subsets” statement is absent.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Expansion nodes using all the tokens in them as a single collection

  • Key: UML24-33
  • Legacy Issue Number: 14991
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    UML expansion regions currently treat each input as a collection, rather
    than all the inputs as members of a single collection, as the execution
    engine currently assumes. The description of Expansion Region says
    "Each input is a collection of values. If there are multiple inputs,
    each of them must hold the same kind of collection, although the types
    of the elements in the different collections may vary. The expansion
    region is executed once for each element (or position) in the input
    collection."

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on ExpansionRegion to
    indicate whether the individual tokens of the input and out expansion
    nodes are taken as collections, or whether all the tokens in the nodes
    are taken as one collection. In ExecUML this attribute value would
    always be for the second option.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of ExpansionRegions in the UML 2.5 beta specification, in
    Subclause 16.12.3, covers this.
    Disposition: Closed - No Change

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

Parameter type of MultiplicityElement::includesMultiplicity()

  • Key: UML24-5
  • Legacy Issue Number: 14580
  • Status: closed  
  • Source: Northrop Grumman ( Christopher McClure)
  • Summary:

    In the UML Infrastructure XMI, the type of Core::Abstractions::Multiplicities::MultiplicityElement::includesMultiplicity() parameter M is Core::Basic::MultiplicityElement. The type of M should be Core::Abstractions::Multiplicities::MultiplicityElement to keep Abstractions independent of Basic.

  • Reported: UML 2.3 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

typo in new attribute name

  • Key: UML24-1
  • Legacy Issue Number: 14565
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    The new 2.3 spec contains typo (double i) in new attribute name:

    iisLocallyReentrant : Boolean = false

    In Subclause 12.3.2 Action, under Attributes.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

CMOF missing several redefined property relationships

  • Key: UML24-2
  • Legacy Issue Number: 14566
  • Status: closed  
  • Source: The MathWorks ( Salman Qadri)
  • Summary:

    Since CMOF does a PackageMerge of Infrastructure-Core-Basic with Infrastructure-Core-Constructs, the resulting metaclass Operation ends up having 'isOrdered', 'isUnique', 'type', 'lower' and 'upper' properties, which conflict with the names of properties it inherits, particularly from MultiplicityElement and TypedElement. This is illegal unless these properties explicitly have redefinedProperty relationships.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Constraint [3] on TestIdentityAction is incorrect

  • Key: UML24-4
  • Legacy Issue Number: 14570
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.49 TestIdentityAction

    Constraint [3] for TestIdentityAction is:

    [3] The type of the result is Boolean.

    self.result.type.oclIsTypeOf(Boolean)

    While the English statement expresses the correct intent, the OCL is wrong. As written, the OCL requires that the type of the object referenced by the type property of the OutputPin be Boolean. But this is, of course, impossible, since the type of OutputPin::type is the metaclass Type, and any value for this property must be for an instance of a concrete subclass of type, such as Classifier or PrimitiveType. Boolean, on the other hand, is represented as an instance of the metaclass PrimitiveType. That is, the OCL for this constraint is confusing metalevels.

    The OCL should really be something like:

    self.result.type = PrimitiveType instance representing Boolean

    However, unless some sort of standard way to reference the M1 instance representing Boolean within the UML metamodel, it is unclear how to formally write “PrimitiveType instance representing Boolean”.

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

Constraint [1] for WriteStructuralFeatureAction is incorrect

  • Key: UML24-3
  • Legacy Issue Number: 14569
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.55

    The OCL for constraint [1] of WriteStructuralFeatureAction incorrectly constraints the type of the value pin of the action to be the featuring classifier of the structural feature being written to. The type of the value should actually be the same as the type of the structural feature. It is the object pin which should be constrained to have a featuring classifier as its type – but this constraint is own the parent StructuralFeatureAction class, not on WriteStructuralFeatureAction itself. The correct OCL is:

    self.value->notEmpty() implies self.value.type = self.structuralFeature.type

    (The possibility of self.value being empty is due to the resolution of Issue 9870 in UML 2.3.)

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

UML2 - non-unique association names in L3.merged.cmof

  • Key: UML24-6
  • Legacy Issue Number: 14613
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    I think the rules say that associations should be uniquely named in a package. L3.merged has three non-unique association names:

    A_outgoing_source

    A_realization_abstraction

    A_templateParameter_parameteredElement

  • Reported: UML 2.3 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issues 14287 and 14632 for disposition

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

Some owned operations with OCL expression bodies but without their "isQuery" set to "true"

  • Key: UML24-11
  • Legacy Issue Number: 14630
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    A body condition is specified for operation '<Operation> ConnectableElement::end () : ConnectorEnd [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::incoming () : Transition [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::outgoing () : Transition [0..*]', but it is not a query.

    **This is a metamodel only fix

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    All additional operations in the UML metamodel are queries and as such must be marked with isQuery = true in the metamodel

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

UML2 - definition of Property.opposite is wrong

  • Key: UML24-8
  • Legacy Issue Number: 14626
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Currently the spec says:

    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->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    This is wrong. The opposite should be calculated properly whatever the property is owned by. It should say “if the property is an association end of a binary association, opposite gives the other end”.

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 - derivation for DeploymentTarget.deployedElement is invalid

  • Key: UML24-7
  • Legacy Issue Number: 14621
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    According to 10.3.6:

    context DeploymentTarget::deployedElement derive: ((self.deployment->collect(deployedArtifact))>collect(manifestation))>collect(utilizedElement)

    But self.deployment->collect(deployedArtifact) gives a collection of DeployedArtifact, not of Artifact; therefore the call to manifestation is invalid. To make it correct from a type point of view, there needs to be an additional select to pick the DeployedArtifacts that are actually Artifacts.

    While we are at it, it is highly inappropriate to have a subclass of DeployedArtifact called Artifact: the names imply the reverse of the inheritance hierarchy.

  • Reported: UML 2.3 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML is vague about which Element should own Comments

  • Key: UML24-27
  • Legacy Issue Number: 14960
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    For example, if a comment appears on a Class diagram for a Package and is attached to one of the classes then should it be owned by the Class or the Package?

    What if there is no Package shown and it is attached to several Classes from multiple Packages?

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

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

Unclear constraint on stereotype associations

  • Key: UML24-28
  • Legacy Issue Number: 14961
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    18.3.3 Semantics contains the following:

    “Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is

    owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by

    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than

    the other class/metaclass.”

    However this is not represented in a formal Constraint and the last sentence in particular is not relevant to associations between 2 stereotypes.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is actually in 18.3.6, not 18.3.3 as stated in the issue.
    There are two aspects to the resolution: rewording of the paragraph, and adding a formal constraint.
    The paragraph is clearly (through the repeated use of the word “opposite”) intended to convey that stereotypes can participate in binary associations. This is consistent with the corresponding limitation in MOF. The rewording recognizes this.

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

lowered multiplicity

  • Key: UML24-25
  • Legacy Issue Number: 14929
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    Redefined with lowered multiplicity. It is not possible to have correct Java implementation of that, as inherited class must have getter with same name which return type is not collection, but single element. We (and Eclipse) simply ignoring these redefinitions or adding constraint which checks value number in collection.

    OccurrenceSpecification::covered [1] redefines InteractionFragment::covered [0..*]
    Transition::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    State::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    StateInvariant::covered [1] redefines InteractionFragment::covered [0..*]
    Extension::ownedEnd [1] redefines Association::ownedEnd [0..*]
    Region::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 6200

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

remove BehavioredClassifier::ownedTrigger

  • Key: UML24-26
  • Legacy Issue Number: 14931
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    can someone explain what is the purpose of "ownedTriggers" in BehavioredClassifier (page 435 of UML 2.3 spec) and how it should be used?
    There is nothing in the spec about it. The description is : "References Trigger descriptions owned by a Classifier".

    If it is intended to be container (or filter) of event types which can be consumed by this classifier behaviors, maybe it should be derived (from all owned behaviors)?
    The samantics section talks about "event pool" of the object at runtime, is it related?

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In general, the event pool of an object holds events that may be dispatched to triggers of that object. However, those triggers are generally part of a state machine or activity related to the object (either as its type or as a classifier behavior of its type). The specification does not describe what the semantics of dispatching an event directly to an ownedTrigger is, since there is not response behavior associated with such triggers. And a trigger directly owned by a behaviored classifier cannot also be owned in the normal way by a state machine or activity.
    Indeed, it is not clear that owned triggers have any purpose in UML 2 as it stands, and their inclusion without any explicit semantics is confusing. Therefore, it is agreed that BehavioredClassifier::ownedTrigger should be removed.

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

is composite and subsets not derived composite property:

  • Key: UML24-24
  • Legacy Issue Number: 14927
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    2) is composite and subsets not derived composite property:

    ProtocolTransition::preCondition:Constraint [0..]
    Profile::metaclassReference:ElementImport [0..*]
    Profile::metamodelReference:PackageImport [0..*]

    Transition::guard:Constraint [0..]
    ProtocolTransition::postCondition:Constraint [0..]
    Operation::postcondition:Constraint [0..*]
    Operation::precondition:Constraint [0..*]
    Behavior::precondition:Constraint [0..*]
    Operation::bodyCondition:Constraint [0..]
    Behavior::postcondition:Constraint [0..*]

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

wrong Actor's constraint [1]"

  • Key: UML24-22
  • Legacy Issue Number: 14875
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor).
    Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

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

is composite, but does not subset ownedElement

  • Key: UML24-23
  • Legacy Issue Number: 14926
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    I tried to collect critical metamodel implementation issues we have in our tool.

    Critical means that every time we must do changes in metamodel to be able to implement it.

    I believe, Eclipse UML2 implementation has exactly same issues.

    Issues may be devided into such groups:

    1. Properties which are composite, but do not subset ownedElement. Our solution - subset ownedElement

    2. Properties which are composite and subset other composite non-derived property. Our solution - make it non-composite as element can't be owned in two places

    I'm not sure all issues are reported, could someone help me manage that and check if all these are really must-be-fixed bugs?

    Most of these issues may be verified by running automatic script on metamodel file.

    See details below:

    1) is composite, but does not subset ownedElement

    Duration::expr:ValueSpecification [0..] is composite, but not ownedElement
    LinkEndData::qualifier:QualifierValue [0..*] is composite, but not ownedElement
    LinkAction::endData:LinkEndData [2..*] is composite, but not ownedElement
    TimeExpression::expr:ValueSpecification [0..] is composite, but not ownedElement
    ValuePin::value:ValueSpecification [1] is composite, but not ownedElement
    State::deferrableTrigger:Trigger [0..*] is composite, but not ownedElement
    CreateLinkAction::endData:LinkEndCreationData [2..*] is composite, but not ownedElement
    StructuredActivityNode::edge:ActivityEdge [0..*] is composite, but not ownedElement
    ValueSpecificationAction::value:ValueSpecification [1] is composite, but not ownedElement
    AcceptEventAction::trigger:Trigger [1] is composite, but not ownedElement
    DestroyLinkAction::endData:LinkEndDestructionData [2..*] is composite, but not ownedElement
    Stereotype::icon:Image [0..*] is composite, but not ownedElement
    TimeEvent::when:TimeExpression [1] is composite, but not ownedElement
    InteractionUse::argument:Action [0..*] is composite, but not ownedElement
    SequenceNode::executableNode:ExecutableNode [0..*] is composite, but not ownedElement
    Transition::trigger:Trigger [0..*] is composite, but not ownedElement
    StructuredActivityNode::node:ActivityNode [0..*] is composite, but not ownedElement

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue affects the Model Interchange Working Group (MIWG).
    Issue 1 is accepted: All properties which are composite, are made to subset ownedElement.
    Issue 2 is not accepted. It is acceptable for a composition to subset another composition. This does not lead to an element being owned in two places; it leads to an element being owned in one place by two links.

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

Issue on generalization

  • Key: UML24-21
  • Legacy Issue Number: 14862
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While looking over Use Cases for other changes, I realize that I’m not sure about how inheritance (generalization) works. It appears that only constraints and features are inherited. Features include structural and behavioral features, and structural features include associations.

    This seems to exclude dependencies and other directed relationships and other potentially named elements in the namespace.

    I must have something wrong, but this means that

    · include and extends are not inherited;

    · realizations are not inherited;

    · nested qualifiers are not inherited;

    · general dependencies are not inherited

  • Reported: UML 2.3 — Mon, 14 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9 is clear that it is members that are inherited. Include and extend are members. Dependencies (including
    Realizations) are not inherited. Qualifiers are owned by Properties which are inherited.
    Disposition: Closed - No Change

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

AcceptEventAction notation

  • Key: UML24-20
  • Legacy Issue Number: 14643
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    The Notation chapter of AcceptEventAction is very weak, there is no description where Event name or Signal name could be displayed.
    It says:
    "An accept event action is notated with a concave pentagon. A wait time action is notated with an hour glass. "

    There are some usage examples in “AcceptEventAction (as specialized)” on page 309 where signal names are inside AcceptEventAction symbol, but such notation is not described under Notation !

  • Reported: UML 2.3 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The description of the AcceptEventAction notation in the UML 2.5 beta specification, Subclause
    16.10.4, calls out the placement of names.
    Disposition: Closed - No Change

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

Some associations in the normative XMI has one memberEnd

  • Key: UML24-19
  • Legacy Issue Number: 14638
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The problems regarding some associations with one memberEnd actually started in the "unmerged" model but show themselves in the "merged" model.

    In 2.3, we added copy-down merge increments for some associations, in particular we added:

    a- InternalStructures::A_feature_classifier (Figure 9.2) as a merge increment for Kernel::A_feature_featuringClassifier (Figure 7.10)
    b- BasicComponents::A_role_connectorEnd (Figure 8.3) as a merge increment for InternlStructures::A_end_role (Figure 9.3)
    c- BasicComponents::A_end_connector (Figure 8.3) as a merge increment for InternalStructures::A_end_connector (Figure 9.3)

    The problem in (a) and (b) is that the merge-increment association has a different name than the original association, thus the package merge algorithm could not match them by name and they ended up both in the merged model. Since the navigable ends of those associations still have similar names, they were matched and merged in their respective Classes but their "association" references were set to the merge-increment associations, leaving the original association with only one reference in their "memberEnd" collections.

    Trying to rename the merge increment associations in (a) and (b) similar to the original associations (by renaming the non-navigable ends and also switching the order of memberEnds references in (b)) and re-performing the package merge, the associations got matched up and only one association in each case ended up in the merged model, as expected. However, the merge algorithm could not merge the non-navigable ends of the merge increment associations with their corresponding navigable ends in the original associations (due to a bug in the algorithm implementation I think), which should have resulted in keeping only the navigable ends, so both ends showed up in the merged model and the "memberEnd" collections had 3 references. To fix that temporarily (until the bug is fixed), I manually deleted the extraneous non-navigable ends from the resulting associations in the merged model.

    **These fixes affect Figures 9.2 and 8.3 to show the names of the non-naviagle ends

    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, I just had to put the "aggregation" and "multipclity" of the merge increment similar to the original.

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested by the issue, for cases (a) and (b), both the original and the copy down association need to have the same association names, same role names and same role navigability/ownership, in order for package merge to merge them into “one” association in the target package.
    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, the "aggregation" and "multiplicity" of the role in the merge increment association should be similar to the original.

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

Cycles in package imports

  • Key: UML24-17
  • Legacy Issue Number: 14636
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    "<Package> Actions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors, <Package> Activities."
    "<Package> Components" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures."
    "<Package> Deployments" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures, <Package> Components."
    "<Package> Interactions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."
    "<Package> StateMachines" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Namespace collission due to package import

  • Key: UML24-18
  • Legacy Issue Number: 14637
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Package InfrastructureLibrary::Core::Abstractions::BehavioralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Changeabilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Classifiers contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Comments contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Constraints contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Expressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Generalizations contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Instances contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Literals contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::MultiplicityExpressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Namespaces contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Ownerships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Redefinitions contains two or more indistinguishable members named "<Class> Classifier."
    Package InfrastructureLibrary::Core::Abstractions::Relationships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::StructuralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Super contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::TypedElements contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Visibilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Profiles contains two or more indistinguishable members named "<Class> Package."
    Package UML::Actions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Actions::BasicActions contains two or more indistinguishable members named "<Class> BehavioralFeature."
    Package UML::Actions::CompleteActions contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Actions::IntermediateActions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::Actions::StructuredActions contains two or more indistinguishable members named "<Class> OutputPin."
    Package UML::Activities contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Activities::CompleteActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Activities::IntermediateActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::AuxiliaryConstructs contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::AuxiliaryConstructs::InformationFlows contains two or more indistinguishable members named "<Class> Pin."
    Package UML::Classes contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Classes::Dependencies contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CommonBehaviors contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components::BasicComponents contains two or more indistinguishable members named "<Class> Property."
    Package UML::CompositeStructures contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CompositeStructures::Ports contains two or more indistinguishable members named "<Class> Property."
    Package UML::Deployments contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Deployments::Artifacts contains two or more indistinguishable members named "<Class> NamedElement."
    Package UML::Interactions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Interactions::BasicInteractions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::StateMachines contains two or more indistinguishable members named "<Class> Classifier."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Attributes without a type

  • Key: UML24-14
  • Legacy Issue Number: 14633
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Profiles::ExtensionEnd::lower is not typed (should have been of type Integer)

      • This fix is only in the metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested, set the type of „lower? to Integer

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

Errors with types of association ends not conforming to their subsetted ends

  • Key: UML24-16
  • Legacy Issue Number: 14635
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The type of AuxiliaryConstructs::Templates::RedefinableTemplateSignature::classifier does not comform to the type of the subsetted end redefinitionContext : Classifier
    The type of Classes::Interfaces::InterfaceRealization::contract does not comform to the type of the subsetted end supplier : NamedElement
    The type of CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier::encapsulatedClassifier does not comform to the type of the subsetted end encapsulatedClassifier : EncapsulatedClassifier
    The type of Activities::IntermediateActivities::Activity::group does not comform to the type of the subsetted end group : ActivityGroup
    The type of Activities::IntermediateActivities::ActivityGroup::inActivity does not comform to the type of the subsetted end inActivity : Activity
    The type of Activities::CompleteActivities::ActivityNode::inInterruptibleRegion does not comform to the type of the subsetted end inInterruptibleRegion : InterruptibleActivityRegion
    The type of Classes::Interfaces::Interface::ownedAttribute does not comform to the type of the subsetted end ownedAttribute : Property
    The type of CommonBehaviors::Communications::Class::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of CommonBehaviors::Communications::Interface::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of Components::BasicComponents::ComponentRealization::realizingClassifier does not comform to the type of the subsetted end realizingClassifier : Classifier
    The type of CompositeStructures::InternalStructures::A_ownedConnector_structuredClassifier::structuredClassifier does not comform to the type of the subsetted end structuredClassifier : StructuredClassifier
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeInput does not comform to the type of the subsetted end structuredNodeInput : InputPin
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeOutput does not comform to the type of the subsetted end structuredNodeOutput : OutputPin
    The type of Activities::IntermediateActivities::ActivityPartition::subpartition does not comform to the type of the subsetted end subpartition : ActivityPartition
    The type of Activities::IntermediateActivities::ActivityPartition::superPartition does not comform to the type of the subsetted end superPartition : ActivityPartition
    The type of Deployments::Artifacts::Manifestation::utilizedElement does not comform to the type of the subsetted end supplier : NamedElement

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform

  • Key: UML24-15
  • Legacy Issue Number: 14634
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    a) StructuredActivities::StructuredActivityNode (specializes FundamentalActivities::ActivityGroup) with the following errors:
    StructuredActivities::StructuredActivityNode::activity redefines StructuredActivities::ActivityGroup::inActivity
    StructuredActivities::StructuredActivityNode::node subsets StructuredActivities::ActivityGroup::containedNode

    b) IntermediateActivities::Activity (does not specialize any other class), with the following errors
    IntermediateActivities::Activity::group subsets Kernel::Element::ownedElement (notice that IntermediateActivities::Activity::partition subsets IntermediateActivities::Activity::group)

    c) IntermediateActivities::ActivityGroup (does not specialize any other class), with the following errors
    IntermediateActivities::ActivityGroup::inActivity subsets Kernel::Element::owner

    d) IntermediateActivities::ActivityPartition (specializes IntermediateActivities::ActivityGroup), with the following errors
    IntermediateActivities::ActivityPartition::subpartition subsets FundamentalActivities::ActivityGroup::subgroup
    IntermediateActivities::ActivityPartition::superPartition subsets FundamentalActivities::ActivityGroup::superGroup (also notice the capitaliation diff between subpartitiion and superPartiion)

    e) CompleteActivities::InterruptibleActivityRegion (specializes BasicActivities::ActivityGroup), with the following errors
    CompleteActivities::InterruptibleActivityRegion::node subsets CompleteActivities::ActivityGroup::containedNode

    f) Interfaces::Property (specializes Kernel::StructuralFeature), with the following errors
    Interfaces::Property::interface subsets Kernel::A_attribute_classifier::classifier

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These problems are a consequence of improper understanding and documentation of package merge.
    a). The problem is caused because StructuredActivities::StructuredActivityNode inherits from FundamentalActivities::ActivityGroup, not StructuredActivities::ActivityGroup. Although according to the text the latter does not exist, it is actually present in the UML 2.3 metamodel. (See also 15264). The resolution is to inherit from the local ActivityGroup. Researching this also shows that the spec document is already quite seriously adrift from the metamodel. Although this will be fixed in UML 2.5, this resolution takes some steps to fix it.
    b) The problem is caused because IntermediateActivities::Activity has no base class. The resolution is to remove the subset assertion from IntermediateActivities::Activity::group. Since the subset is correctly declared in FundamentalActivities, it is reintroduced by the merge.
    c) The problem and resolution are analogous to (b).
    d) The problem is that the subsetted properties are those in FundamentalActivities, not those in IntermediateActivities. This is like (a).
    e) The problem is that InterruptableActivityRegion inherits from BasicActivities::ActivityGroup, not CompleteActivities::ActivityGroup. We make it inherit from the latter.
    f) The problem is that the Property defined in Interfaces is not related to Classifier, so there is no /attribute association to subset. We create a local Classifier and copy down the association.

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

All enumertion literals in the model have their "classifier" collections empty

  • Key: UML24-12
  • Legacy Issue Number: 14631
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    All enumertion literals in the model have their "classifier" collections empty (i.e do not contain the corresponding enumertion)

    This issue also existed in UML 2.1.1. To fix, I can add the enumeration to the "classifier" collection of the literals. But, shouldn't EnumertionLiteral have redefined "classifier" and made it derived from "enumeration" association end?

    **This is a metamodel only fix

  • Reported: UML 2.3 — Wed, 18 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The „classifier? association is inherited by EnumerationLiteral from InstanceSpecification in the UML spec, not in the MOF spec, which the UML metamodel is an instance of. Therefore, the enumeration literals in UML should not have this property.
    However, in the UML spec, an enumeration literal?s classifier should always be set to the enumeration owning it. Therefore, „classifier? should be redefined to be a derived association end that gets it value from the „enumeration? property of enumeration literal, which should also be made non-optional, since an enumeration should not be owned by anything other than an enumeration.

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

UML2: Incomplete definition for Activity.structuredNode

  • Key: UML24-9
  • Legacy Issue Number: 14627
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Currently the sentence is incomplete:

    /structuredNode : StructuredActivityNode [0..*] Top-level structured nodes in the activity. Subsets

    It should subset node and group (according to the diagram).

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

Associations with same name that live in different packages violate unique name constraint

  • Key: UML24-13
  • Legacy Issue Number: 14632
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    Some associations that have the same name, but exist in different packages in the unmerged model, show up together in the merged model violating the unique name constraint

    BasicActivities::A_outgoing_source (Figure 12.5) and BehaviorStateMachines::A_outgoing_source (Figure 15.2).
    BasicActivities::A_incoming_target (Figure 12.5) and BehaviorStateMachines::A_incoming_target(Figure 15.2).
    BasicComponents::A_realization_abstraction (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction (Figure 17.2)

    One way to fix that is to rename the associations to avoid the name collission, for example:

    BasicActivities::A_outgoing_source_node and BehaviorStateMachines::A_outgoing_source_vertex
    BasicActivities::A_incoming_target_node and BehaviorStateMachines::A_incoming_target_vertex
    BasicComponents::A_realization_abstraction_component (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction_flow (Figure 17.2)

      • This fix affects the respective figures to show the non-default association names explicitly
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the suggestion given in the issue.

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

UML 2 Events referred to by OccurrenceSpecifications should be optional

  • Key: UML24-10
  • Legacy Issue Number: 14629
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In UML 2, every OccurrenceSpecification must be associated with an Event. The Event in turn should have a name and an owning package. But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications.

    This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model. This simply consumes memory footprint without providing any user value.

    If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects. Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1.

  • Reported: UML 2.3 — Fri, 6 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The Events that are only defined for Interactions are superfluous and is removed. The necessary information is in the Signal or Operation designated by the signature property of Message together with the MessageKind and MessageSort properties.
    In UML 2.3 the signature attribute is derived, in this revision it is changed to non-derived.

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