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

UML 2.3 RTF — Closed Issues

  • Key: UML23
  • Issues Count: 155
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UML23-155 Japan Superstructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-154 New proposal for conjugate types for ports UML 2.1.2 UML 2.3 Resolved closed
UML23-153 proper content for Figure 13.8 UML 2.1 UML 2.3 Closed; No Change closed
UML23-152 Section: 15.3.8 UML 2.1.1 UML 2.3 Resolved closed
UML23-151 Section: 14.3.20 UML 2.0 UML 2.3 Resolved closed
UML23-150 UML 2 Super / Activities / missing subsets UML 2.1 UML 2.3 Resolved closed
UML23-148 UML 2 Super / Components / realizingClassifier UML 2.0 UML 2.3 Resolved closed
UML23-149 Section: 8.3.4 UML 2.0 UML 2.3 Resolved closed
UML23-147 LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger. UML 2.2 UML 2.3 Resolved closed
UML23-146 UML 2 chapter 17: template model cannot represent templates parameterized by value types UML 2.2 UML 2.3 Resolved closed
UML23-145 Semantics of the AddVariableValueAction UML 2.2 UML 2.3b1 Resolved closed
UML23-143 What is "top-tier packages of the UML metamodel"? UML 2.2 UML 2.3 Resolved closed
UML23-125 Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-127 notation of objet flow <> and <> UML 2.2 UML 2.3 Resolved closed
UML23-126 UML 2.3 draft, 11.3.1 - AcceptCallAction UML 2.2 UML 2.3 Resolved closed
UML23-124 Duplicate association in normative UML 2.3 superstructure file UML 2.2 UML 2.3 Resolved closed
UML23-123 Japan Infrastructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-122 Japan Infrastructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-118 Japan Infrastructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-117 Japan Infrastructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-114 Japan Superstructure PAS Ballot Comments - comment 20 UML 2.2 UML 2.3 Resolved closed
UML23-113 Japan Superstructure PAS Ballot Comments - comment 19 UML 2.2 UML 2.3 Resolved closed
UML23-121 Japan Infrastructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-120 Japan Infrastructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-116 Japan Infrastructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-119 Japan Infrastructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-115 Japan Infrastructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML23-144 Section: Classes RAS 2.2 UML 2.3 Resolved closed
UML23-95 Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner UML 2.2 UML 2.3 Resolved closed
UML23-94 Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith' UML 2.2 UML 2.3 Resolved closed
UML23-99 Japan Superstructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-98 Japan Superstructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-93 Language unit of Usage UML 2.2 UML 2.3 Resolved closed
UML23-92 Documentation of merge increments in the superstructure UML 2.2 UML 2.3 Resolved closed
UML23-97 Japan Superstructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-96 Japan Superstructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML23-129 UML 2.3: Errors in example serialization for Profiles in Chapter 18 UML 2.2 UML 2.3 Resolved closed
UML23-128 errors in OCL statements of Additional Operations? UML 2.2 UML 2.3 Resolved closed
UML23-132 Value of a Property UML 2.2 UML 2.3 Resolved closed
UML23-131 Interface-redefinedInterface should subset Classifier-redefinedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-142 'false' is not a member of VisibilityKind UML 2.2 UML 2.3 Resolved closed
UML23-141 Guard of activity edge should be optional UML 2.2 UML 2.3 Resolved closed
UML23-140 Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf UML 2.2 UML 2.3 Resolved closed
UML23-130 Ordered derived unions UML 2.2 UML 2.3 Resolved closed
UML23-135 Package Extension UML 2.2 UML 2.3 Resolved closed
UML23-134 Wrong Spelling for "development" UML 2.2 UML 2.3 Resolved closed
UML23-133 Cyclick dependency UML 2.2 UML 2.3 Resolved closed
UML23-138 Invalid type for NamedElement.namespace UML 2.2 UML 2.3 Resolved closed
UML23-137 Invalid type for Slot.value UML 2.2 UML 2.3 Resolved closed
UML23-139 Minor bug in Namespace::importMembers() query UML 2.2 UML 2.3 Resolved closed
UML23-136 Contents of Dependencies package UML 2.2 UML 2.3 Resolved closed
UML23-101 Japan Superstructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-100 Japan Superstructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-109 Japan Superstructure PAS Ballot Comments - comment 15 UML 2.2 UML 2.3 Resolved closed
UML23-105 Japan Superstructure PAS Ballot Comments - comment 11 UML 2.2 UML 2.3 Resolved closed
UML23-104 Japan Superstructure PAS Ballot Comments - comment 10 UML 2.2 UML 2.3 Resolved closed
UML23-111 Japan Superstructure PAS Ballot Comments - comment 17 UML 2.2 UML 2.3 Resolved closed
UML23-110 Japan Superstructure PAS Ballot Comments - comment 16 UML 2.2 UML 2.3 Resolved closed
UML23-102 Japan Superstructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-107 Japan Superstructure PAS Ballot Comments - comment 13 UML 2.2 UML 2.3 Resolved closed
UML23-106 Japan Superstructure PAS Ballot Comments - comment 12 UML 2.2 UML 2.3 Resolved closed
UML23-103 Japan Superstructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-108 Japan Superstructure PAS Ballot Comments - comment 14 UML 2.2 UML 2.3 Resolved closed
UML23-112 Japan Superstructure PAS Ballot Comments - comment 18 UML 2.2 UML 2.3 Resolved closed
UML23-53 Figure 18.15 does not reflect the example before UML 2.2 UML 2.3 Resolved closed
UML23-52 The XMI document contains elements which should be UML 2.2 UML 2.3 Resolved closed
UML23-47 chapter 2.2, p.3 Last paragaph, second sentence UML 2.2 UML 2.3 Resolved closed
UML23-46 "Associations" part of the "9.10.3 Slot" chapter/section UML 2.2 UML 2.3 Resolved closed
UML23-44 In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a". UML 2.2 UML 2.3 Resolved closed
UML23-43 In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core" UML 2.2 UML 2.3 Resolved closed
UML23-50 18.3.6 Typo in Profile section UML 2.2 UML 2.3 Resolved closed
UML23-49 Section: Fig. 7.15: subsets at wrong side UML 2.2 UML 2.3 Resolved closed
UML23-41 Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. UML 2.2 UML 2.3 Resolved closed
UML23-42 Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile UML 2.2 UML 2.3 Resolved closed
UML23-48 Section: Chapter 2.2 Compliance levels UML 2.2 UML 2.3 Resolved closed
UML23-45 In the Attributes section, "integer" should be capitalized UML 2.2 UML 2.3 Resolved closed
UML23-51 Section: 18.3.2 UML 2.2 UML 2.3 Resolved closed
UML23-23 UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents UML 2.2 UML 2.3 Resolved closed
UML23-17 UML 2: conflicting specifications for how to calculate context for a Behavior UML 2.2 UML 2.3 Resolved closed
UML23-16 use of "internal" transition is used incorrectly in many places where "local" should be used. UML 2.2 UML 2.3 Resolved closed
UML23-18 default multiplicty of association ends are defined more than one UML 2.2 UML 2.3 Resolved closed
UML23-25 Section: 7.4 Diagrams text on page 144 UML 2.2 UML 2.3 Resolved closed
UML23-24 UML 2.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1] UML 2.2 UML 2.3 Resolved closed
UML23-28 Figure 12.95 - "Fork node example" UML 2.2 UML 2.3 Resolved closed
UML23-27 UML2 : Lifeline identity for InteractionUse UML 2.2 UML 2.3 Resolved closed
UML23-22 In the XMI, Ownerships::Element erroneously includes an association for ownedComment. UML 2.2 UML 2.3 Resolved closed
UML23-21 In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element UML 2.2 UML 2.3 Resolved closed
UML23-20 Section: 9.8.3 XMI fails to include a "lower" attribute UML 2.2 UML 2.3 Resolved closed
UML23-19 The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression UML 2.2 UML 2.3 Resolved closed
UML23-26 "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 UML 2.2 UML 2.3 Resolved closed
UML23-15 Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) UML 2.2 UML 2.3 Resolved closed
UML23-88 Propagate RTF 2.3 changes to Infrastructure UML 2.2 UML 2.3 Resolved closed
UML23-87 Need to copy down merged content to make constraints parse in receiving package UML 2.2 UML 2.3 Resolved closed
UML23-86 Remove InputPint from StructuredActivities UML 2.2 UML 2.3 Resolved closed
UML23-85 BNF of Constructs::Property UML 2.2 UML 2.3 Resolved closed
UML23-84 Ambiguity in the names of the stereotypes in the standard profiles UML 2.2 UML 2.3 Resolved closed
UML23-91 The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public UML 2.2 UML 2.3 Resolved closed
UML23-90 Difference between OCL and text in constraint [2] of 15.3.15 UML 2.2 UML 2.3 Resolved closed
UML23-89 Remove redundantant constraint [2] in 7.3.4 UML 2.2 UML 2.3 Resolved closed
UML23-73 UML 2.2 Issue - availability of PrimitiveTypes for UML models UML 2.2 UML 2.3 Resolved closed
UML23-72 lowerBound/upperBound constraints and derivations wrong UML 2.2 UML 2.3 Resolved closed
UML23-81 UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents UML 2.2 UML 2.3 Resolved closed
UML23-80 remove StructuredActivities::ActivityGroup UML 2.2 UML 2.3 Resolved closed
UML23-83 Profile::allOwningPackages UML 2.2 UML 2.3 Resolved closed
UML23-82 Properties need not be owned UML 2.2 UML 2.3 Resolved closed
UML23-71 Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace UML 2.2 UML 2.3 Resolved closed
UML23-70 UML2.2 chapter 16 : Actor constraint [1] has invalid OCL UML 2.2 UML 2.3 Resolved closed
UML23-76 UML2: error in definition of Class::nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-75 confusion re diagram on p. 83 UML 2.2 UML 2.3 Resolved closed
UML23-79 Currently is it possible for a Classifier to specialize the same classifier directly more than once UML 2.2 UML 2.3 Resolved closed
UML23-77 nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-74 Section 9.9 should classifier be added to the diagram on p 50? UML 2.2 UML 2.3 Resolved closed
UML23-78 type mismatch UML 2.2 UML 2.3 Resolved closed
UML23-32 Section 12.3.48 on page 412 UML 2.2 UML 2.3 Resolved closed
UML23-34 Figure 7.1 shows no dependency UML 2.2 UML 2.3 Resolved closed
UML23-33 Section 2.3 para 1 needs to be re-written UML 2.2 UML 2.3 Resolved closed
UML23-40 Section 13 "Core::Profiles" inconsistency UML 2.2 UML 2.3 Resolved closed
UML23-39 Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements? UML 2.2 UML 2.3 Resolved closed
UML23-37 The "Generalizations" heading is missing before the "ValueSpecification" bullet. UML 2.2 UML 2.3 Resolved closed
UML23-36 Paragraph 5: The text states that class Comment has no generalizations UML 2.2 UML 2.3 Resolved closed
UML23-31 UML 2 7.3.3 : incorrect text about aggregationKind in associations UML 2.2 UML 2.3 Resolved closed
UML23-29 Table 12.1 - "Graphic nodes included in activity diagrams", UML 2.2 UML 2.3 Resolved closed
UML23-30 Generalizations" for StructuredActivityNode on p. 417 UML 2.2 UML 2.3 Resolved closed
UML23-38 Two issues regarding Figure 10.2: 1 UML 2.2 UML 2.3 Resolved closed
UML23-35 Parameter is part of the BehavioralFeatures package. UML 2.2 UML 2.3 Resolved closed
UML23-65 Validator issues with TestCase 2 UML 2.2 UML 2.3 Resolved closed
UML23-64 current definition of a 'local' transition does not allow the case to have a local transition UML 2.2 UML 2.3 Resolved closed
UML23-59 Figures 9.17 and 9.19 and related text UML 2.2 UML 2.3 Resolved closed
UML23-58 what's the difference > between weight=1 and weight=*? UML 2.2 UML 2.3 Resolved closed
UML23-63 Clarify that input pins do not accept more tokens than their actions can immediately consume UML 2.2 UML 2.3 Resolved closed
UML23-62 The OCL for /required interfaces of Component is using ports.provided instead of ports.required UML 2.2 UML 2.3 Resolved closed
UML23-67 Clarification need on circle plus notation for containment UML 2.2 UML 2.3 Resolved closed
UML23-66 Color errors on figures in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-69 Figure 7.38 needs to be revised UML 2.2 UML 2.3 Resolved closed
UML23-68 Activity groups should be named UML 2.2 UML 2.3 Resolved closed
UML23-57 Table 2.2 Example feature support statement references Note (4) and Note (5) UML 2.2 UML 2.3 Resolved closed
UML23-56 Description of Level 1 diagram does not make sense with respect to figure 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-61 Clarify how the provided and required interfaces of a Port are calculated UML 2.2 UML 2.3 Resolved closed
UML23-60 Missing keyword? UML 2.2 UML 2.3 Resolved closed
UML23-54 Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class" UML 2.2 UML 2.3 Resolved closed
UML23-55 URIs do not refer to existing resources (404 errors) Annex H UML 2.2 UML 2.3 Resolved closed
UML23-14 Section: 14.3.13 Interaction (from BasicInteraction, Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-13 Notation for ExecutionSpecification UML 2.2 UML 2.3 Resolved closed
UML23-6 Section: 7.3.39 PackageImport (from Kernel) UML 2.2 UML 2.3 Resolved closed
UML23-5 Section: 7.3.12 Dependency (from Dependencies) UML 2.2 UML 2.3 Resolved closed
UML23-11 Val(MyCar.Interaction [SVWB UML 2.2 UML 2.3 Resolved closed
UML23-10 Section: 12.3.14 Figure 12.29 on page 320 UML 2.2 UML 2.3 Resolved closed
UML23-8 Section: 14.3.24 MessageSort (from BasicInteractions) UML 2.2 UML 2.3 Resolved closed
UML23-7 Section: 14.3.3 CombinedFragment (from Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-9 "description" section of the Behavior metaclass UML 2.2 UML 2.3 Resolved closed
UML23-2 Parameter isn't package (Heading 2 level) UML 2.2 UML 2.3 Resolved closed
UML23-1 Super package should import NamedElement from the Visibilities package, not Namespaces UML 2.2 UML 2.3 Resolved closed
UML23-12 description of Interaction provided by the Semantic section inconsistent UML 2.2 UML 2.3 Resolved closed
UML23-4 Section: 14.3.20 Actors in Interactions UML 2.2 UML 2.3 Resolved closed
UML23-3 Figure 9.20 UML 2.2 UML 2.3 Resolved closed

Issues Descriptions

Japan Superstructure PAS Ballot Comments - comment 9

  • Key: UML23-155
  • Legacy Issue Number: 14266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE All the heading should be numbered as subclauses or itemized as lists.

    Follow Directives part2 5.2.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There are a large number of Bold headings in the document, which are not numbered. Many OMG specs do this, and it was used in ISO/IEC 19501. Changing the spec at this time to give each one of these Bold headers their own subsection number. e.g., sec 7.3.3 has sub headings "Generalization" , "Description" etc., is too large too large an undertaking to incorporate into version 2.3 of UML.
    Revised Text:

    Disposition: Closed, No Change

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

New proposal for conjugate types for ports

  • Key: UML23-154
  • Legacy Issue Number: 13081
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

    Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

    There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

    We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

    This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

    Is this acceptable?

  • Reported: UML 2.1.2 — Thu, 6 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a verbatim duplicate of 13080 which I will address soon.

    Revised Text:
    None.

    Disposition: Duplicate.

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

proper content for Figure 13.8

  • Key: UML23-153
  • Legacy Issue Number: 10083
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 2.1 spec, 06-04-02, has lost the proper content for Figure 13.8, by duplicating the content of Figure 13.7 again and labeling it 13.8. See pages 442 and 443 as paginated in the pdf, 462 and 463 as paginated by Adobe in onscreen display.

    above from the 06-04-02 spec, below from the 05-07-04 spec

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Closed; No Change — UML 2.3
  • Disposition Summary:

    Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

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

Section: 15.3.8

  • Key: UML23-152
  • Legacy Issue Number: 10082
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?

  • Reported: UML 2.1.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

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

Section: 14.3.20

  • Key: UML23-151
  • Legacy Issue Number: 10076
  • Status: closed  
  • Source: Thomson Transaction Services ( Tim Grunewald)
  • Summary:

    My question regards the following: Syntax for the Message name is the following: <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’ <argument> ::= (<[parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter-name> [‘:’ <argument-value>] | ‘ -’ First, I see a typo in the argument definition where the beginning of the definition should read as follows (Note the first square bracket and less than symbol): <argument> ::= ([<parameter-name> ‘=’] Second, I would like clarification on this item. From the definition it seems that I cannot specify a message by just showning the parameters. For example, if I have a class that has an operation of setFoo(int value): void, I cannot have a message of the method and its parameters, for example, "setFoo(value)". It would look like this instead "setFoo(value=)" according to the definition in the specification. To me this just doesn't seem right to have this hanging equal sign. There are other examples, pages 458 and 491 for example, that show a parameter without the equals sign. Could someone clarify this for me?

  • Reported: UML 2.0 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Discussion:
    This issue seems to have been fixed already.
    Disposition: ClosedNoChange

  • Updated: Sun, 8 Mar 2015 14:22 GMT

UML 2 Super / Activities / missing subsets

  • Key: UML23-150
  • Legacy Issue Number: 8668
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::node, Activity::edge, and Activity::group do not subset Namespace::ownedMember, but they should

  • Reported: UML 2.1 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 14:22 GMT

UML 2 Super / Components / realizingClassifier

  • Key: UML23-148
  • Legacy Issue Number: 8385
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    InterfaceRealization is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that InterfaceRealization must have a "realizingClassifier", even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that InterfaceRealization has its own association end that serves a similar purpose called "implementingClassifier". But, this only makes sense for the case when the target of the realization is an Interface and not a Component.

    InterfaceRealization should not be forced to have a "realizingClassifier" attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., ComponentRealization) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This has already been resolved in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Sun, 8 Mar 2015 14:18 GMT

Section: 8.3.4

  • Key: UML23-149
  • Legacy Issue Number: 8386
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a duplicate of part of 10651.

    Revised Text:
    None.

    Disposition: Duplicate.

  • Updated: Sun, 8 Mar 2015 14:18 GMT

LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Key: UML23-147
  • Legacy Issue Number: 19293
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Reported: UML 2.2 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 03:22 GMT

UML 2 chapter 17: template model cannot represent templates parameterized by value types

  • Key: UML23-146
  • Legacy Issue Number: 14062
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In a programming language such as C# it is common, in libraries, to create parameterized types such as List<T>, which can be instantiated as List<Foo>, List<int>, List<Boolean> and so on.

    UML templates do not permit the equivalent. The parameters of a template are all instantiated objects of a known concrete metaclass. It is therefore invalid for parameter-kind (17.5.4) to be an abstract metaclass, such as Type. This is a very severe limitation when trying to map UML to C#.

  • Reported: UML 2.2 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter, duplicate of 13257

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Semantics of the AddVariableValueAction

  • Key: UML23-145
  • Legacy Issue Number: 14027
  • Status: closed  
  • Source: European Software Institute (ESI -Tecnalia) ( Aitor Aldazabal)
  • Summary:

    In the Semantics of the AddVariableValueAction there is a line stating: "If isReplaceAll is false and the variable is unordered and non-unique, then adding an existing value has no effect." I find this statement in correct and in conflict with the semantics defined in multiplicity element. multiplicityElement.ordered -> Specifies whether the values are inserted in a certain position which can be identified by an Integer. This has no influence whatsoever on WHAT values can be added to a variable. multiplicityElement.unique -> An instance (of any type) cannot appear more than once in the collection of values. addVariableValueAction.isReplaceAll -> Specifies if all the previous values are removed before inserting the new ones. This does have influence on WHAT values can be added to a variable. Therefore if the addVariableValueAction is true then the input collection only needs to be evaluated. Else the input collection and the existing values need to be cheked. If the variable IS unique then it must be ensured that the add operation does not put the same instance more than once in the variable. This means that input collection will be merged with the existing values collection (empty collection if isReplaceAll==true) and then the repeated isntances will be removed. If the variable IS NOT unique then there is no need to check anything. Having repeated values in an unordered collection might have sense, for example to execute an algorithm to retrieve the number of times a user has logged in.

  • Reported: UML 2.2 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3b1
  • Disposition Summary:

    duplicate of issue # 8972

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

What is "top-tier packages of the UML metamodel"?

  • Key: UML23-143
  • Legacy Issue Number: 17370
  • Status: closed  
  • Source: aol.com ( Brian Book)
  • Summary:

    Under Compliance Levels, the first paragraph following the level descriptions is confusing, since it references the terms "top-tier" and "second-tier" packages without ever defining what those means.
    For me, this entire paragraph is meaningless as a result.

  • Reported: UML 2.2 — Wed, 16 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2

  • Key: UML23-125
  • Legacy Issue Number: 14355
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The MOF 2.0 Specification section 12.4 states that "Names are required for all Types and Properties". We should ensure that all Properties in the UML xmi files have names, preferably the same as the ones that were already there in UML 2.1.1 (this is a regression). An example is:

    " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.xmi (2.3) and " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.cmof (2.2) have no names. But " Classes-Interfaces-A_interface_ownedAttribute-interface" in Superstructure.cmof (2.1.1) has names.

  • Reported: UML 2.2 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The UML 2.1.1 XMI files are fully compliant with the quoted constraint that "Names are required for all Types and Properties". The UML 2.3 XMI files; however, no longer have names for several association end properties (298 in the in Superstructure.xmi; 55 in the Infrastructure.xmi). Most of these association end properties are in fact owned ends of their respective associations. These ownedEnds are MOF Properties that had names in UML 2.1.1. We consider this to be a regression, and we are to repair all such ownedEnds by restauring their name according to the naming convention specified in clause 6.4.2 that was used to name the corresponding association.
    In addition, we will ensure that there are no other Types or Properties that have no name. In Superstructure.xmi (2.3), there are 5 Associations which also must be given names. This is an XMI-only change.
    The OCL query used to find associations with unnamed association ends using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    ->sortedBy(qualifiedName).qualifiedName
    The OCL query used to report unnamed associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.name->isEmpty())->collect(a|Tuple

    { pkg=a.namespace.qualifiedName, end1_type=a.member->asSequence()->at(1).oclAsType(Property).type.name, end1_name=a.member->asSequence()->at(1).oclAsType(Property).name, end2_type=a.member->asSequence()->at(2).oclAsType(Property).type.name, end2_name=a.member->asSequence()->at(2).oclAsType(Property).name}

    )

    The OCL query used to verify that all occurrences of unnamed association ends are in fact owned ends of their associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    >forAll(a|a.member>one(m|m.name->isEmpty() and
    m.oclAsType(Property).association->notEmpty()))

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

notation of objet flow <> and <>

  • Key: UML23-127
  • Legacy Issue Number: 14431
  • Status: closed  
  • Source: Teuchos ( Samuel Rochet)
  • Summary:

    Description:

    Notation of ObjectFlow "selection" and "transformation" as a note symbole does not specifiy the content of the note relatively to these behaviors.

    In exemples figures 12.75 and 12.112 this note contains OCL constraints or free text.

    It could be usefull to specify what needs to be displayed. For exemple :

    • if the selection/transformation is an OpaqueBehavior then the body of the OpaqueBehavior is dislayed in the note
    • if the selection/transformation is another Behavior then the name of the Behavior is displayed in the note

    Note that same problem occurs for ObjectNode selection

  • Reported: UML 2.2 — Thu, 24 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The UML 2.5 specification, in subclause 15.2.4, at the end of the paragraph describing the
    selection and transformation Behavior notation, has the sentence: “The body of the note symbol may either contain
    a textual representation of the Behavior (e.g., the body of an OpaqueBehavior) or the name of a Behavior that is not
    represented textually.”
    Disposition: Closed - No Change

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

UML 2.3 draft, 11.3.1 - AcceptCallAction

  • Key: UML23-126
  • Legacy Issue Number: 14429
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The text of the description is contradictory. The first sentence says:

    “AcceptCallAction is an accept event action representing the receipt of a synchronous call request. ....”

    In the second paragraph it says:

    This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

    Although the description states twice that it is for the receipt of synchronous calls it then goes on to describe its use for asynchronous calls.

  • Reported: UML 2.2 — Tue, 22 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Accept call actions are intended to receive synchronous calls, however they will, indeed, also accept asynchronous calls, but, as already noted in the spec, no reply will be sent in such cases. The description could be better worded to make this clear without sounding contradictory.

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

Duplicate association in normative UML 2.3 superstructure file

  • Key: UML23-124
  • Legacy Issue Number: 14287
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    What state is UML 2.3 in with respect to filing issues?

    In particular, there is a duplicate association name in the Superstructure Library normative XMI file for UML 2.3 that was detected by my CMOF Import:

    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.
    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.

    I checked the XMI file and, yes, the association is duplicated

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is covered by the resolution to 13330

    Revised Text:

    Disposition: Duplicate of 13330

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

Japan Infrastructure PAS Ballot Comments - comment 9

  • Key: UML23-123
  • Legacy Issue Number: 14286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III GE This is a multipart standard, use of "Part I, II, III" make confusion. Delete Part III and Make others rewrite as clauses. 7. General Introduction, 10 Infrastructure Library, and renumber other clauses. Also, delete Part III page.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

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

Japan Infrastructure PAS Ballot Comments - comment 8

  • Key: UML23-122
  • Legacy Issue Number: 14285
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex E GE Acknowledgements are not normative specification.

    Leave them as OMG only document. Remove Annex E from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.3. However agree should be removed from ISO spec.

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

Japan Infrastructure PAS Ballot Comments - comment 4

  • Key: UML23-118
  • Legacy Issue Number: 14281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14280 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

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

Japan Infrastructure PAS Ballot Comments - comment 3

  • Key: UML23-117
  • Legacy Issue Number: 14280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

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

Japan Superstructure PAS Ballot Comments - comment 20

  • Key: UML23-114
  • Legacy Issue Number: 14277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III,, IV GE 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.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

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

Japan Superstructure PAS Ballot Comments - comment 19

  • Key: UML23-113
  • Legacy Issue Number: 14276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex K GE Acknowledgements are not normative specification. . Leave them as only OMG document but not ISO standard. Remove Annex K.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.5. Needs to be removed from ISO spec. remove section 6.5 from ISO spec and OMG spec for consistency.

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

Japan Infrastructure PAS Ballot Comments - comment 7

  • Key: UML23-121
  • Legacy Issue Number: 14284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex D GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG only document.

    Remove Annex D from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Infrastructure PAS Ballot Comments - comment 6

  • Key: UML23-120
  • Legacy Issue Number: 14283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex C TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.

    Remove Annex C or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, but Annex C is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

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

Japan Infrastructure PAS Ballot Comments - comment 2

  • Key: UML23-116
  • Legacy Issue Number: 14279
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

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

Japan Infrastructure PAS Ballot Comments - comment 5

  • Key: UML23-119
  • Legacy Issue Number: 14282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4,5 GE There is no terms ,definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Leave section 4 for future revisions to add terms and definitions.
    Issue 14279 replaces section 5 with a new Notational Conventions section. see Issue 14279 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14279

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

Japan Infrastructure PAS Ballot Comments - comment 1

  • Key: UML23-115
  • Legacy Issue Number: 14278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comment will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Revised Text:
    See resolution to OMG Issues 14283

    Disposition: Duplicate of 14283

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

Section: Classes

  • Key: UML23-144
  • Legacy Issue Number: 8768
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types.
    Revised Text:
    None.
    Disposition: Closed No Change

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

Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner

  • Key: UML23-95
  • Legacy Issue Number: 14235
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In Superstructure.xmi (2.3):

    Classes-Interfaces-Interface-ownedAttribute has a one-directional association to Classes-Kernel-Property and subsets Classes-Kernel-Namespace-ownedMember. Adding an instance of a merged Property to Interface-ownedAttribute would fail to populate the ‘owner’ or ‘namespace’ attributes of the Property (because the only slots are ‘class’ and ‘datatype’).

    This is inconsistent in 2 ways:

    1) The merged Property has the slots ‘class’ and ‘datatype’, but there is no slot for ‘interface’.

    2) Compare this to a merged Operation, which has ‘class’, ‘datatype’ as well as ‘interface’ (from Classes-Interfaces-Operation-interface). Also, Classes-Interfaces-Interface-ownedOperation has a bidirectional association with Classes-Interfaces-Operation-interface, which also feels at odds with Classes-Interfaces-Interface-ownedAttribute.

    3) Since Classes-Interfaces-Interface-ownedAttribute explicitly subsets ‘Classes-Kernel-Namespace-ownedMember’, we would expect that the association to ‘Classes-Kernel-NamedElement-namespace’ should produce a result. However since ‘namespace’ is a derived-union with no slots that accept an ‘Interface’, this remains empty (and consequently so does ‘owner’ even though the Property IS being owned by an Interface).

    I would like to suggest the following:

    1) Add a cmof:Class ‘Classes-Interfaces-Property’ to the package ‘Classes-Interfaces’ as an ‘ownedMember’ and change the ‘type’ of ‘Classes-Interfaces-Interface-ownedAttribute’ to ‘Classes-Interfaces-Property’.

    2) Add a cmof:Property ‘Classes-Interfaces-Property-interface’ as an ‘ownedAttribute’ of ‘Classes-Interfaces-Property’. This attribute should be 0..1 with the type ‘Classes-Interfaces-Interface’ and should subset ‘Classes-Kernel-RedefinableElement’, ‘Classes-Kernel-Feature-featuringClassifier’ and ‘Classes-Kernel-NamedElement-namespace’. Its’ association should be ‘Classes-Interfaces-A_interface_ownedAttribute’.

    3) Modify ‘Classes-Interfaces-A_interface_ownedAttribute’ to have the member ends be ‘Classes-Interfaces-Property-interface’ and ‘Classes-Interfaces-Interface-ownedAttribute’.

  • Reported: UML 2.2 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This inconsistency issue is substantiated as explained; the suggestion amounts to repairing Classes::Interfaces as a package merge extension of Classes::Kernel. In fact, the "copy-down" suggested in item (2) is implicitly shown in the fact that 'Property' like all of the other metaclasses defined in the Classes::Interfaces package are unqualified whereas the other metaclasses defined but not copied in this package are fully qualified.

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

Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith'

  • Key: UML23-94
  • Legacy Issue Number: 14228
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The body of the ‘Core-Constructs-Operation-isConsistentWith’ Operation in Infrastructure.xmi uses an attribute called ‘formalParameter’, which does not exist in the metamodel:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.formalParameter.size() = op.formalParameter.size() and self.returnResult.size() = op.returnResult.size() and forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))

    We should instead borrow the body from Superstructure.xmi which does not have that problem:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type))

  • Reported: UML 2.2 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolve discrepancies for RedefinableElement amongst the following artifacts:

    • Infrastructure document (clause 11.4.4)
    • Superstructure document (clause 7.3.46)
    • Infrastructure XMI: Core::Constructs::RedefinableElement
    • Superstructure XMI: Classes::Kernel::RedefinableElement
      Resolve discrepancies for Operation::isConsistentWith amongst the following artifacts:
    • Infrastructure document (clauses 11.3.4 & 11.8.2)
    • Superstructure document (clause 7.3.36)
    • Infrastructure XMI: Core::Constructs::Operation
    • Superstructure XMI: Classes::Kernel::Operation
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 4

  • Key: UML23-99
  • Legacy Issue Number: 14261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP4 3 GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502
    • OCL 2.0 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
      OCL 2, OMG, available at
      <http://www.omg.org/spec/OCL/2.0/PDF>
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14260 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

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

