Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
UML22-1375 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.1 UML 2.1.2 Resolved closed
UML22-1367 Section: Composite Structures/Abstract syntax UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1141 Section: Activities: Modifications to the approved resolution of 10815 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1122 Diagram metaclass shall be introduced and shall be subclass of Element UML 2.1 UML 2.1.2 Resolved closed
UML22-1121 Setting structural features of a data type UML 2.1 UML 2.1.2 Resolved closed
UML22-1124 Figure 7.14: "Type" does not show its inheritance from "PackageableElement" UML 2.1 UML 2.1.2 Resolved closed
UML22-1123 ConnectorEnd shall have references to provided or required interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1134 constraining Classifiers UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1133 defaultClassifier of ClassifierTemplateParameter SysML 1.0 UML 2.1.2 Resolved closed
UML22-1129 Section: 9.3.11 p 182 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1128 Wrong notation description SysML 1.0 UML 2.1.2 Resolved closed
UML22-1127 Section: 9.3.8 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1126 page 449 chapter 13.3.24 (Signal (from Communications) SysML 1.0 UML 2.1.2 Resolved closed
UML22-1125 UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1136 Change multiplicity of ClassifierTemplateParameter role UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1135 Any ownedBehavior should be able to have AcceptEventAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1132 composite values SysML 1.0 UML 2.1.2 Resolved closed
UML22-1131 Section: 9 composite structures SysML 1.0 UML 2.1.2 Resolved closed
UML22-1130 "representation" SysML 1.0 UML 2.1.2 Resolved closed
UML22-1138 TimeEvent UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1137 Figure 14.5 - Messages. UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1140 Section: 7.3.7 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1139 Figures 9.4 identical to figure 9.3 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1120 Flowing data into decision input behaviors UML 2.1 UML 2.1.2 Resolved closed
UML22-1119 Section: Composite Structures UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1107 issue regarding required and provided interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1106 UML 2: Semantics of isOrdered need to be clarified UML 2.1 UML 2.1.2 Resolved closed
UML22-1118 Ptc/06-04-02/Pg 188 UML 2.1 UML 2.1.2 Resolved closed
UML22-1117 Section: 7.3.32 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1116 A notation for Trigger UML 2.1 UML 2.1.2 Resolved closed
UML22-1102 Section: Activities - Action semantic clarification UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1101 Section: Activities -StartClassifeirBehaviorAction and classifier behaviors UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1100 Section: Activities - isSingleExecution default UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1105 Profile Structure Diagrams are missing from Annex A SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1104 Missing inheritance in 9.3.12 SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1103 No default value specified for Generalization::isSubstitutable SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1115 consistent descriptions of semantics of event consumption needed UML 2.1 UML 2.1.2 Resolved closed
UML22-1114 section 13.3.2 – doc ptc/2006-04-02, v.2.1 UML 2.1 UML 2.1.2 Resolved closed
UML22-1113 Uses notation "Subsets Element::ownedElement" and similar UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1112 UML2: Behavior without a specification should not be a classifier behavior UML 2.1 UML 2.1.2 Resolved closed
UML22-1109 Figure 13.8 shows the wrong diagram UML 2.1 UML 2.1.2 Resolved closed
UML22-1108 Section: 13.3.25 UML 2.1 UML 2.1.2 Resolved closed
UML22-1111 Section: 13 SimpleTime UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1110 Section: 13.2 UML 2.1 UML 2.1.2 Resolved closed
UML22-1084 UML2: No notation for BehavioredClassifier::ownedTrigger UML 2.0 UML 2.1.2 Resolved closed
UML22-1083 UML 2/Templates -- single argument? UML 2.0 UML 2.1.2 Resolved closed
UML22-1082 Use the new 'dot' notation in examples UML 2.0 UML 2.1.2 Resolved closed
UML22-1099 Section: Activities - Join node edge constraint UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1098 Section: Activities - Offer ordering on joins UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1097 Section: Activities - Multiple activity parameters nodes for a single inout UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1088 A notation for Trigger SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1087 Section: 9.3.13 - connectors UML 2.1 UML 2.1.2 Resolved closed
UML22-1096 Section: Activities - Semantics of fork node wording UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1095 ReadLinkAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1094 Section: Activities - Weight notation UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1093 Section: Activities - Weight description UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1092 Section: Activities UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1091 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1090 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1089 Section: 9.2 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1086 Section: 13.3.24 Signal (from Communications) UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1085 page 467, Section 13.3.24 UML 2.0 UML 2.1.2 Resolved closed
UML22-1081 UML 2 Superstructure / CommonBehaviors / Incorrect types in text UML 2.0 UML 2.1.2 Resolved closed
UML22-1080 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.0 UML 2.1.2 Resolved closed
UML22-1079 Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember" UML 2.0 UML 2.1.2 Resolved closed
UML22-1078 Page: 161 UML 2.0 UML 2.1.2 Resolved closed
UML22-1057 Section: Appendix A: Diagrams UML 2.0 UML 2.1.2 Resolved closed
UML22-1056 Section 7.2.1 of ptc/04-10-14 UML 2.0 UML 2.1.2 Resolved closed
UML22-1055 Section: 7.3.36 Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1054 Section 8 Issue - Component Realization-Classifier multiplicity UML 2.0 UML 2.1.2 Resolved closed
UML22-1020 Section: Common Behaviors UML 2.0 UML 2.1.2 Resolved closed
UML22-1019 Section: Actions UML 2.0 UML 2.1.2 Resolved closed
UML22-1018 Section: Classes UML 2.0 UML 2.1.2 Resolved closed
UML22-1012 Section: 6.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1001 Section: 9.3.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1008 Core::Constructs::Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1007 Interaction::lifeline should be ordered UML 2.0 UML 2.1.2 Resolved closed
UML22-972 Notation of Attributes and Associations subsections RAS 2.2 UML 2.1.2 Resolved closed
UML22-971 Page: 330 UML 2.0 UML 2.1.2 Resolved closed
UML22-973 Section: 8.3.1 Page: 156 ff UML 2.0 UML 2.1.2 Resolved closed
UML22-959 CollaborationUse: Constraint 1, UML 2.0 UML 2.1.2 Resolved closed
UML22-962 Notation for connector end multiplicities. UML 2.0 UML 2.1.2 Resolved closed
UML22-947 The create stereotype on Usage dependency UML 2.0 UML 2.1.2 Resolved closed
UML22-946 Element to Constraint navigation UML 2.0 UML 2.1.2 Resolved closed
UML22-945 Disjointness should be independent of generalization UML 2.0 UML 2.1.2 Resolved closed
UML22-928 Section 12 (02) UML 1.4.2 UML 2.1.2 Resolved closed
UML22-822 Section: 8.3.1 UML 2.0 UML 2.1.2 Resolved closed
UML22-775 Section: 13.3.2 UML 2.0 UML 2.1.2 Resolved closed
UML22-735 Section: 12.3.14 UML 2.0 UML 2.1.2 Resolved closed
UML22-560 UML 2 Super Basic Interactions UML 1.4.2 UML 2.1.2 Resolved closed
UML22-562 An observed time value must be written into a structural feature UML 2.0 UML 2.1.2 Resolved closed
UML22-669 Section: 11.3.11 UML 2.0 UML 2.1.2 Resolved closed
UML22-581 underlined association name UML 2.0 UML 2.1.2 Resolved closed
UML22-712 Property string {bag} is redundant UML 2.0 UML 2.1.2 Resolved closed
UML22-593 Terminology Issue UML 1.4.2 UML 2.1.2 Resolved closed
UML22-535 Figure 78 UML 2.0 UML 2.1.2 Resolved closed
UML22-501 UML 2 Issue: definition of navigability UML 1.5 UML 2.1.2 Resolved closed
UML22-537 simple time model" in CommonBehavior UML 2.0 UML 2.1.2 Resolved closed
UML22-543 TimeObservationAction and DurationObservationAction UML 2.0 UML 2.1.2 Resolved closed
UML22-540 Interactions model sequences of events UML 2.0 UML 2.1.2 Resolved closed
UML22-476 Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace ) UML 1.4 UML 2.1.2 Resolved closed
UML22-475 Sending a signal after a delay XMI 1.3 UML 2.1.2 Resolved closed
UML22-512 UML 2 Infra/Metamodel/missing derivation indicators UML 1.5 UML 2.1.2 Resolved closed