Japan Superstructure PAS Ballot Comments - comment 3

  • Key: UML23-98
  • Legacy Issue Number: 14260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

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

Language unit of Usage

  • Key: UML23-93
  • Legacy Issue Number: 14220
  • Status: closed  
  • Source: No company ( Eduardo Palermo)
  • Summary:

    On C.1 StandardProfileL2 the stereotype «create» is on language unit Dependencies, and «responsability» is on language unit Classes::Kernel. I think both belong to language unit Classes::Dependencies

  • Reported: UML 2.2 — Tue, 25 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Documentation of merge increments in the superstructure

  • Key: UML23-92
  • Legacy Issue Number: 14216
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure v2.2 (formal/09-02-02)

    In the superstructure specification, when a class is intended primarily as an increment to be merged with some other “base” class, this is usually documented by listing the “base” class under the Generalization section, with the annotation “(merge increment)”. While such documentation of merge intent is extremely useful for the understanding of the reader, putting this documentation under the “Generalization” section is confusing, since the way package merge is now used in the superstructure abstract syntax model has nothing to do with generalization. Further, this documentation convention is not always consistently applied, especially when the class also has “real” generalizations.

    So, the specification should retain documentation for merge increments, but the overall approach for doing this should be revised and clarified, and then this approach should be applied consistently across the specification.

  • Reported: UML 2.2 — Mon, 24 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Japan Superstructure PAS Ballot Comments - comment 2

  • Key: UML23-97
  • Legacy Issue Number: 14259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

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

Japan Superstructure PAS Ballot Comments - comment 1

  • Key: UML23-96
  • Legacy Issue Number: 14258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comments will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The TH comments (OMG Issues 14271 - JP14, 14274 - JP17) were accepted in the approved resolutions for UML 2.3. See resolutions to OMG Issues 14271 and 14274
    Revised Text:

    Disposition: Duplicate of 14271 and 14274

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

UML 2.3: Errors in example serialization for Profiles in Chapter 18

  • Key: UML23-129
  • Legacy Issue Number: 14448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are many errors in the example XMI serialization for the profile and the profile application and the xsd in section 18.3.6:

    The UML namespaces (in the definitions and the hrefs) refer to version 2.0 (and in some places inconsistently to 2.1) and should be correct for the current version

    The profile definition is missing a definition of a namespace and prefix for xmi

    The ownedMember tag should be packagedElement to be consistent with how superstructure is serialized.

    The isComposite, lower and upper tags are not valid in a superstructure serialization (and upper is not valid in an infrastructure serialization).

  • Reported: UML 2.2 — Mon, 5 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The examples are corrected to follow the rules. We remove the schema example altogether because it presupposes that we are publishing an XML Schema for UML, and we are not doing so. The text just preceding the schema example is incomprehensible and unnecessary so is deleted.

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

errors in OCL statements of Additional Operations?

  • Key: UML23-128
  • Legacy Issue Number: 14439
  • Status: closed  
  • Source: University of Bayreuth ( Thomas Buchmann)
  • Summary:

    shouldn't the OCL statement for the Utility [1] return a collection: collect(dependency|dependency.supplier)

    instead of

    collect(dependency|dependency.client) ?

    and in the OCL statement for the Utility [2] shouldn't it be (classifier.clientDependency->...)

    instead of

    (classifier.supplierDependency->...) ?

    Please clarify.

  • Reported: UML 2.2 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Value of a Property

  • Key: UML23-132
  • Legacy Issue Number: 14560
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed.

    "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent.

    Suggested resolution :

    • Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification
    • Change defaultValue to be derived according to the following constraint: {OCL}

      defaultValue = if self.isDerived then self.valueSpecification else NULL endif

  • Reported: UML 2.2 — Wed, 14 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There is some confusion in the issue. In the UML 2.5 text it is made clear that the phrase “value of a property”
    describes the state of instances of the classifier. The property has no value except in the context of an instance.
    Disposition: Closed - No Change

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

Interface-redefinedInterface should subset Classifier-redefinedClassifier

  • Key: UML23-131
  • Legacy Issue Number: 14554
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML 2.3 and earlier, Interface-redefinedInterface subsets RedefinableElement-redefinedElement. However, since Interface specializes Classifier, the property should subset Classifier-redefinedClassifier instead, which will in turn subset RedefinableElement-redefinedElement

  • Reported: UML 2.2 — Mon, 12 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    It is legal for Interface::redefinedInterface to have a subset relation with Classifier::redefinedClassifier, even if the latter is not a derived union. Such a relation simply means that, even though there are two distinct associations, any redefinedInterface must also be a redefinedClassifier – but that there may be redefinedClassifiers (of an interface) that are not redefinedInterfaces.
    Of course, if it is desired that an interface only be able to redefine another interface, then the simplest thing to do would be to just add a constraint to Interface that all redefinedClassifiers must be interfaces. Actually, the proper way to do this is to redefined the OCL operation RedefinableElement::isConsistentWith.
    On the other hand, if we make redefinedClassifier a derived union, then we also need to add non-derived subsetting associations to all the subclasses of Classifier, not just Interface. And this would result in a definite semantics change. For example, right now a class can, seemingly, realize any classifier.
    RedefinableElement::isConsistentWith is false by default, and needs to be “must be overridden for subclasses of RedefinableElement to define the consistency conditions”. Class and Interface would therefore need to override isConsistentWith in order to define the meaning of redefinition of specific kinds of classifiers. Redefinition of classifiers was introduced in order to allow behaviors, which are Classifiers, to redefine other behaviors.
    This is possibly a bigger problem. The model for redefinable elements sets up a relatively simple but quite flexible mechanism for establishing the consistency of the redefinition of various kinds of elements. But this simply has not been used properly in the specification of most kinds of redefinable elements. However, section 7.3.24 does have a simpler error, redefinedInterface cannot subset Element::redefinedElement since it doesn?t exist. See figure 7.9 and figure 7.16. Rather than address the meaning of interface redefinition in this resolution, the error should be corrected so that at least the redefineInterface contributes to a valid subset as suggested in the issue.

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