Issues Descriptions

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1375
  • Legacy Issue Number: 9338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is an exact duplicate of issue 9337 Revised Text: N/A Disposition: Duplicate

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

Section: Composite Structures/Abstract syntax

  • Key: UML22-1367
  • Legacy Issue Number: 11503
  • Status: closed  
  • Source: Validas AG ( Reinhard Jeschull)
  • Summary:

    There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.

  • Reported: UML 2.1.1 — Thu, 20 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    withdrawn, this issue has been resolved

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section: Activities: Modifications to the approved resolution of 10815

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

    Modifications to the approved resolution of 10815. It should use a different keyword for decision input flows than the existing one for decision input behaviors. It should include an update to the notation figure, and to the keyword index.

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Revise the resolution to 10815 as suggested

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

Diagram metaclass shall be introduced and shall be subclass of Element

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

    Diagram metaclass shall be introduced and shall be subclass of Element, because every tool need to add Diagrams into packages (and uses hacks to do that) , Dependencies between diagrams is usable also. Stereotypes for diagrams are also used and even represented in DiagramFrame notation

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is definitely outside the scope of an RTF. However, it is also very much against one of the fundamental architectural principles of UML, that the abstract and concrete syntaxes are to be kept distinct. For instance, it should be possible to provide a UML concrete syntax that is completely textual and, hence, has no notion of diagram. Finally, the question of defining concrete syntaxes for MOF-based modeling languages and the issue of how these relate to the models themselves is being addressed by a separate RFP (the “Diagram Definition RFP”). Disposition: Closed, no change

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

Setting structural features of a data type

  • Key: UML22-1121
  • Legacy Issue Number: 10816
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background:

    Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

    Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

    Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

    In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

    Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

    Proposed resolution:

    Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

    (Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored – though it might sometimes be convenient even in this case for "chaining" actions on an object.)

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Figure 7.14: "Type" does not show its inheritance from "PackageableElement"

  • Key: UML22-1124
  • Legacy Issue Number: 10828
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, in figure 7.14, the "Type"
    metaclass is shown right below the "PackageableElement" metaclass,
    but without any inheritance arrow between them. This is not wrong,
    since a class diagram is not obliged to show all existing
    relaitonships.

    However, it would ease the understanding and be consistent if in this
    case, the inheritance arrow between these two metaclasses was shown
    in that figure.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This strikes me as a matter of taste; someone else might object to the generalization being shown in this diagram since it would clutter the diagram. Disposition: Closed, no change

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

ConnectorEnd shall have references to provided or required interfaces

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

    ConnectorEnd shall have references to provided or required interfaces. It helps to use assembly connectors in composite structure diagrams between parts and ports, connector will be able to display two compatible interfaces using "ball in socket" notation.
    Now it is impossible to implement that, because there are no references to interfaces.

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: There are two problems with this issue: (a) The ball-and-socket notation is unique to the components chapter, so this issue cannot be resolved in general for ConnectorEnd, but would have to be addressed specifically in the components chapter by introducing a subtype of ConnectorEnd. More importantly, though, (b) connectors do not have a semantic relation to interfaces. They connect ports or parts based on their compatability. The compatability between interfaces is a derived notation, and does not require metamodel support. Disposition: Closed, no change

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

constraining Classifiers

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

    It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
    For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.

    Resolution:

    17.5.8
    Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].

  • Reported: UML 2.1.1 — Mon, 6 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

defaultClassifier of ClassifierTemplateParameter

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

    Problem:

    "defaultClassifier" of ClassifierTemplateParameter shall redefine "default" of TemplateParameter and restrict type to Classifier.

    "default" shall be not accessible in ClassifierTemplateParameter.

    Resolution:

    Add

    {redefines default} to end of "defaultClassifier"property description in chapter 17.5.8 ClassifierTemplateParameter

    Add {redefines default}

    in metamodel association. Unfortunately diagram of abstract syntax of ClassifierTemplateParameter is not included into 17.5 Templates chapter.

    It should be added also.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Remove this redundant association

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

Section: 9.3.11 p 182

  • Key: UML22-1129
  • Legacy Issue Number: 11087
  • Status: closed  
  • Source: UPM ( Juan Pedro Silva)
  • Summary:

    All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.

  • Reported: UML 2.1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change

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

Wrong notation description

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

    "A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). ", BUT
    A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element

  • Reported: SysML 1.0 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    agreed

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

Section: 9.3.8

  • Key: UML22-1127
  • Legacy Issue Number: 11004
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog

  • Reported: UML 2.1.1 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change

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