'false' is not a member of VisibilityKind

  • Key: UML23-142
  • Legacy Issue Number: 15281
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    under Attributes -
    visibility: VisibilityKind [1]
    Default value is false.

    'false' is not a member of VisibilityKind. I assume 'private' is intended, though I notice some tools have gone for 'public'.

  • Reported: UML 2.2 — Mon, 7 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Guard of activity edge should be optional

  • Key: UML23-141
  • Legacy Issue Number: 15251
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    The standard specifies the guard of an activity edge like this:

    guard : ValueSpecification [1..1] = true

    Hence it is required that every activity edge has a guard. This should be changed to [0..1] to make the guard optional.
    The standard should also say that if a guard is not present it means the same as a "true" guard.

    Note that the guard of a state machine transition is optional, so this change will make things more consistent

  • Reported: UML 2.2 — Thu, 6 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf

  • Key: UML23-140
  • Legacy Issue Number: 15221
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    In Core::Abstractions::Super::Classifier::hasVisibilityOf there is
    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    if (self.inheritedMember->includes ) then
    hasVisibilityOf = (n.visibility <> #private)
    else
    hasVisibilityOf = true

    This is wrong because “NamedElement” doesn’t have “visibility” attribute. In fact “Feature” doesn’t have “visibility” attribute as well, so all of the properties and operations for Classifier needs to be public. That’s why I think that for now “hasVisiblityOf” should be fixed to:
    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf = true

    but maybe it should be considered to add visibility attribute to Feature.

  • Reported: UML 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Ordered derived unions

  • Key: UML23-130
  • Legacy Issue Number: 14552
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union?

  • Reported: UML 2.2 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This problem actually occurs in the UML spec itself, in the definition of ExceptionHandler::output_pins
    which relies on the ordering of Action::output, which is a derived union.
    We can specify a determinate order for the common case where all of the subsetting properties are class
    owned and there is single inheritance: which is the case for Action::output. In other cases, we can just say
    that the order is undefined.

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

Package Extension

  • Key: UML23-135
  • Legacy Issue Number: 15019
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    The term "Package Extension" on page 142 seems to be obsolet and possibly may be omitted

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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 Spelling for "development"

  • Key: UML23-134
  • Legacy Issue Number: 14889
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In the first table of section C.2, the first row, <<buildComponents>>, in the column called "Description" the word development is misspelled in the phrase ”for the purpose of system level decelopment activities"

  • Reported: UML 2.2 — Tue, 22 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Cyclick dependency

  • Key: UML23-133
  • Legacy Issue Number: 14563
  • Status: closed  
  • Source: asd-software ( Jiri Schubert)
  • Summary:

    1)
    In paragraph "7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)" is constraint:
    [4] self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    2)
    inheritableMembers() is query with definition:
    [4] Classifier::inheritableMembers(c: Classifier): Set(NamedElement);
    pre: c.allParents()->includes(self)
    inheritableMembers = member->select(m | c.hasVisibilityOf(m))

    3)
    hasVisibilityOf() is query with definition:
    [5] Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    if (self.inheritedMember->includes) then
    hasVisibilityOf = (n.visibility <> #private)
    else
    hasVisibilityOf = true

  • Reported: UML 2.2 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Invalid type for NamedElement.namespace

  • Key: UML23-138
  • Legacy Issue Number: 15209
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For NamedElement there is:

    namespace: NamedElement [0..1]

    when it should be

    namespace: Namespace [0..1]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Invalid type for Slot.value

  • Key: UML23-137
  • Legacy Issue Number: 15208
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For Slot there is:

    value : InstanceSpecification [*]

    when it should be

    value : ValueSpecification [*]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10005 for disposition

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

Minor bug in Namespace::importMembers() query

  • Key: UML23-139
  • Legacy Issue Number: 15216
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    There is:

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    mem.imp.isDistinguishableFrom(mem, self)))

    when it should be

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    imp.isDistinguishableFrom(mem, self)))

  • Reported: UML 2.2 — Wed, 21 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Contents of Dependencies package

  • Key: UML23-136
  • Legacy Issue Number: 15020
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    Fig. 7.15 contains two misplaced

    {subsets}

    -clauses.

    In the two associations between Dependency and NamedElement,

    {subsets target}

    only makes sense for property supplier; the same holds for

    {subsets source}

    and property client.

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Japan Superstructure PAS Ballot Comments - comment 6

  • Key: UML23-101
  • Legacy Issue Number: 14263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Regarding Description, Notation and Semantics section, It is difficult to distinguish MetaClass name from general term, since there are several confusing occurrences which are shown in lower case letter. It seems those are inconsistent.

    Clarify their usages through the entire specification.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML.
    The Japanese National body provided the following clarification on this issue:
    "Could you just confirm the capitalization?
    We have to translate this standard to establish the Japanese Industrial Standard (JIS) after ISO standardization. In that case, unclear usage of the capitalization will make us confused."
    In many cases the capitalization is an editorial matter. There is not enough time to make a detailed proposal for making capitalization more consistent in time for this RTF.
    Should leave this issue of consistent capitalization open for discussion in future RTF for detailed proposals to be considered for resolution in the next UML version..
    Revised Text:

    Disposition: Deferred

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

Japan Superstructure PAS Ballot Comments - comment 5

  • Key: UML23-100
  • Legacy Issue Number: 14262
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP5 4,5 GE There is no terms, definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Leave section 4 for future revisions to add terms and definitions. Issue 14259 replaces section 5 with a new Notational Conventions section. see Issue 14259 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14259

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

Japan Superstructure PAS Ballot Comments - comment 15

  • Key: UML23-109
  • Legacy Issue Number: 14272
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Fig. 13.15, 13.17, 14.12, 14.16~31, …, 16.10 E The annotations with red characters and a red arrow which outside the framework are not parts of example. They are class names and/or their attributes. Also, the arrow symbol is same as UML notation. Thus, those annotations lead misunderstand.
    *Add annotation convention to somewhere.

    • Unify the arrow symbol, someone are white hatching, others are red hatching.
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Suggest adding description of red annotations to section 5, Notational Conventions.

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

Japan Superstructure PAS Ballot Comments - comment 11

  • Key: UML23-105
  • Legacy Issue Number: 14268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    12.4, E There is no subheading representing a particular diagram.

    Add subheading "Activity Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 12 is titled Activities, it serves as the context for sub-section 12.4
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 10

  • Key: UML23-104
  • Legacy Issue Number: 14267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    TL It is unclear whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

    State clearly whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    RTF does not see why Japan thinks the names might be anything but normative - they are in Annex A clearly marked as Normative. Resolution to Issue 14265 (JP 8) results in all annexes being labeled as normative or informative.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 17

  • Key: UML23-111
  • Legacy Issue Number: 14274
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex I TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition. Remove Annex I or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed, Annex I is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 16

  • Key: UML23-110
  • Legacy Issue Number: 14273
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 16.1 E Many people may misunderstand the annotations inside table 16.1 are notations of graphical nodes. Remove annotations inside table 16.1.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    add explanation of annotations.
    Revised Text:
    See Issue 14272 revision, which adds explanation of graphical annotations.

    Disposition: Duplicate of 14272

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

Japan Superstructure PAS Ballot Comments - comment 7

  • Key: UML23-102
  • Legacy Issue Number: 14264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE There are a lot of sentences which start with Metaclass name (in upper case letter) without preceding letter. In that case, It is difficult to distinguish Metaclass name from general term.

    Clarify their usages through the entire specification. When sentence starts with metaclass name, put certain preceding letter, for example article, and make it distinguishable.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML. Leave Issue open for consideration in future Revisions.
    Revised Text:

    Disposition: Deferred

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

Japan Superstructure PAS Ballot Comments - comment 13

  • Key: UML23-107
  • Legacy Issue Number: 14270
  • Status: closed  
  • Source: Anonymous
  • Summary:

    16.4 E There is no subheading representing a particular diagram.

    Add subheading "Use Case Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 16 is titled "Use Cases", it serves as the context for sub-section 16.4
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 12

  • Key: UML23-106
  • Legacy Issue Number: 14269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.4 E There is no subheading representing a particular diagram.

    Add subheading "State Machine Diagram"

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 15 is titled "State Machines", it serves as the context for sub-section 15.4.
    Revised Text:

    Disposition: Closed, No Change

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

Japan Superstructure PAS Ballot Comments - comment 8

  • Key: UML23-103
  • Legacy Issue Number: 14265
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Distinction between normative and informative part is unclear.

    Make distinction between normative and informative part.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Ensure that all annexes are labled as "normative" or "informative"
    All statements in the body of the spec (unless explicitly stated as informative) are considered as normative. The formal semantics of use of term "may" from resolution to Issue 14259 (jp 2) clarifies its use as in normative statements.
    Eg: In Section "Notation" in 7.3.3 Association" the sentence:
    "Users may conceptualize the dot as showing that the model includes a property of the type represented by the classifier touched by the dot."
    is a normative statement.

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

Japan Superstructure PAS Ballot Comments - comment 14

  • Key: UML23-108
  • Legacy Issue Number: 14271
  • Status: closed  
  • Source: Anonymous
  • Summary:

    17.3.1 1st paragrap, Semantics section. (There are several "physical" in the section) TH According to the standard, "Model" is restricted to "physical system". However, It is required to apply to conceptual/logical system.

    Remove "physical". Otherwise, add "conceptual/logical" before "system".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed to remove prefix "physical" before "system" in Section 17.3.1, para 1

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

Japan Superstructure PAS Ballot Comments - comment 18

  • Key: UML23-112
  • Legacy Issue Number: 14275
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex J GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as only OMG document but not ISO standard.
    Remove Annex J.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3
    Revised Text:
    Annex J already removed in UML 2.3.

    Disposition: Closed, No Change

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

Figure 18.15 does not reflect the example before

  • Key: UML23-53
  • Legacy Issue Number: 13860
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.15 does not reflect the example before. The property names "wrap" and "resolution" do not match. Moreover, a link is missing from :Extension to :Class which has the "metaclass" and "extension" as a role names

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

The XMI document contains elements which should be

  • Key: UML23-52
  • Legacy Issue Number: 13857
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The XMI document contains "<ownedMember>" elements which should be "<packagedElement>" due to the change in the abstract syntax (see Fig. 18.2). Actually, Eclipse UML support correctly exports "<packagedElement>". The same holds for all other XMI documents.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

chapter 2.2, p.3 Last paragaph, second sentence

  • Key: UML23-47
  • Legacy Issue Number: 13846
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    chapter 2.2, p.3 Last paragaph, second sentence: "Note that each of the four packages..." There are more than four packages.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

"Associations" part of the "9.10.3 Slot" chapter/section

  • Key: UML23-46
  • Legacy Issue Number: 13834
  • Status: closed  
  • Source: Thales Rail Signalling Solutions ( Stoica Alexandru)
  • Summary:

    In the "Associations" part of the "9.10.3 Slot" chapter/section the text : "• value : InstanceSpecification [*]" should be changed to : "• value : ValueSpecification [*]" according to the diagram provied at page 54.

  • Reported: UML 2.2 — Wed, 25 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Key: UML23-44
  • Legacy Issue Number: 13799
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core"

  • Key: UML23-43
  • Legacy Issue Number: 13798
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

18.3.6 Typo in Profile section

  • Key: UML23-50
  • Legacy Issue Number: 13853
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Third paragraph below Figure 18.8, second word: isStrict instead of isStric

  • Reported: UML 2.2 — Sun, 5 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section: Fig. 7.15: subsets at wrong side

  • Key: UML23-49
  • Legacy Issue Number: 13852
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Subsets target and subsets source at the associations from Dependency to NamedElement are at the wrong side. They are property strings of the association ends supplier and client.

  • Reported: UML 2.2 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element.

  • Key: UML23-41
  • Legacy Issue Number: 13796
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. The "Generalizations" on p. 185 says it generalizes Core::Basic::Element. Is that correct? Other classes in Core::Profiles generalize a class from Core::Constructs

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile

  • Key: UML23-42
  • Legacy Issue Number: 13797
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile". The text on p. 196 states that the role is "importedProfile". The respective statements of subsetting also do not correspond.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section: Chapter 2.2 Compliance levels

  • Key: UML23-48
  • Legacy Issue Number: 13847
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p.4, fig 2.2. The package L0 is missing which should also be merged into L1.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