page 449 chapter 13.3.24 (Signal (from Communications)

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

    there is a mistake in document formal/07-02-03 (UML Superstructure,
    v2.1.1) on page 449 chapter 13.3.24 (Signal (from Communications)). A
    Signal does not have an association to a signal of type Signal. It is
    probably a mix-up with SignalEvent

  • Reported: SysML 1.0 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Duplicate of issue 10960 Revised Text: N/A Disposition: Duplicate

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

UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3

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

    Figure 9.4 in formal/07-02-05 is a duplicate of figure 9-3. There should be a different diagram in place of figure 9-4 that shows the ports metamodel.

  • Reported: SysML 1.0 — Tue, 8 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

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

Change multiplicity of ClassifierTemplateParameter role

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

    Problem:
    The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters.

    Solution:
    Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Any ownedBehavior should be able to have AcceptEventAction

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

    Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.

  • Reported: UML 2.1.1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

composite values

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

    UML 2.1.1

    Problem:

    Duration value and TimeExpression value can't be owned by Duration or TimeExpression.

    Solution:

    Make Duration "expr" and TimeExpression "expr" properties composite.
    Change Figure 13.13 SimpleTime to reflect these ownerships.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 9 composite structures

  • Key: UML22-1131
  • Legacy Issue Number: 11164
  • Status: closed  
  • Source: Student at IFI UIO Norway ( Tormod Vaksvik Håvaldsrud)
  • Summary:

    Figure 9.3 : Is it riht that a connector can hold more than 2 ConnectorEnds? It is stated that it can hold: 2..*

  • Reported: SysML 1.0 — Fri, 20 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Yes, it is possible that a connector have more than 2 ends, in case it is an n-way connector. Disposition: Closed, no change

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

"representation"

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

    Classifier from Kernel packages has "representation" property of type InformationItem.
    Classifier from Collaborations package has "representation" property of type CollaborationUse.

    After package merge these properties conflict, one of them shall be renamed.

  • Reported: SysML 1.0 — Tue, 5 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

TimeEvent

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

    TimeEvent has "when" property for time value.

    13.3.27 TimeEvent

    • when: TimeExpression [1] Specifies the corresponding time deadline.

    However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.

    Model shall correspond to text, so Figure 13.13 shall be fixed.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Figure 14.5 - Messages.

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

    Problem:
    Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.

    Solution:
    Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.7

  • Key: UML22-1140
  • Legacy Issue Number: 11625
  • Status: closed  
  • Source: Volvo Technology Corporation ( Hans Blom)
  • Summary:

    nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.

  • Reported: UML 2.1.1 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate

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

Figures 9.4 identical to figure 9.3

  • Key: UML22-1139
  • Legacy Issue Number: 11524
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors

  • Reported: UML 2.1.1 — Fri, 28 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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

Flowing data into decision input behaviors

  • Key: UML22-1120
  • Legacy Issue Number: 10815
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 12.3.22, DecisionNode

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background

    There is no direct way to flow a supporting value into the decision input behavior of a decision node.

    Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

    Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior – but this seems awfully round about!

    Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

    Proposal

    Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Adopt as proposed

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

Section: Composite Structures

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

    Figure 9.4 duplicates 9.3

  • Reported: UML 2.1.1 — Sat, 10 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

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

issue regarding required and provided interfaces

  • Key: UML22-1107
  • Legacy Issue Number: 10354
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    There appears to be an issue with required and provided interfaces of Components in the UML2 Super Structure specification 2006-04-02 section 8.3.1., p.151 .

    In the OCL and the paragraph discussing required and provided interfaces there is no mention of inheriting provided or required interfaces from the supertypes of the component.
    Should we also consider required or provided interfaces of inherited ports?
    Should we also consider supertypes of realizing classifiers?

    The fact that Components don't consider supertypes is contrary to how Ports get required and provided interfaces on p187. Ports consider supertypes of the classifiers that type them when collecting required and provided interfaces.

  • Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

UML 2: Semantics of isOrdered need to be clarified

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

    Text should read something like:

    isOrdered : Boolean For a multivalued multiplicity, this
    attribute specifies whether the values in an instantiation of this
    element are maintained in the order that they where insertedsequentially
    ordered. Default is false.

  • Reported: UML 2.1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Actually, the original description is more general, since the ordering can be based on different ordering criteria, not just based on the order of insertion. Revised Text: N/A Disposition: Closed, no change

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

Ptc/06-04-02/Pg 188

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

    Where the spec currently says:

    “If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.”

    Consider whether this should in fact be defined as a semantic variation point.

  • Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The dynamic semantics of a port, when it is typed by a class, is already a semantic variation point. Most of the text above is an example, rather than a definition of behavior. The only normative text above is that the interaction point object will be an instance of the type of the port, if the port is typed by a class. That aspect is currently used by tools to give dynamic semantics to ports in a domain-specific manner. If such is not desired, the modeler can always close the semantic variation point as to the meaning of this construct to behave as desired, e.g., to reduce to the case where the type of the port is an interface. Disposition: Closed, no change

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

Section: 7.3.32

  • Key: UML22-1117
  • Legacy Issue Number: 10783
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".

  • Reported: UML 2.1.1 — Wed, 21 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

A notation for Trigger

  • Key: UML22-1116
  • Legacy Issue Number: 10777
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: There is no notation for trigger independent of its specific notation in a behavioral feature. (Note that this notation reduces to the specific notation for the associated event.) For example, in state machines, a notation is defined for representing triggers on states or transitions. Disposition: Closed, no change

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

Section: Activities - Action semantic clarification

  • Key: UML22-1102
  • Legacy Issue Number: 9875
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

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

Section: Activities -StartClassifeirBehaviorAction and classifier behaviors

  • Key: UML22-1101
  • Legacy Issue Number: 9872
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: Activities - isSingleExecution default

  • Key: UML22-1100
  • Legacy Issue Number: 9871
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change

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

Profile Structure Diagrams are missing from Annex A

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

    Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
    However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

    Proposed resolution:
    For clarity use the term 'Profile Diagram in section 18.4
    Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Missing inheritance in 9.3.12

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

    Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

  • Reported: SysML 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The submitter is correct; see revised text.

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

No default value specified for Generalization::isSubstitutable

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

    No default value specified for Generalization::isSubstitutable.
    This is the only Boolean attribute in the whole specification without a default value

  • Reported: SysML 1.0b1 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    For consistency and correctness, add a default value as the summary mentions.

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

consistent descriptions of semantics of event consumption needed

  • Key: UML22-1115
  • Legacy Issue Number: 10776
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    make consistent the descriptions of semantics of event consumption in section 13.3.4 and in section 13.3.2

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Section 13.3.2 is generic and does not define details of the semantics of event consumption. In fact it states that this is handled by BehavioredClassifier, section 13.3.4. I do not see any inconsistency between these two sections. Disposition: Closed, no change

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

section 13.3.2 – doc ptc/2006-04-02, v.2.1

  • Key: UML22-1114
  • Legacy Issue Number: 10775
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    Issue a: ) in behaviour description (section 13.3.2 – doc ptc/2006-04-02, v.2.1) precise more formally and explicitely which elements can have behaviors, and how the behavior context is defined.

    Typically clarification should say something like:

    • [A] Any subclasses of BehavioredClassifier (that is: Collaboration, Class, Actor, UseCase) can have a Behavior and its context is defined through the “context” association
    • [B] Any subclasses of BehavioralFeature (that is: xxx to be listed xxx) can have a Behavior and its context is defined through the “specification” association
    • [C] Additionally, Transitions and States can have a Behavior and its context is defined by the first BehavioredClassifier reached through their “owned” relation
    • [D] A Behavior can stand alone and be its own context (e.g. as equivalent to a C/C++ program)

    è Is it here necessary to add a context association from the Behavior to itself…? or should we consider that in this case it is always owned by a modelling element (eg a package) that defines its context… and should we explicitly define to which kind of element this can be considered and add these elements to the list of the [C] situation ?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The issue is somewhat confusing in its wording when it asks what “elements can have behaviors”. In one reading, only BehavioredClassifier can have behaviors. Probably the issue means to ask what “elements can own behaviors”. It would be not in the style of the UML specification to summarize in a central location such information, as this would conflict with the object-oriented style of the specification, or it would cause a maintenance difficulty. Behavior::context clearly defines how the context object is determined, independent of the type of behavior or its owner. Disposition: Closed, no change

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