In the Attributes section, "integer" should be capitalized

  • Key: UML23-45
  • Legacy Issue Number: 13800
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the Attributes section, "integer" should be capitalized

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section: 18.3.2

  • Key: UML23-51
  • Legacy Issue Number: 13855
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Remove the $ character in 'extension$_' stereotypeName

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents

  • Key: UML23-23
  • Legacy Issue Number: 13482
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    (This is quite a nasty and significant issue that arose from discussions of issues raised on the UPDM profile. It may well be declared as Urgent.)

    (start of issue)

    The Profiles chapter claims in a few places (with an example in Figure 18.16) that it’s possible to have a single Stereotype extend many metaclasses. However this is contradicted by the description of Stereotype semantics defined by means of a MOF metamodel equivalent (in Figure 18.4) which shows a ‘base_Interface’ 1..1 composite ownership property on the Home Stereotype. Which makes intuitive sense since you cannot have a free-floating stereotype instance (unattached to any element). However in the case of a Stereotype extending 2 metaclasses this would result in it having 2 mandatory composite owners (e.g. for the example in Figure 18.16 base_Class and base_Component) – which is not permitted (you could never have a valid model since an instance can only ever have one composite owner) and would not make sense (it would require each instance of the Stereotype to be attached to 2 distinct model elements – each property is mandatory).

    This 1..1 property is also reflected in the XMI serialization of a Profile (in 18.3.6) that makes the multiplicity of the base_Interface property 1..1 (by default). And in the Profile XSD where the xsd:element and xsd:attribute are again 1..1 (by default).

    Note that this issue also arises when a Stereotype inherits from another Stereotype and they both extend different metaclasses. This situation could however be addressed in the restricted case that one metaclass is a specialization of the other and by declaring that one property redefined the other. For example assume we modify Figure 18.16 to have an additional Stereotype SuperClock which generalizes Clock and extends Class (instead of Clock directly extending Class). We could then define that Clock::base_Component

    {redefines} SuperClock::base_Class. Thus the Stereotype Clock ends up with only one composite owner property.



    It seems there are two main options, one with variants, for addressing the general problem:



    A) Prohibit a stereotype extending more than one metaclass. Or restrict to the special case above where one base_X property can redefine the other.

    I’m not sure how useful it is to have Stereotypes extending multiple metaclasses anyway since one could always declare common properties on an abstract Stereotype with specialized concrete stereotypes each extending a single metaclass. Extending multiple metaclasses also gives rise to potential problems of how to express constraints – which typically require navigation to the extended element and use of its properties: if there are multiple such navigations and different properties at the target element this becomes tortuous to say the least. However I’m sure there are such profiles out there so this will ‘break’ those (despite the fact that they are inherently ill-formed anyway according to profile semantics)

    B) Modify the ‘MOF equivalent metamodel’ and the XMI and XSD rendition of Profiles to make the base_X property 0..1 instead of 1..1. This would need to be combined with a somewhat-tortuous-to-express (especially if there are more than 2 metaclasses extended) constraint that exactly one of the base_X properties (including those inherited from other Stereotypes) must be non-empty. And this constraint could not be expressed in the XSD (not that XSDs are very good for validation anyway).

    C) A variant of B) is to make the base_X property optional only if the Stereotype extends more than one metaclass (including those inherited). This would minimize the impact for the vast majority of existing profiles. However there are complications. In particular it would require redefinition of properties from general stereotypes which extend a single metaclass. In the above extended example with SuperClock, since that extends only one metaclass then SuperClock::base_Class would be defined as 1..1 as in the current specification. However Clock, in addition to defining Clock::base_Component[0..1] would also require Clock::base_Class[0..1} {redefines}

    SuperClock::base_Class. This however only works because Component specializes Class. In the general case (for example if SuperClock extended Package) then redefinition would not be possible and SuperClock::base_package would have to be changed to be optional. This violates the general design principle that extending something should not change it.

    D) Due to the complications with C), a further variant of B) is to make explicit the multiplicity of the base_X property, in the same way that it can be made explicit for

    {required}

    stereotypes. So SuperClock::basePackage may be explicitly declared to be 0..1. If defaulted to 1..1 then that prohibits it from being specialized – except by a stereotype which extends a subclass of Package and {redefines) SuperClock::basePackage with a [0..1] property. So that makes the use of [1..1] for base_X the equivalent of declaring in Java that the Stereotype is ‘final’ and cannot be extended.

    To summarize the impact of these options on existing profiles:

    A) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and probably requires new Stereotypes to be created to cover the multiple metaclasses. In those cases it will have an impact on models applying those Steretypes (to migrate to the new Stereotype) but this is a transformation that can be easily automated.

    B) Requires a change to the XMI serialization of all Stereotypes in all existing Profiles (though not models applying those profiles) and their XSD files

    C) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and requires a change to the XMI serialization of their profiles and XSD but for those stereotypes only and possibly their general stereotypes (which could be in another Profile: I think though the only case I’m aware of that does this is UPDM itself which has not yet been Finalized).

    D) Has the same impact on existing profiles as C), but has the benefit of simpler and more predictable generation rules.

    Option A) has the advantage of retaining the current simple 1..1 structural constraint which is amenable to MOF and XSD validation without the need for OCL support. The other options make it harder to validate that an instance of a stereotype is applied to exactly one instance of a UML metaclass.

    (end of issue)

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The FTF agreed that this is an issue that needs to be resolved. The solution is to provide another example in
    the specification besides the single metaclass example given in Figure 12.15 for multiple metaclass extension
    and its MOF equivalent class. Furthermore, informal constraints need to be added to the Stereotype’s
    classifier description, stating that: The upper bound of a base property is always 1
    • The multiplicity of the base property in single metaclass extension is always 1..1
    • The multiplicity of all base properties in multiple metaclass extension is always 0..1, whereas only
    one base property is allowed to contain a value at any point during runtime

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

UML 2: conflicting specifications for how to calculate context for a Behavior

  • Key: UML23-17
  • Legacy Issue Number: 13476
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to 13.3.2 context is calculated as follows: “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.” Also according to 13.3.2 ”When a behavior is instantiated as an object, it is its own context.” These two statements are contradictory.

  • Reported: UML 2.2 — Mon, 9 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The second quoted sentence is confusing, though the intended meaning is not contradictory with the calculation of the context classifier. The intent is that, when a Behavior without a context classifier is instantiated then, at runtime, the behavior instance acts as its own context object, even though it is not its own context classifier.

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

use of "internal" transition is used incorrectly in many places where "local" should be used.

  • Key: UML23-16
  • Legacy Issue Number: 13325
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    The use of "internal" transition is used incorrectly in many places where "local" should be used. The specification should be updated to correct this inconsistencies. For example, on page (575/748) of UML2.2, it states: "An entry pseudostate is used to join an external transition terminating on that entry point to an internal transition emanating from that entry point. An exit pseudostate is used to join an internal transition terminating on that exit point to an external transition emanating from that exit point" However, internal transitions are not meant to be used in this context and must be connected directly to a state. A 'local' transition is used to navigate to a subvertex which is more the use case being described here.

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This misuse of the term “internal transition” was rectified in UML 2.5. An inspection of the text reveals no remaining
    cases.
    Disposition: Closed - No Change

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

default multiplicty of association ends are defined more than one

  • Key: UML23-18
  • Legacy Issue Number: 13477
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the infrastructure 6.2.1 it says

    If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.

    However, in

    8.3.3 Associations

    The opposite ends of associations connected to the class are also listed in the same way. The sub clause states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).

    It appears that the default is 1 and the default is also * which is confusing.

    I believe it should be clarified something like this.

    When an association is shown as an attribute/property, the default multiplcity is the same as the default attribute/property multiplictty (1)

    When an assocation or attribute is shown as a association (that is, on the end of a line), the default multiplicity should be

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The default multiplicity is always 1.
    This text appears only in the section describing the structure and conventions used by the specification itself. Superstructure has the following similar text:
    The “Attributes” sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*.
    Which is inconsistent with the Infrastructure text for Attributes:
    The multiplicity of the attribute is suppressed it defaults to „1? (default in UML). In practice both documents are now explicit about all association multiplicities, and suppress only attribute multiplicities of [1].

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

Section: 7.4 Diagrams text on page 144

  • Key: UML23-25
  • Legacy Issue Number: 13591
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    text on page 144: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" Search in the document for "PackageExtension" produces a single result on this same page, which means that the term "PackageExtension" is no longer defined. Most likely, the text above should have "PackageMerge" instead, smth like: Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1]

  • Key: UML23-24
  • Legacy Issue Number: 13543
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Specification: UML 2.1 Beta 1 (2008/05/01)

    Section: 12.2 Activities (Abstract Syntax), Figure 12.18

    Summary:

    This figure shows Parameter::effect : ParameterEffectKind in a way that suggests that its multiplicity is [1..1] when in fact it is [0..1]. Also, the figure incorrectly shows an Eclipse ECore stereotype, <<eAttribute>>.

    Proposed Resolution:

    In Figure 12.18:

    • Remove the <<eAttribute>> stereotype notation for the Parameter::effect attribute
    • Show the multiplicity of the attribute explicitly, i.e.: effect : ParameterEffectKind [0..1]
  • Reported: UML 2.2 — Tue, 24 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The attribute Parameter::effect is shown on Figure 9.9 in the UML 2.5 specification, and the
    problems identified in the issue have already been resolved.
    Disposition: Closed - No Change

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

Figure 12.95 - "Fork node example"

  • Key: UML23-28
  • Legacy Issue Number: 13659
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Figure 12.95 - "Fork node example" shows "Fill Order" twice, while it should show - as explained right above - that when "Fill Order" is completed, "Ship Order" and "Send Invoice" get control.

  • Reported: UML 2.2 — Thu, 5 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10818 (resolved in UML 2.3) for disposition

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

UML2 : Lifeline identity for InteractionUse

  • Key: UML23-27
  • Legacy Issue Number: 13653
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 14.3. 18 says “An InteractionUse refers to an Interaction. The InteractionUse is a shorthand for copying the contents of the referred Interaction where the InteractionUse is.” What is the relationship of the Lifelines in the used interaction to those in the using interaction? Are they supposed to be the very same lifeline instances, or are they matched by name?

  • Reported: UML 2.2 — Mon, 2 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    UML 2.5 added constraints on covered lifelines of interactionUse stating “Lifelines are common if they have
    the same selector and represents associationEnd values.” It also clarified that selector values are constrained
    to be LiteralString or LiteralInteger
    However, it is necessary to fix some Bugs in the new lifeline and interactionUse constraints. Fix constraint
    interaction_uses_share_lifeline of lifeline and all_lifelines of interactionUse to ensure coverage of Literal-
    Integer Selector value. Also Fix selector_int_or_string constraint to properly cover both LiteralInteger and
    LiteralString options for Selector value.
    This resolution also incorporates the change from Issue 18465, which proposes changing
    : “x.oclIsKindOf(T)->notEmpty()” To: “x.oclIsKindOf(T)’’

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

In the XMI, Ownerships::Element erroneously includes an association for ownedComment.

  • Key: UML23-22
  • Legacy Issue Number: 13481
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element erroneously includes an association for ownedComment. Similarly, the XMI for this package includes an association A_ownedComment_owningElement. These more properly belong in the Comments package of Abstractions.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Key: UML23-21
  • Legacy Issue Number: 13480
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section: 9.8.3 XMI fails to include a "lower" attribute

  • Key: UML23-20
  • Legacy Issue Number: 13479
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The XMI for the various operations integerValue, booleanValue, stringValue and unlimitedValue fails to include a "lower" attribute, so the default of [1..1] is assumed.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Key: UML23-19
  • Legacy Issue Number: 13478
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

"Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144

  • Key: UML23-26
  • Legacy Issue Number: 13592
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 includes PackageImport but does not include ElementImport, described in "7.3.15 ElementImport (from Kernel)". It is also missing on p.144 in: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" It should look smth like: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport • ElementImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above)

  • Key: UML23-15
  • Legacy Issue Number: 13324
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    In the Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) it is specifying the use of 'final' to define that a redefinable element (state or transition in this case) can not be redefined. However, there is no other mention of this 'final' in the rest of the document (maybe its leftover from before?). RedefinableElement's have an isLeaf attribute which is used to determine this property. Therefore we should probably use

    {leaf}

    .

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 12380

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

Propagate RTF 2.3 changes to Infrastructure

  • Key: UML23-88
  • Legacy Issue Number: 14116
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Some of the resolutions that affected the superstructure doc in RTF 2.3 also have implications for Infrastructure. Please do the proper changes to Infrastrcture to keep the two documnets in sync"

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is confirmed. All the relevant changes are proposed below.

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

Need to copy down merged content to make constraints parse in receiving package

  • Key: UML23-87
  • Legacy Issue Number: 14115
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Currently in the metamodel:

    1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::attribute

    2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else.

    A question: is the subsetting in 1 valid?

    The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::attribute is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel.

    So to make things consistent, as Nic said, we should:

    • Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier
    • Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute.

    in addition:

    • don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures?
    • Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration".
    • So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. "
  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    For chapter 8, this resolution incorporates part of the resolution from the accepted resolution 7364, but modifies it in order to copy down the merged class and features required for the OCL constraint to parse in the context of the receiving package.
    For chapter 9, it sorts out InternalStructures::Classifier, which was introduced according to this "copy down" principle, but is not documented properly. Also Collaborations::Classifier inherits more than is necessary, so to simplify the overall documentation of Classifier in chapter 9, we can make both InternalStructures::Classifier and Collaborations::Classifier just specialize Kernel::Namespace.

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