Uses notation "Subsets Element::ownedElement" and similar

  • Key: UML22-1113
  • Legacy Issue Number: 10731
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.

  • Reported: UML 2.1.1 — Wed, 14 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: In one of the earlier revisions, the decision was made to use the “::” operator as a qualifier and not the “.” operator. Disposition: Closed, no change

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

UML2: Behavior without a specification should not be a classifier behavior

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

    Section 13.3.3, in the description of Behavior::specification says: "If a behavior does not have a specification, it is directly associated with a classifier (i.t., it is the behavior of the classifier as a whole."

    This appears to be incorrect. Assuming the "associated classifier" is the context Classifier: a Behavior might not be an ownedBehavior of any Classifier and has no context. For example, and Activity in a Package. Such a Behavior could not have a specification, but is not the behavior of any associated classifier.

    An ownedBehavior of a context Classifier can be explicitly designated as the behavior of the classifier using the BehavioredClassifier::classifierBehavior property. So there should be no need to define implicit classifier behaviors.

    Finally, a BehavioredClassifier might contain any number of ownedBehaviors that factor out reusable, private functions that are used in the implementations of other ownedBehaviors. These behaviors could be invoked using CallBehaviorActions and do not need specification operations. These behaviors would need a parameter for self if they need to refer to information in the context classifier.

  • Reported: UML 2.1 — Fri, 9 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue correctly points to that the text in Behavior::specification is misleading

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

Figure 13.8 shows the wrong diagram

  • Key: UML22-1109
  • Legacy Issue Number: 10469
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    diagrams for UML 2.1.1 - Figure 13.8 shows the wrong diagram

  • Reported: UML 2.1 — Wed, 22 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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

Section: 13.3.25

  • Key: UML22-1108
  • Legacy Issue Number: 10383
  • Status: closed  
  • Source: Bergson Technology ( Marc Hamilton)
  • Summary:

    SignalEvent notation interpretes Signal as an Operation. Details: A SignalEvent is associated to a Signal. The notation of SignalEvent contains an <assignment-specification> that consists of a list of <attr-name>. Quote: "<attr-name> is an implicit assignment of the corresponding parameter of the signal to...". Signal is however a Classifier and has no parameters. Either Signal should be an Operation or the notation of SignalEvent must utilize the explicit assignment of "corresponding attributes of the signal". In the latter case, this assignment should include the attribute name of the signal since the attributes of a Classifier are not ordered.

  • Reported: UML 2.1 — Fri, 6 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue is correct. What is meant was the attributes of the signal

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

Section: 13 SimpleTime

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

    What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue

  • Reported: UML 2.1.1 — Mon, 5 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change

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

Section: 13.2

  • Key: UML22-1110
  • Legacy Issue Number: 10513
  • Status: closed  
  • Source: UFRJ (Federal Uniersity of Rio de Janeiro) ( Felipe Gomes Dias)
  • Summary:

    In the UML Superstructure 2.1 available in the download section, the picture 13.8 is the same as the picture 13.7, in the page 463 of the document. The picture 13.8 should be explaining about the classes "Behavior" and "Constraint", as shown in the UML Superstructure 2.0 version.

  • Reported: UML 2.1 — Fri, 15 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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

UML2: No notation for BehavioredClassifier::ownedTrigger

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

    UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

    The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

    If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

    However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

    The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.

  • Reported: UML 2.0 — Wed, 1 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: A classifier declares its “willingness” to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change

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

UML 2/Templates -- single argument?

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

    A TemplateParameterSubstitution corresponds to exactly one template parameter, but the metamodel allows multiple actual arguments to be supplied for the parameter. There does not seem to be any compelling reason for multiple arguments to be provided for a single template parameter in a substitution (nor are the semantics of this clearl). Therefore, the multiplicity of TemplateParameterSubstitution::actual and Template ParameterSubstitution::ownedActual should be restricted to [1].

  • Reported: UML 2.0 — Fri, 24 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Use the new 'dot' notation in examples

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

    Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
    Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 9372

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

Section: Activities - Join node edge constraint

  • Key: UML22-1099
  • Legacy Issue Number: 9867
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says “If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.” Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change

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