Remove InputPint from StructuredActivities

  • Key: UML23-86
  • Legacy Issue Number: 14114
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    My inclination would be to remove StructuredActivities::InputPin, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2."

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Make InputPin only coming from CompleteStructuredActivities (and remove it from StructuredActivities in the metamodel).
    Then, for OutputPin sections add "Package CompleteStructuredActivities" as a subheading for the constraint (and move it in the metamodel to the counterparts in that package).

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

BNF of Constructs::Property

  • Key: UML23-85
  • Legacy Issue Number: 14093
  • Status: closed  
  • Source: n/a ( Jonas Gorski)
  • Summary:

    The BNF of Constructs::Property defines <Visibility> ::= '+' | '-' clearly missing the package and protected visibilities. This Contradicts the Superstructure in 7.3.44, where the BNF states all four visibilites.

  • Reported: UML 2.2 — Fri, 24 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Ambiguity in the names of the stereotypes in the standard profiles

  • Key: UML23-84
  • Legacy Issue Number: 14092
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure, v2.2

    Section: Annex C, Standard Profiles

    It is not clear what the names actually are of the stereotypes in the standard profiles of UML. The stereotypes are listed in Annex C as they would be applied (using guillemet notation). However, Subclause 18.3.8 has the style guideline: “The first letter of an applied stereotype should not be capitalized.” Due to the above style guideline, this leaves it ambiguous as to whether the actual stereotype model element is named “metaclass” or “Metaclass”. This affects XMI serialization of an application of the stereotype, because the XML element for the stereotype should use the actual stereotype model element name.

    Indeed, as a classifier, the normal practice would be for its name to be capitalized but it would then still be allowable to display this on the diagram using a lower case letter, as in «metaclass». Unfortunately, there is no normative XMI for the standard profiles, so there is currently no way to resolve this based on the normative standard.

  • Reported: UML 2.2 — Wed, 22 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The resolution is to provide normative XMI for the standard profiles, and to fix up the document accordingly. In order to do this properly we need to resolve 13306 by shipping a normative version of the UML metamodel expressed in UML. Having done this we can resolve 14092 by shipping standard profiles that refer to this normative UML metamodel.
    We change the convention so that references to stereotypes are shown with upper case letters, and change all the examples accordingly, fixing errors as we go.
    We permit lower case references but remark that they are stylistically obsolete.

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

The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public

  • Key: UML23-91
  • Legacy Issue Number: 14192
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In the SysML 1.2 RTF, we found a small bug in the normative UML 2.3 infrastructure.xmi here:
    https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3%20Normative%20XMI.zip

    The bug is described at the bottom of the SysML 1.2 RTF wiki page where I described how I adapted Maged’s excellent instructions for generating the normative UML 2.3 xmi to SysML 1.2.
    It was a bit more complicated for SysML 1.2 because we added an OCL constraint in SysML issue 11091 that required the same “copy down” package merge trick we did for UML issue 7364.
    Fortunately for SysML, it was easier for us since we had to mimick what we did in UML. Nonetheless, we should do something to avoid these annoying last-minute surprises.

  • Reported: UML 2.2 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Difference between OCL and text in constraint [2] of 15.3.15

  • Key: UML23-90
  • Legacy Issue Number: 14135
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [2] in 15.3.15 says:

    [2] A transition with kind external can source any vertex except entry points.
    context Transition inv:
    source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local)

    • Is the text and OCL saying that same thing? I think the text is saying "A implies not B", while the OCL is saying "B implies C", where:

    A : kind = TransitionKind::external
    B : source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint
    C: kind = TransitionKind::local (this is not the oppsite of "A" as there is a third kind of transition "internal")

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This constraint should be fixed to match the text.

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

Remove redundantant constraint [2] in 7.3.4

  • Key: UML23-89
  • Legacy Issue Number: 14123
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Actually, reading 7.3.8 Classifier [8], I realize that the constraint in the resolution 9374 is superfluous since [8] already prevents a Class from specializing an AssociationClass or an Association from specializing an AssociationClass.

    So, the options are:

    1) leave the constraint editorially fixed as we did and file an issue to remove it at the next RTF
    2) cancel the editorial fix and editorially remove the (superfluous) constraint from 9374

    Either way is fine with me but I think that option (2) is better than (1)."

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

UML 2.2 Issue - availability of PrimitiveTypes for UML models

  • Key: UML23-73
  • Legacy Issue Number: 13993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The introduction to section 17.4 states the following:

    A number of primitive types have been defined for use in the specification of the UML metamodel. These include

    primitive types such as Integer, Boolean, and String. These types are reused by both MOF and UML, and may potentially

    be reused also in user models.

    However the XMI for UML provides the definitions only as CMOF types not as UML types – so they cannot reliably/interchangeably be used/reused or referenced from user models. There would also need to be a normative URI defined for them.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Indeed for better interchange of UML user models, there needs to be a normative PrimitiveTypes package (with a normative URI) with the common primitive types that can be referenced by UML XMI documents.
    Additionally, since such primitive types are also needed by almost all CMOF-based metamodels, a PrimitiveTypes CMOF package is needed. Unfortunately, the PrimitiveTypes package provided in the InfrastructureLibrary is meant to be package merged vs. referenced by metamodels. Since only few metamodels merge it (still resulting in private copies), the rest duplicate these primitive types in their context.
    This resolution proposes moving the PrimitiveTypes package out of InfrastructureLibrary.cmof and into its own independent package (PrimitiveTypes.cmof). This package can then be referenced instead of copied (through package merge) by metamodels. Additionally, the package can also be exported in UML XMI as PrimitiveTypes.xmi, to be referenced by user models.

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

lowerBound/upperBound constraints and derivations wrong

  • Key: UML23-72
  • Legacy Issue Number: 13992
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Issue on UML 2.2 Superstructure, Section 7.3.32:

    1. There are 2 constraints numbered [1]

    2. The 2nd of these is: lowerBound()->notEmpty() implies lowerBound() >= 0.

    However the way lowerBound() is defined (operation [4]) means it can never be empty: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    It makes more sense to have the constraint condition apply to the stored lowerValue. i.e. lowerValue()->notEmpty() implies lowerBound() >= 0

    3. Likewise constraint [2] should be: upperValue()->notEmpty() implies upperBound() >= lowerBound()

    4. Note that this omits the test currently in constraint for lowerValue notEmpty since lowerBound will then default to 1 – and it’s necessary to have the constraint check that upperValue is not less.

    5. /upper and /lower are defined as [0..1]. However since they are defined in terms of upper/lowerValue – which always has a value - then they will never be empty so should be declared as [1].

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    1. This is no longer relevant in UML 2.5.
    2. Actually, lowerBound can be empty, because lowerValue.integerValue() will be empty if lowerValue does
    not have an integer value. Redefining lowerBound() to check if lowerValue.integerValue() is null, rather
    than just lowerValue, would ensure that lowerBound always was non-empty. With this change, simply
    lowerBound() >=0 would be sufficient for the constraint. (But see also the resolution to Issue 17583.)
    3. Similarly changing the definition of upperBound() to check upperValue.unlimitedValue() would mean
    that upperBound() >= lowerBound() would be sufficient as the constraint.
    4. Actually, including the constraint upperValue->notEmpty() is not correct. Because if the upperValue is
    empty, then upperBound() defaults to 1, which still needs to be greater than or equal to lowerBound().
    5. Actually, upper and lower are defined in terms of upperBound() and lowerBound(), not upperValue
    and lowerValue. Modified as described above, those operations will always return a value. So, the return
    parameters for upperBound() and lowerBound() should have multiplicity 1..1, as well as the attributes upper
    and lower.
    This also resolves Issue 17808.

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

UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents

  • Key: UML23-81
  • Legacy Issue Number: 14065
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In RedefinableTemplateSignature.Associations we have this

    extendedSignature : RedefinableTemplateSignature[*] The template signature that is extended by this template signature. Subsets RedefinableElement::redefinedElement.

    It should read “The template signatures that are extended ...”

    Similarly the constraint says:

    The inherited parameters are the parameters of the extended template signature.

    And should read “extended templates signatures”.

    More seriously, the semantics says nothing about what happens when more than one of the extended template signatures have parameters with the same name. Is it an error? Are they merged (in which case what happens if they are different types)? Are they all there in which case what is the syntax for differentiating them? (e.g. Super1::T : Class, Super2::T : Class)

  • Reported: UML 2.2 — Fri, 10 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Correct the plurals, and explain that qualified names will be used to differentiate in the case of clashes. Fix
    the logic of qualified names so that template parameters have them. This is a bit tricky because TemplateParameter,
    TemplateSignature, TemplateableElement and ParameterableElement do not specialize NamedElement.
    The approach adopted is to change the allNamespaces() operation on NamedElement so that if the
    template is a namespace, it is used as the enclosing namespace for the ParameterableElement, which is in
    fact guaranteed to be a NamedElement because all specializations of ParameterableElement are

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

remove StructuredActivities::ActivityGroup

  • Key: UML23-80
  • Legacy Issue Number: 14063
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that “simple” structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a “procedural” style of the use of actions (along with the use of variables, sequence nodes and value pins).

    It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don’t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2.

    Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn’t seem to add anything. And, as you note, StructuredActivityNode doesn’t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!).

    So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup – it is probably more than should be done “editorially”. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn’t actually hurt anything in the end.

  • Reported: UML 2.2 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 15264 for disposition

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

Profile::allOwningPackages

  • Key: UML23-83
  • Legacy Issue Number: 14083
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    I noticed that in section 18.3.6 (as well as Infrastructure 13.1.6) the addition operation allOwningPackages is defined in the namespace of NamedElement and not Profile. In the metamodel, this operation is defined in InfrastructureLibrary::Profiles::NamedElement, which is a class that is not defined in the spec doc in clause 18 (neither in clause 13 in InfrastructureLibrary).

    Shouldn't there be a section NamedElement in clause 18 (superstructure) and clause 13 (infrastructure libary) to define this additional operation, as implemented by the metamodel now? (since the operation is already defined in that namespace)

  • Reported: UML 2.2 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Properties need not be owned

  • Key: UML23-82
  • Legacy Issue Number: 14066
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional.

    As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything.

    So can you have a “free-floating” property? Where can you put it? Since Properties are not packagable, they can’t be owned by Packages.

    There are (at least) two ways of solving this (I prefer the first)

    1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties.

    2) Fix the hole and make properties required to be owned by something.

    A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable.

    In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams

    Again there are two ways of solving this (I prefer the first)

    1) Make connectors packageable.

    2) Fix the hole and make connectors required to be owned by something.

    A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes.

  • Reported: UML 2.2 — Thu, 9 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is incorrect to state that properties/connectors need not be owned. They both inherit Element::mustBeOwned(),
    which means that they must have an owner.
    Disposition: Closed - No Change

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

Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace

  • Key: UML23-71
  • Legacy Issue Number: 13991
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML, Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace, just like Operation-class and Operation-datatype. This is needed since the opposite of Operation-interface, which is ‘Interface-ownedOperation’ subsets ‘Classifier-feature’ and ‘Namespace-ownedMember’.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue affects the XMI and the specification document of the UML2 superstructure.

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

UML2.2 chapter 16 : Actor constraint [1] has invalid OCL

  • Key: UML23-70
  • Legacy Issue Number: 13948
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Actor constraint [1] says: 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 Actor has no ownedAttribute property, so this constraint is ill-formed.

  • Reported: UML 2.2 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 10780

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

UML2: error in definition of Class::nestedClassifier

  • Key: UML23-76
  • Legacy Issue Number: 14021
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Class::nestedClassifier currently reads:

    nestedClassifier: Classifier [*] References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember

    Element::ownedMember does not exist. It should say Subsets Namespace::ownedMember.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10829 for disposition

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

confusion re diagram on p. 83

  • Key: UML23-75
  • Legacy Issue Number: 13995
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 83 states that Classifier generalises Namespace, but the text of 9.19.1 states that Classifier (as specialized) generalises Classifier. Which is it? Should it be both?

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Currently is it possible for a Classifier to specialize the same classifier directly more than once

  • Key: UML23-79
  • Legacy Issue Number: 14035
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This seems harmless. Also, there might be scenarios where the same pair of classifiers are related by more than one
    generalization each associated with different GeneralizationSets. Prohibiting this might also invalidate existing models
    unnecessarily.
    Disposition: Closed - No Change

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

nestedClassifier

  • Key: UML23-77
  • Legacy Issue Number: 14023
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    the definition of nestedClassifier is misleading. Maybe something like: "Classifier definitions owned by the class. Subsets NameSpace::ownedMember" would be better.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Rephrase the metamodel documentation, and remove a difficult-to-parse and redundant sentence from the
    semantics.

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

Section 9.9 should classifier be added to the diagram on p 50?

  • Key: UML23-74
  • Legacy Issue Number: 13994
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 50 shows that a Classifier is generalized from Type , whereas the accompanying text states that Classifier is generalized from Type AND Classifier (as Specialized). Should Classifier (as Specialized) be added to the diagram? Thanks, Paul

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