Section: Activities - Offer ordering on joins

  • Key: UML22-1098
  • Legacy Issue Number: 9866
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: “Tokens are offered on the outgoing edge in the same order they were offered to the join.” Disposition: Closed, no change

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

Section: Activities - Multiple activity parameters nodes for a single inout

  • Key: UML22-1097
  • Legacy Issue Number: 9865
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.

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

A notation for Trigger

  • Key: UML22-1088
  • Legacy Issue Number: 9750
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: SysML 1.0b1 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This issue is an identical duplicate, submitted by the same author, as issue 10777

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

Section: 9.3.13 - connectors

  • Key: UML22-1087
  • Legacy Issue Number: 9619
  • Status: closed  
  • Source: Unisys ( Paul Koerber)
  • Summary:

    Connectors cannot be properly represented in a UML model using only constructs available in Compliance Level 1. The Connector class is part of the InternalStructures package which is in Level 1. The class that can own Connectors is StructuredClassifier through the ownedConnector association. This class is also in Level 1 but is abstract. All non-abstract subclasses of StructuredClassifer (such as Collaboration and EncapsulatedClassifier) are in Level 2. Because of this there is no class that can own Connector instances in a model that uses only Level 1 constructs. Therefore Connectors can’t be used in a Level 1 compliant model

  • Reported: UML 2.1 — Mon, 8 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This was a decision made in the design of UML 2. A tool that wants to offer internal structure with only compliance level 1 would have to at least define a profile that introduces a concrete subtype of StructuredClassifier. Disposition: Closed, no change

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

Section: Activities - Semantics of fork node wording

  • Key: UML22-1096
  • Legacy Issue Number: 9864
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: “Tokens arriving at a fork are duplicated across the outgoing edges.” The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change

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

ReadLinkAction

  • Key: UML22-1095
  • Legacy Issue Number: 9859
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

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

Section: Activities - Weight notation

  • Key: UML22-1094
  • Legacy Issue Number: 9857
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Correct text as below

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

Section: Activities - Weight description

  • Key: UML22-1093
  • Legacy Issue Number: 9856
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge

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

Section: Activities

  • Key: UML22-1092
  • Legacy Issue Number: 9855
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are “accessible” within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.

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

Section: 9.3.11

  • Key: UML22-1091
  • Legacy Issue Number: 9821
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Semantics of ports needs to be define with regard to interfaces having attributes and associations

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change

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

Section: 9.3.11

  • Key: UML22-1090
  • Legacy Issue Number: 9814
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that “clarification” is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.

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

Section: 9.2

  • Key: UML22-1089
  • Legacy Issue Number: 9813
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change

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

Section: 13.3.24 Signal (from Communications)

  • Key: UML22-1086
  • Legacy Issue Number: 9576
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Replace • signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal

  • Reported: UML 2.1.1 — Sun, 16 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

page 467, Section 13.3.24

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

    On page 467, Section 13.3.24, a Signal is said to have one association:

    signal : Signal[1] The signal that is associated with this event.

    I don't understand this. A signal is associated with another signal?
    Which one? Why? Could that be incorrect?

    Perhaps a cut-and-paste error, because on the same page, Section 13.3.25,
    a SignalEvent is said to have one association:

    signal : Signal[1] The specific signal that is associated with
    this event.

  • Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Duplicate of issue 9576

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

UML 2 Superstructure / CommonBehaviors / Incorrect types in text

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

    TimeConstraint::specification and DurationConstraint::specification properties are shown as having the wrong type in the text (the diagrams are OK). They should be TimeInterval and DurationInterval respectively.

  • Reported: UML 2.0 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This issue has been resolved in an earlier version of the specification. Disposition: Closed, no change

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

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1080
  • Legacy Issue Number: 9337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.0 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Key: UML22-1079
  • Legacy Issue Number: 9235
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was resolved in some previous revision. Disposition: Closed, no change

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

Page: 161

  • Key: UML22-1078
  • Legacy Issue Number: 9232
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 9.7: property "representation" subsets "collaborationUse" not "occurrence"? "Classifier" has no property named "occurrence"!

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has already been fixed in the current version of the specification. Disposition: Closed, no change

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

Section: Appendix A: Diagrams

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

    There's no diagram kind for deployment diagrams

  • Reported: UML 2.0 — Sat, 26 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section 7.2.1 of ptc/04-10-14

  • Key: UML22-1056
  • Legacy Issue Number: 9146
  • Status: closed  
  • Source: Red Hat ( John Verhaeg)
  • Summary:

    Page 13 of section 7.2.1 of the "Unified Modeling Language (UML) Specification: Infrastructure" (ptc/04-10-14) states:

    "There are minor differences in the design rationale for the other two packages."

    There are actually 4 packages being discussed, with the first being PrimitiveTypes. So, either "two" should be changed to "three" when referring to the "other" packages, or the two packages (amongst the "other" three being discussed) containing the "minor differences in design rationale" should be identified.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.36 Operation

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

    The BNF for the textual specification of an operation does not allow one to specify the multiplicity of an operation's return type. The current BNF is [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>]

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}’] It should allow the multiplicity to be specified in a manner similar to that for a property. For example: [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]

  • Reported: UML 2.0 — Tue, 8 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section 8 Issue - Component Realization-Classifier multiplicity

  • Key: UML22-1054
  • Legacy Issue Number: 9142
  • Status: closed  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    Issue: The multiplicity on the relationship from Realization to Classifier is 1. This seems wrong - it should be 1 or more.

    Rationale:
    A component realization consisting of only a single classifier would be very odd - although not impossible for a Hello World component perhaps.

  • Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: Common Behaviors

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

    In Description section of Common Behaviors, CallConcurrencyKind, how can "Multiple invocations of a behavioral feature" occuring simultaneously have a "first behavioral feature". Full text: "Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks."

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    While nit-picking, the issue submitter is correct

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

Section: Actions

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

    Figure 143 should show MultiplicityElement as being from Kernel (the MDL file accidentally used a copy).

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in a previous revision. Disposition: Closed, no change

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

Section: Classes

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

    Association.memberEnd should specialize Relationship:relatedElement. Programs accessing the repository with RelatedElement should get the elements being associated

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 6.5

  • Key: UML22-1012
  • Legacy Issue Number: 8987
  • Status: closed  
  • Source: Vtron ( Minghua Liu)
  • Summary:

    "“Part I. Structure” defines the static, structural constructs (e.g., classes, components, nodes artifacts) used in various structural diagrams, such as class diagrams, component diagrams, and deployment diagrams. Part II - “Behavior” specifies the dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. “Part ~~~~ I. Structure” defines auxiliary constructs ~~~~~~~~~~~~~~ (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods" The words underlined shoude be "Part III - Supplement.

  • Reported: UML 2.0 — Wed, 7 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Section: 9.3.5

  • Key: UML22-1001
  • Legacy Issue Number: 8946
  • Status: closed  
  • Source: Bergson TA ( Marc Hamilton)
  • Summary:

    A Property is a ConnectableElement, which currently is (should be?) a TypedElement. The Description in 9.3.5 however states: "A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. Note on p.84 states: "When used to specify the existence of an entity in a modelled system, an instance specification represents part of that system." In 9.3.12. it says:"When an instance of the containing classifier is created, a set of instances corresponding to its properties may be created either immediately or at some later time. These instances are instances of the classifier typing the property. A property specifies that a set of instances may exist; this set of instances is a subset of the total set of instances specified by the classifier typing the property. A part declares that an instance of this classifier may contain a set of instances by composition." So, the concepts must be related. I propose that a ConnectableElement is a specialization of InstanceSpecification, not just a TypedElement. Current problems in practise: A TypedElement is not a PackageableElement and it thus cannot be imported in some other namespace. This makes is hard to create orthogonal views of architectures (e.g. logical vs. execution) in which 'roles' (parts!) are shared. On the other hand, using InstanceSpecifications instead of "Parts" makes it impossible to refer them in interactions. Besides, the meaning of an InstanceSpecification in the context of a classifier is unclear in contrast to the Property.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The concept of connectable element is not an instance specification, so it would be a mistake to make it a specialization of InstanceSpecification. As the issue also points out, doing so would cause problems with interactions (where connectable elements are heavily used) as well as with their meaning. The issue really at hand appears to be that ConnectableElements are not packageable elements. The reason is that they have really no meaning outside of the context of the classifier they are owned by and thus would not be packaged separately. Disposition: Closed, no change

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

Core::Constructs::Operation

  • Key: UML22-1008
  • Legacy Issue Number: 8966
  • Status: closed  
  • Source: Vienna University of Technology ( Lorenz Froihofer)
  • Summary:

    This is a question or an issue for the UML 2.0 Superstructure and Infrastructure Revision Task Force (http://www.omg.org/issues/uml2-rtf.html An operation, e.g. Core::Constructs::Operation does no longer contain the isAbstract attribute (compared to UML version 1.5). I could not find a note in any of the classes within the inheritance hierarchy stating that this is a change to the 1.x versions. Was this attribute intentionally dropped for version 2.0? If yes, what is the suggested replacement?

  • Reported: UML 2.0 — Tue, 9 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This ability is still there, since the attribute isAbstract is inherited from BehavioralFeature (which is a superclass of Operation) as defined in CommonBehaviors. Disposition: Closed, no change

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

Interaction::lifeline should be ordered

  • Key: UML22-1007
  • Legacy Issue Number: 8964
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example).

  • Reported: UML 2.0 — Fri, 12 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Notation of Attributes and Associations subsections

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

    Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.

  • Reported: RAS 2.2 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are:
    „h the use of * instead of 0..* – simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open.
    „h The derivation specification already has another open issue.
    Revised Text: N/A Disposition: Closed, no change

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

Page: 330

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

    Typo in fig. 192: Association from BehavioralFeature to Parameterset: should be ownedMember instead of ownedmember (uppercase).

  • Reported: UML 2.0 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue refers to an older version of the specification. It is fixed in the meantime. Disposition: Closed, no change

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

Section: 8.3.1 Page: 156 ff

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

    Fig. 86, 87, and 89 have no dividing line between name compartment and internal view compartment

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This dividing line is optional. Revised Text: N/A Disposition: Closed, no change

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