type mismatch

  • Key: UML23-78
  • Legacy Issue Number: 14034
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::parents() is defined as "parents = generalization.general". However there is a type mismatch: the operation return type is a Set whereas the expression is a Bag. It should be defined as "parents = generalization.general->asSet()".

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section 12.3.48 on page 412

  • Key: UML23-32
  • Legacy Issue Number: 13718
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Spec. version 2.2 ptc/2008-05-xx

    Regarding section 12.3.48 on page 412, I believe that both StructuredActivityNode::node and StructuredActivityNode::edge should also subset Namespace::ownedElement.

  • Reported: UML 2.2 — Fri, 13 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, except that the reference would normally be to just Element::ownedElement, especially since this is inherited from multiple immediate superclasses of StructuredActivityNode.

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

Figure 7.1 shows no dependency

  • Key: UML23-34
  • Legacy Issue Number: 13789
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1: The text states that Figure 7.1 shows a dependency between Profiles and Core. Figure 7.1 shows no dependency.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section 2.3 para 1 needs to be re-written

  • Key: UML23-33
  • Legacy Issue Number: 13788
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1, which appears to be copied from the Superstructure, is incorrect in this context. The Superstructure has compliance levels L0-L3, but the infrastacture only has L0 and LM. The paragraph needs to be rewritten.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section 13 "Core::Profiles" inconsistency

  • Key: UML23-40
  • Legacy Issue Number: 13795
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The section title is "Core::Profiles". In Figure 1 on p. 27, "Core" and "Profiles" are top-level, sibling packages (and the previous paragraph states as much). Which is correct?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Key: UML23-39
  • Legacy Issue Number: 13794
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Key: UML23-37
  • Legacy Issue Number: 13792
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Paragraph 5: The text states that class Comment has no generalizations

  • Key: UML23-36
  • Legacy Issue Number: 13791
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 5: The text states that class Comment has no generalizations. This conflicts with Figure 9.10 on p. 37.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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 7.3.3 : incorrect text about aggregationKind in associations

  • Key: UML23-31
  • Legacy Issue Number: 13662
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The following paragraph appears in 7.3.3: “An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. The diamond shall be noticeably smaller than the diamond notation for associations. An association with aggregationKind = composite likewise has a diamond at the aggregate end, but differs in having the diamond filled in.”

    aggregationKind is a property of Property, not of Association, so this paragraph is incorrect.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Table 12.1 - "Graphic nodes included in activity diagrams",

  • Key: UML23-29
  • Legacy Issue Number: 13660
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Table 12.1 - "Graphic nodes included in activity diagrams", the row "ActivityNode" states: "See ExecutableNode, ControlNode, and ObjectNode." But the "ExecutableNode" row is missing in the table. The action needed is to insert another row in the table for "ExecutableNode" with smth like "See Action, StructuredActivityNode". But the "StructuredActivityNode" row is not present in the table as well. So insert another row for "StructuredActivityNode" with notation taken from p.419, Figure 12.133 "Notation for structured nodes".

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 11162 (resolved in UML 2.3) for disposition

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