CollaborationUse: Constraint 1,

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

    CollaborationUse: Constraint 1, allows parameters from different operations to be coordinated. Is that intended?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue appears to refer to an earlier version of the specification. It is impossible to identify in the current version what this issue concerns. Disposition: Closed, no change

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

Notation for connector end multiplicities.

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

    Notation for connector end multiplicities. Notation of ConnectorEnd, first paragraph says the multiplicities shown are the association multiplicities. What about the connector end multiplicities?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has been fixed in the current version of the specification. Disposition: Closed, no change

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

The create stereotype on Usage dependency

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

    The create stereotype on Usage dependency. The create stereotype on Usage dependency is defined in standard stereotypes (Table 25) and in retired stereotypes (Table 28). It is used in Figures 103 and 121.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in an earlier revision. The “create” stereotype is now defined in the table in appendix C section C.1. Disposition: Closed, no change

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

Element to Constraint navigation

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

    Element to Constraint navigation. The "constrainedElement" association between Constraint and Element is unidirectional from Constraint to Element. That means implementations are not required to provide efficient navigation from an element to the constraints on it. Can't see how an API could do without this.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 8020 Revised Text: N/A Disposition: Duplicate

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

Disjointness should be independent of generalization

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

    Disjointness is applicable to classes that are not specializations of the same class. It should be independent of generalization

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Same as issue 8014 Revised Text: N/A Disposition: Duplicate

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

Section 12 (02)

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

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

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

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

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

Section: 8.3.1

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

    Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation).

  • Reported: UML 2.0 — Sun, 27 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This line is optional. Revised Text: N/A Disposition: Closed, no change

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

Section: 13.3.2

  • Key: UML22-775
  • Legacy Issue Number: 8295
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters "that can be given" which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available.

  • Reported: UML 2.0 — Thu, 17 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    In the recent version of the specification, the specialization for context:BehavioredClassifier has already been added. The multiplicities mentioned above are all “” which is equivalent to “0..”. To correct the remaining mismatch between text and diagram:

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

Section: 12.3.14

  • Key: UML22-735
  • Legacy Issue Number: 8231
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For the Attributes, Associations, and Constraints sub-sections change "None" to "No new." This would be a good policy to follow for all "(as Specialized)" concepts where no new information is presented in the 'as Specialized" concept.

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

    Discussion: This was fixed as part of an editorial pass in a previous release. Revised Text: N/A Disposition: Closed, no change

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

UML 2 Super Basic Interactions

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

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

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

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

    Also BasicActions::SendSignalAction references Communications::Signal

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

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

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

An observed time value must be written into a structural feature

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

    TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily

  • Reported: UML 2.0 — Fri, 3 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change

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

Section: 11.3.11

  • Key: UML22-669
  • Legacy Issue Number: 8155
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of a previous copy-edit pass of the spec. Revised Text: N/A Disposition: Closed, no change

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

underlined association name

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

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

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

    The notation for instance specification seems clear that if an association name is shown on an instance specification, that this name would be underlined, see p.84: “It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.” (The diagram example in that section does not show the name.) Therefore, the above two figures are consistent with the notation defined for instance specifications. One could eliminate the association name, if so desired. Revised Text: Disposition: Closed, no change

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

Property string {bag} is redundant

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

    Property string

    {bag}

    is redundant. Use property string

    {nonunique}

    defined for MultiplicityElement instead

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

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

Terminology Issue

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

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

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

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

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

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

Figure 78

  • Key: UML22-535
  • Legacy Issue Number: 7246
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change

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

UML 2 Issue: definition of navigability

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

    PROBLEM STATEMENT
    There is no definition for navigability or navigation in the Spec. Other
    concepts of similar importance, such as visibility, multiplicity, etc., are
    defined in the Spec, so it is not clear why it should be assumed that this
    concept does not require a definition.

    PROPOSED SOLUTION
    Add definition in Section 4 (Terms and definitions): The navigability of a
    binary association specifies the ability of an instance of the source
    classifier to access the instances of the target classifier by means of the
    association instances (links) that connect them. Navigability is closely
    related to the possibility of sending messages through associations (a
    message cannot be sent through an association instance against its
    navigability, that is, navigability is required for sending messages through
    associations), but they remain nonetheless different concepts.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change

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

simple time model" in CommonBehavior

  • Key: UML22-537
  • Legacy Issue Number: 7303
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

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

TimeObservationAction and DurationObservationAction

  • Key: UML22-543
  • Legacy Issue Number: 7406
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

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

Interactions model sequences of events

  • Key: UML22-540
  • Legacy Issue Number: 7392
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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

Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )

  • Key: UML22-476
  • Legacy Issue Number: 5593
  • Status: closed  
  • Source: blomesystem ??????? ( Michael Zavyalov)
  • Summary:

    The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents)

    The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter !

    2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of «accessable» objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by «friend» Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors («contents» instead of «acessable»).

  • Reported: UML 1.4 — Sun, 25 Aug 2002 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change

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

Sending a signal after a delay

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

    Sending a signal after a delay

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).

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

UML 2 Infra/Metamodel/missing derivation indicators

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

    Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived.

  • Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

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

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