Generalizations" for StructuredActivityNode on p. 417

  • Key: UML23-30
  • Legacy Issue Number: 13661
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Generalizations" for StructuredActivityNode on p. 417 include: • Action • ActivityGroup • ExecutableNode • Namespace but "Figure 12.21 - Structured nodes" on page 313 shows StructuredActivityNode and Action as siblings (generalization for both is ExecutableNode). So either "Action" should be removed from Generalizations for StructuredActivityNode on p. 417 or the diagram on p. 313 to be updated to show different relations between these nodes.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Two issues regarding Figure 10.2: 1

  • Key: UML23-38
  • Legacy Issue Number: 13793
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Two issues regarding Figure 10.2: 1) What is the "<<eAttribute>>" stereotype that's applied to Comment::body? I can't find a definition for it elsewhere in the document. 2) Why aren't the NamedElement::name and Comment::body attributes suffixed with "[0..1]"?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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 is part of the BehavioralFeatures package.

  • Key: UML23-35
  • Legacy Issue Number: 13790
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should this section be numbered 9.1.2? Parameter is part of the BehavioralFeatures package.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Validator issues with TestCase 2

  • Key: UML23-65
  • Legacy Issue Number: 13930
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    looked at the 7 OCL constraint failures reported in Test Case 2. There are 5 different kinds of constraints that failed. In summary I found:

    • In 2 of these it appears that the model, valid.xmi, is wrong.
    • In 2 the OCL is wrong. One can be fixed. The other should be removed from the UML spec.
    • In 1 I made a mistake when correcting an unrelated problem in the OCL.

    I'll update the Validator. If my conclusions below are correct, someone should update valid.xmi too.

    Details below:

    (Model 'TestCase2')
    Summary of Model Content:
    Total objects: 94.
    UML objects: 94
    SysML objects: 0
    The model: <uml:Model TestCase2, id=1>
    Object Inventory
    Summary of Warnings:

    • Referent not found: 0
    • Unresolved URI used for object identification: 0
    • Set members not unique: 0
    • Missing mandatory value: 0
    • No class with name specified: 0
    • Property not found: 0
    • Cannot infer class of object: 0
    • Multiplicity violation: 0
    • Type violation: 0
    • Invalid stereotype application: 0
    • No object for stereotyping: 0
    • Creation of abstract class: 0
    • OCL constraint violation: 7 <================
    • OCL execution errors: 3
    • OCL errors while evaluating derived attribute: 0
    • OCL errors due to missing derived attribute specifications: 315
    • Identical XMI attribute xmi:id used by multiple XML elements: 0
    • Expected a uml:PrimitiveType: 0
    • XMI attribute xmi:id references excessive space chars: 0

    OCL constraint violation (7)
    There are 5 variations of this error:

    1 instances of this:
    The constraint Property.redefined_property_inherited() was violated.
    View Instance 1

    2 instances of this:
    The constraint NamedElement.has_no_qualified_name() was violated.
    View Instance 1

    1 instances of this:
    The constraint Constraint.value_specification_boolean() was violated.
    View Instance 1

    1 instances of this:
    The constraint Interface.visibility() was violated.
    View Instance 1

    2 instances of this:
    The constraint RedefinableElement.redefinition_context_valid() was violated.
    View Instance 1

    The constraint Property.redefined_property_inherited() was violated.
    This one on instance 84, a Property named "redefiningProperty"

    The constraint is:
    redefinedProperty->notEmpty() implies
    redefinitionContext->notEmpty() and
    redefinedProperty->forAll(rp|redefinitionContext->
    collect(fc | fc.allParents())>asSet()>
    collect(c| c.allFeatures())>asSet()>includes(rp))

    ... 84.redefinedProperty is not empty, but 84.redefinitionContext is empty.

    In as far as this constraint is what was intended, the validator is doing the right thing. The file should specify a redefinition context. If you believe the contraint or my conclusion is incorrect, let me know. Otherwise, shall I'll write an issue against the testcase?

    The constraint Interface.visibility() was violated.
    This one on instance 29:

    The constraint is:
    self.feature->forAll(f | f.visibility = #public)

    self.feature contains one instance, named "operation1", and its visibility is not set. In as far as this constraint is what was intended, the validator is doing the right thing. If you believe the constraint or my conclusion is incorrect, let me know.

    The constraint NamedElement.has_no_qualified_name() was violated.

    This one is my mistake. I corrected an error in the derivation of qualified names, and in an unrelated act, placed that "self.name" text before the endif below. It was Set{} and should be Set{}. I'll fix the OCL in Validator and put out a new version.

    result = if self.name->notEmpty() and
    self.allNamespaces()>select(ns | ns.name>isEmpty())->isEmpty()
    then self.allNamespaces()->iterate( ns : Namespace;
    result : String = self.name | ns.name.concat(self.separator()).concat(result))
    else self.name endif <=== should be Set{}

    The constraint Constraint.value_specification_boolean() was violated.

    The constraint is:
    self.specification.booleanValue().oclIsKindOf(Boolean)

    The function booleanValue():
    result = value

    It looks like this intends to perform runtime evaluation of the OCL string in the specification property (which should more accurately be specification.body, anyway). Technically, I could do this, but there is no way to describe the evaluation in OCL, and I wouldn't really want to execute arbitrary code on my server.

    I will mark this OCL as an error, and have it return True. This OCL should be removed from the UML spec.

    The constraint RedefinableElement.redefinition_context_valid() was violated.

    After some digging I found that the definition of isRedefinitionContextValid, which is called by this was:

    redefinitionContext->
    exists(c | c.allParents()->
    includes(redefined.redefinitionContext))

    But redefined.redefinitionContext is a Collection, so the use of includes here is not correct. It should be:

    redefinitionContext->
    exists(c | c.allParents()->
    oclIntersection(redefined.redefinitionContext)->notEmpty())

    Things work fine with this correction.

  • Reported: UML 2.2 — Tue, 12 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The problems highlighted by the issue have already been resolved in the specification.
    Disposition: Closed - No Change

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

current definition of a 'local' transition does not allow the case to have a local transition

  • Key: UML23-64
  • Legacy Issue Number: 13920
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    To properly and unambiguously constrain which Region 'should' own a transition, requires that the transition kind be used (further work on issue 10498). The current definition of a 'local' transition does not allow the case to have a local transition whose target is a composite state and source is nested within that composite state. It should be possible to assign this kind of transition local semantics, i.e., the composite state will not be exited nor entered; only the nested configuration of composite state will be affected as a result of exiting the nested source state and establishing a configuration for the composite state itself, i.e., the target.

  • Reported: UML 2.2 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Update the text to explicitly include the possibility. Also, remove the reference to local self-transitions and
    replace them with an explanation about the representation of internal transitions

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

Figures 9.17 and 9.19 and related text

  • Key: UML23-59
  • Legacy Issue Number: 13909
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figures 9.17 and 9.19 and related text show that an Engine requires Power on the same port as it provides a powertrain. This makes no sense conceptually – an engine does not require power from its powertrain, it delivers power to its powertrain. Modify the examples so they make sense.

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

what's the difference > between weight=1 and weight=*?

  • Key: UML23-58
  • Legacy Issue Number: 13898
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    I agree with the resolution, but I > ask myself what's the difference > between weight=1 and weight=? Edge weight controls how many offers must be accepted by the target of the edge for any tokens to traverse the edge at the same time ("the minimum number of tokens that must traverse the edge at the same time."). The default weight=1 lets just one offer be accepted for a token to traverse (all tokens might be offerred to the ObjectFlow, but it's OK if only one is accepted, it traverses). Weight=2 requires two to be accepted, or none traverse. Weight = * requires all tokens currently at the source to be accepted for any to traverse. If for some reason the target of the ObjectFlow can't accept all the tokens required by the weight (maybe the target is full), the object flow can't accept any. In the example Ed was concerned with, there's no reason for the target of an ObjectFlow to reject offers, so weight=1 causes all the tokens at the source to move at once, as if weight=. Weight=* gives a different execution of the join in Figure 12.45 than weight=1 (refered to in the Semantics of ActivityEdge). Normally the join would take one token from Bids For Proposal when the Ready to Award Bid event occurs (or at least I thought it would, the join semantics isn't clear on that I notice), but with weight=, the join must take all the tokens in Bids For Proposal. The semantics of weight= is slightly bent, because you would think it means an infinite number of tokens must traverse at the same time. It actually means whatever number of tokens are at the source must traverse at the same time (it's using "*" like a wildcard instead of infinity, not so good). The wording of the paragraph in Semantics of ActivityEdge could be improved if you'd like to file issue. In particular: - Where it says "When the minimum number of tokens are offered" it should say "accepted" instead of "offered". - The sentence starting "An unlimited weight" should continue "means that all the tokens at the source must be accepted for any of them to traverse the edge". Conrad

  • Reported: UML 2.2 — Sat, 25 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Clarify that weight gives the minimum number of tokens that must be accepted by the target of an ActivityEdge for any tokens to traverse the edge, and that weight=UnlimitedInteger means the minimum number of tokens is the number currently at the source of the ObjectFlow.

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

Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Key: UML23-63
  • Legacy Issue Number: 13914
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Reported: UML 2.2 — Mon, 4 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The Activities, (12.3.2) Action, Semantics, item 1, says
    The object flow prerequisite is satisfied when all of the input pins are offered all necessary tokens and accept them all at once, precluding them from being consumed by any other actions. This ensures that multiple action executions competing for tokens do not accept only some of the tokens they need to begin, causing deadlock as each execution waits for tokens that are already taken by others.
    The "necessary tokens" in the first sentence above are the ones needed to execute the actions (meeting the minimum multiplicity), but should include any additional ones offered up the maximum multiplicity. Only these are accepted by the input pins, then immediately consumed by the action. The second sentence gives the motivation, which is to avoid having tokens in input pins that are not immediately consumed. This would prevent those tokens from being used to execute other actions, potentially creating deadlock or starvation. Deadlock is discussed more in issue 7221 of the UML 2.0 FTF report (http://doc.omg.org/ptc/04-10-01).

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

The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Key: UML23-62
  • Legacy Issue Number: 13912
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Clarification need on circle plus notation for containment

  • Key: UML23-67
  • Legacy Issue Number: 13933
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is not clear when the circle plus notation is available for showing containment. Can it be used for showing nested class, packages, ownedBehaviors, etc.? Any containment association in the metamodel?

  • Reported: UML 2.2 — Fri, 15 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 13936

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

Color errors on figures in UML 2.2

  • Key: UML23-66
  • Legacy Issue Number: 13931
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Here are some (hopefully editorial) errors in the figures in the recent UML 2.2 release, document 09-02-02. A conscientious OCUP candidate brought the first of these to my attention.

    Figure 6.2: What is the significance of the red color of the symbols and arrows? If none, they should be black.

    Figure 14.1: The <<merge>> arrows are black, as is most of the rest of the figure, but the <<import>> arrows are red. This confuses at least one conscientious OCUP candidate who wrote in asking the significance of the color in the figures. i.e. Are <,import>> arrows supposed to be Red?

    Now I'm going back in the spec and checking all of the Abstract Syntax sections for color. Here we go...

    Part I, Figure 1, on page 21, also has red <<import>> arrows.

    Figure 8.1: Here, one of the <<merge>> arrows is red.

    Figure 9.1: The StructuredActivities box outline is maroon.

    Figure 10.1: Red <<import>> arrow

    Figure 11.1: Red <<import>> arrows

    Figure 12.1: Two boxes have red outlines and yellow fill. (Ouch!) Lots of red arrows.

    Figure 15.2: Red <<import>> arrows

    Figure 17.1: Red <<import>> arrows

    Figure 18.1: Red <<import>> arrows

    That's all I found. Hopefully it won't take a bunch of votes to turn all of these lines black

  • Reported: UML 2.2 — Thu, 14 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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.38 needs to be revised

  • Key: UML23-69
  • Legacy Issue Number: 13947
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    Figure 7.38 needs to be revised. The arrowhead on the dependency of Figure 7.38 is on the wrong end. The example it illustrates is not consistent with software engineering practices and is consequently ambiguous and misleading and should be revised. These errors lead to endless confusion and debate among UML modelers as to the correct usage of the standard notation for dependencies. p.62 Notation, says, "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." The example of Fig. 7.38 says, "the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." These sentences should be revised. Suggested wording: "the Car class depends on on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is instantiated by the CarFactory class. That is, the Car class depends on the CarFactory class to produce instances of Car, i.e., to produce cars."

  • Reported: UML 2.2 — Thu, 4 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

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

Activity groups should be named

  • Key: UML23-68
  • Legacy Issue Number: 13943
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Activity groups should be named. Interruptible Regions in particular. Nodes, Edges, and some Activity Groups are already named, such as Activity Partitions.

  • Reported: UML 2.2 — Sun, 31 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Activity Groups specialize NamedElement intead of Element.

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

Table 2.2 Example feature support statement references Note (4) and Note (5)

  • Key: UML23-57
  • Legacy Issue Number: 13868
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 24 of PDF. Table 2.2 Example feature support statement references Note (4) and Note (5). Notes only number 1 - 3. There is no Note (4) nor Note (5).

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Description of Level 1 diagram does not make sense with respect to figure 2.2

  • Key: UML23-56
  • Legacy Issue Number: 13867
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 19 and 20 of PDF. Description of Level 1 diagram does not make sense with respect to figure 2.2. "...packages merged into Level 0 and their contents are extended...," yet packages listed on figure 2.1 (Level 0 diagram) are not shown in figure 2.2 and no <<extend>> relationship is shown. Even a <<merge>> relationship between L1 and L0 would seem clear except for the defect noted next. "Note that each of the four packages shown in the figure...," but I see twelve packages shown in figure 2.2.

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Clarify how the provided and required interfaces of a Port are calculated

  • Key: UML23-61
  • Legacy Issue Number: 13911
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Clarify how the provided and required interfaces of a Port are calculated when the type of a Port is a Component or a Class with Ports

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Missing keyword?

  • Key: UML23-60
  • Legacy Issue Number: 13910
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 9.19 shows some kind of "dependency" between interfaces, so if that means Usage, <<use>> keyword must be used

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is obsolete. The figure no longer appears in the spec.
    Disposition: Closed - No Change

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

Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Key: UML23-54
  • Legacy Issue Number: 13861
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

URIs do not refer to existing resources (404 errors) Annex H

  • Key: UML23-55
  • Legacy Issue Number: 13863
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    URIs do not refer to existing resources (404 errors)

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Section: 14.3.13 Interaction (from BasicInteraction, Fragments)

  • Key: UML23-14
  • Legacy Issue Number: 13256
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text from the specs states: "Description An interaction is a unit of behavior that focuses on the observable exchange of information between ConnectableElements. ..." "Semantics Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the Classifier." One issue is that in several other places of the specs interactions are described as being "owned" - not "enclosed" - by Classifier, e.g below on p. 492 we read "The classifier owning an Interaction may be specialized, and ..." Another question I have is that semantics of interaction as described now is focusing on passing of information between ConnectableElements of that specific Classifier - but traces of interaction include OccurrenceSpecifications of possibly several participants represented by LifeLines of one to many Classifiers. The case when Classifier interacts only with itself or a single other Classifier should be quite rare. When we have several Classifiers (represented by LifeLines) interacting, that interaction should include ConnectableElements of those several Classifiers involved, unless the "ConnectableElements of the Classifier" are considered to be some transitive closure of all ConnectableElements depicted on the interaction. In other words, I'd clarify both Description and Semantics of Interaction to something like: Interactions are units of behavior of an owning Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the owning Classifier and ConnectableElements of other interacting Classifiers. All Classifiers participating in the interaction - including owner Classifier - are represented by LifeLines."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The requested change contradicts the Lifeline Constraint “same_classifier” which states:
    “The classifier containing the referened ConnectableElement must be the same classifier, or an ancestor, of the classifier
    that contains the intraction enclosing the Lifeline.”
    Disposition: Closed - No Change

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

Notation for ExecutionSpecification

  • Key: UML23-13
  • Legacy Issue Number: 13254
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Notation for ExecutionSpecification is described as: "Notation ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see “Lifeline (from BasicInteractions, Fragments)” on page 500). We may also represent an ExecutionSpecification by a wider labeled rectangle, ..." It seems that "ExecutionOccurences" above is typo as this paragraph is about ExecutionSpecifications, and thus text should read as: "Notation ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline ..."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 7.3.39 PackageImport (from Kernel)

  • Key: UML23-6
  • Legacy Issue Number: 13137
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    There is some obvious copy/paste error: "Presentation options As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace..." This 7.3.39 section is about package import - not element import - so that sentence should look like: "As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace..."

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 7.3.12 Dependency (from Dependencies)

  • Key: UML23-5
  • Legacy Issue Number: 13136
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation to Figure 7.38 - An example of an instantiate dependency - states: "In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." (1) Logically and from the diagram itself, it should be opposite: CarFactory class has a dependency on the Car class. (2) Instantiate dependency does not mean that "Car class is an instance of the CarFactory class". That sentence most likely should read simply as "Car class is instantiated by the CarFactory class".

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

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

Val(MyCar.Interaction [SVWB

  • Key: UML23-11
  • Legacy Issue Number: 13250
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Constraint [2] implies that: "The name of the NamedElement referenced by signature must be the same as that of the Message" The point is that the syntax describe for the signature in the Notation section (p503) cannot ensure that the Message name will be unique inside its Namespace (i.e. its owning Interaction)

  • Reported: UML 2.2 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The message notation for message name was clarified in UML 2.5. The operation isDistinguishableFromwas overidden
    to always be True to avoid namespace problem. These changes address the concern raised in the issue.
    No change needed.
    Disposition: Closed - No Change

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

Section: 12.3.14 Figure 12.29 on page 320

  • Key: UML23-10
  • Legacy Issue Number: 13193
  • Status: closed  
  • Source: Mamezou Co.,Ltd. ( Kenichi Kobayashi)
  • Summary:

    Incorrect: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «precondition» and «postcondition». Correct: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «localPrecondition» and «localPostcondition».

  • Reported: UML 2.2 — Fri, 26 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is incorrect. The annotations on a CallBehaviorAction that are being described are supposed to show the
    pre- and postconditions of the called behavior, not the local pre- and postconditions. This is stated more explicitly in
    the corresponding wording in the UML 2.5 beta specification, in Subclause 16.3.4, under “Call Behavior Actions”.
    Disposition: Closed - No Change

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

Section: 14.3.24 MessageSort (from BasicInteractions)

  • Key: UML23-8
  • Legacy Issue Number: 13149
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "MessageSort is an enumeration of the following values: ... • asynchSignal - The message was generated by an asynchronous send action.createMessage - The message designating the creation of another lifeline object." The "createMessage" should be on a separate line: • asynchSignal - The message was generated by an asynchronous send action. • createMessage - The message designating the creation of another lifeline object.

  • Reported: UML 2.2 — Tue, 9 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Section: 14.3.3 CombinedFragment (from Fragments)

  • Key: UML23-7
  • Legacy Issue Number: 13148
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation for: "Presentation Options for “coregion area” ... This means that in a given “coregion” area of a Lifeline all the directly contained fragments are considered separate operands of a parallel combined fragment. See example in Figure 14.12." The "Figure 14.12 - Continuation" - seems to have no example of coregion as expected. Example of coregion could be found on "Figure 14.22 - Sequence Diagrams where two Lifelines refer to the same set of Parts", p.519.

  • Reported: UML 2.2 — Mon, 8 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

"description" section of the Behavior metaclass

  • Key: UML23-9
  • Legacy Issue Number: 13188
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In the "description" section of the Behavior metaclass, there is the following sentence: "A classifier behavior is always a definition of behavior and not an illustration". The consequences of this statement should be explained and especially its impact on the capability of using Interactions for that purpose. A constraint should be added to the specification of the BehavioredClassifier metaclass.

  • Reported: UML 2.2 — Mon, 22 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    In the UML 2.5 beta specification, this sentence still appears in Subclause 13.2.3, under the semantics of
    “Behaviored Classifiers”. However, it is not clear that the sentence is really necessary at all. In the same
    paragraph it says “For example, the classifierBehavior of a Collaboration (see sub clause 11.7) represents
    emergent behavior of all the parts. . . ” Certainly, it is common to use Interactions as Collaboration classifier-
    Behaviors, and it is not really clear what it means to “define” an emergent behavior anyway. The contrast
    of “definition of behavior not an illustration” thus seems methodological, and the sentence can be removed
    without changing the essential specification of classifierBehavior semantics.

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

Parameter isn't package (Heading 2 level)

  • Key: UML23-2
  • Legacy Issue Number: 13092
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Parameter isn't package (Heading 2 level), but class (need to be Heading 3 level under Heading 2 "9.1. BehavioralFeatures package")

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

Super package should import NamedElement from the Visibilities package, not Namespaces

  • Key: UML23-1
  • Legacy Issue Number: 13091
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.48 - The elements defined in the Super package As Classifier is associated to NamedElement's property of visibility, Super package should import NamedElement from the Visibilities package, not Namespaces

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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

description of Interaction provided by the Semantic section inconsistent

  • Key: UML23-12
  • Legacy Issue Number: 13253
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of Interaction provided by the Semantic section sounds good by itself but is widely inconsistent with the meta-model, according Attributes sections, Association sections and Figures 14.x. For instance: the Semantic section mentions "ordered sets of occurences" that can not be found in the meta-model. It does exist an ordered property in the association between Lifeline and OccurenceSpecification but: first it's not exactly the same thing, second the related property cannot be found anywhere in the meta-classes!... My global feeling is that the chapter 14 of the meta-model is not mature, very (too much?) complex and ambiguous.

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Semantics of interactions were clarified considerably.
    Disposition: Closed - No Change

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

Section: 14.3.20 Actors in Interactions

  • Key: UML23-4
  • Legacy Issue Number: 13134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is common to model interactions with actors, e.g. to show scenarios how actors interact with the system. For example in the context of a collaboration it is possible to model lifelines that represent system actors. However it is not possible that they receive messages in an interaction. According to constraint [2] in chapter 14.3.20 each message must correspond to an operation or signal. But it is not allowed to have actors with operations or receptions.

  • Reported: UML 2.2 — Tue, 2 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11068

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

Figure 9.20

  • Key: UML23-3
  • Legacy Issue Number: 13093
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.20 - The elements defined in the Expressions package Associations • operand: ValueSpecification[*] Specifies a sequence of operands. Subsets Element::ownedElement.

    {non-unique; ordered}
  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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