Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

  • Acronym: UML
  • Issues Count: 478
  • 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-21 UML 2 Issue: isUnique UML 1.5 UML 2.2 Resolved closed
UML22-457 New proposal for conjugate types for ports UML 2.1.2 UML 2.2 Resolved closed
UML22-459 Semantics of Ports in Components and CompositeStructures are incompatible UML 2.1.2 UML 2.2 Resolved closed
UML22-319 Explanation of Observation notation UML 2.1 UML 2.2 Resolved closed
UML22-307 Repr. of applied stereotypes and their properties insufficiently described UML 2.1 UML 2.2 Resolved closed
UML22-1380 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Duplicate or Merged closed
UML22-1372 Instance modeling does not take into account stereotypes properties UML 2.1.2 UML 2.2 Resolved closed
UML22-1371 Comments owned by Packages (02) UML 2.1.2 UML 2.2 Resolved closed
UML22-1370 Comments owned by Packages UML 2.1.2 UML 2.2 Resolved closed
UML22-1369 section 15.3.14 Transition :: Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-1368 Regarding the quote on p128 UML 2.1.2 UML 2.2 Resolved closed
UML22-458 UML 2.2 superstructure section 9.3.11 page 184: Port.isService UML 2.1.2 UML 2.2 Resolved closed
UML22-456 Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? UML 2.1.2 UML 2.2 Resolved closed
UML22-455 Inconsistency in Superstructure 2.2 p. 550 UML 2.1.2 UML 2.2 Resolved closed
UML22-454 InstanceSpecifications UML 2.1.2 UML 2.2 Resolved closed
UML22-453 specificMachine association should be changed to be type StateMachine UML 2.1.2 UML 2.2 Resolved closed
UML22-452 p269-p270 Constraint UML 2.1.2 UML 2.2 Resolved closed
UML22-451 operation allConnections UML 2.1.2 UML 2.2 Resolved closed
UML22-450 TYPO p.54 Additional Operations UML 2.1.2 UML 2.2 Resolved closed
UML22-446 Classifier has association end "attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-445 Typo 9.3.13 p190 UML 2.1.2 UML 2.2 Resolved closed
UML22-449 Metaclass Property is denoted in Interfaces Package on p.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-448 7.3.33 p100 UML 2.1.2 UML 2.2 Resolved closed
UML22-447 Property 7.3.44 p125 UML 2.1.2 UML 2.2 Resolved closed
UML22-444 7.3.44 additional operation P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-399 first paragraph of section 7.8 UML kernel UML 2.1.2 UML 2.2 Resolved closed
UML22-398 Section: 7.3.7 and 8.3.1 UML 2.1.2 UML 2.2 Resolved closed
UML22-401 Port UML 2.1.2 UML 2.2 Resolved closed
UML22-400 Section 14 Interaction UML 2.1.2 UML 2.2 Resolved closed
UML22-389 Section: 15.3.11/Notation UML 2.1.2 UML 2.2 Resolved closed
UML22-388 Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten UML 2.1.2 UML 2.2 Resolved closed
UML22-396 interpreting InstanceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-395 Figure showing an AssociationClass as a ternary association UML 2.1.2 UML 2.2 Resolved closed
UML22-391 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Resolved closed
UML22-390 Section: 13.3.3/ Changes from previous UML UML 2.1.2 UML 2.2 Resolved closed
UML22-394 Car dependency example UML 2.1.2 UML 2.2 Resolved closed
UML22-393 Section: 12.3.8/Generalizations UML 2.1.2 UML 2.2 Resolved closed
UML22-387 qualifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-397 Section: 15 StateMachines: doActivity and internal transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-392 Section: 7.3.10/Associations - insert reference UML 2.1.2 UML 2.2 Resolved closed
UML22-432 Unspecified constraint [1] on ActivityNode UML 2.1.2 UML 2.2 Resolved closed
UML22-431 constraint [4] on AcceptEventAction and unordered result:OutputPin property UML 2.1.2 UML 2.2 Resolved closed
UML22-434 figure 13.12 UML 2.1.2 UML 2.2 Resolved closed
UML22-433 Unspecified constraint [1] on ActivityNode (StructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-436 Clarification on use of Profiles. UML 2.1.2 UML 2.2 Resolved closed
UML22-435 Property – Additional Operations, page 127. UML 2.1.2 UML 2.2 Resolved closed
UML22-443 7.3.44 Property P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-442 18.3.8 Stereotype UML 2.1.2 UML 2.2 Resolved closed
UML22-430 Unspecified constraint [3] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-440 Typo P205 10.3.4 UML 2.1.2 UML 2.2 Resolved closed
UML22-439 On the table 2.3, page 8 UML 2.1.2 UML 2.2 Resolved closed
UML22-438 On the communication diagram in Fig 6.2 (second issue) UML 2.1.2 UML 2.2 Resolved closed
UML22-437 On the communication diagram in Fig 6.2 (P12) UML 2.1.2 UML 2.2 Resolved closed
UML22-441 7.3.11 DataType, P61 UML 2.1.2 UML 2.2 Resolved closed
UML22-383 UML 2.1.2:18.3.5 Package (from Profiles) UML 2.1.2 UML 2.2 Resolved closed
UML22-382 UML Super 2.1.2:Feature UML 2.1.2 UML 2.2 Resolved closed
UML22-384 A final node that returns to the caller but leaves alive any parallel flow UML 2.1.2 UML 2.2 Resolved closed
UML22-380 section '10.3.12 Property (from Nodes)' UML 2.1.2 UML 2.2 Resolved closed
UML22-379 PackageableElement (from Kernel), subsection: "Attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-386 CMOF file for UML2 does not have derived Associations marked as such UML 2.1.2 UML 2.2 Resolved closed
UML22-385 Section: 8.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-378 description of MessageOccurenceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-377 The list of literal described for the ennumeration MessageSort is not compl UML 2.1.2 UML 2.2 Resolved closed
UML22-381 undefined term 'Element::redefinedElement' occurs three times in standard UML 2.1.2 UML 2.2 Resolved closed
UML22-419 Section: 7.4 figure 7.1 missing dependency UML 2.1.2 UML 2.2 Resolved closed
UML22-418 UML2: Need a better mechanism for integrating UML2 Profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-421 Regression in XMI from UML 2.1.2 to UML 2.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-420 Section: 2.2-2.4 compliance level clarifiction needed UML 2.1.2 UML 2.2 Resolved closed
UML22-424 Unspecified constraint [1] on AcceptEventAction UML 2.1.2 UML 2.2 Resolved closed
UML22-423 Incorrect OCL expression for constraint [1] on BehavioredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-415 OCL 2.0 8.2 Real UML 2.1.2 UML 2.2 Resolved closed
UML22-414 UML2 issue regarding RedefinableTemplateSignature UML 2.1.2 UML 2.2 Resolved closed
UML22-427 Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-426 Unspecified constraint [2] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-429 Unspecified constraint [2] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-428 Unspecified constraint [1 on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-417 Section 7.3.50 "substitution" UML 2.1.2 UML 2.2 Resolved closed
UML22-416 Keyword ambiguity for DataType Section UML 2.1.2 UML 2.2 Resolved closed
UML22-425 Unspecified constraint [1] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-422 Section: 9.3.8 UML 2.1.2 UML 2.2 Resolved closed
UML22-406 Section 10.3.10 UML 2.1.1 UML 2.2 Resolved closed
UML22-405 definition of RedefinableElement::isLeaf UML 2.1.2 UML 2.2 Resolved closed
UML22-404 Behavior's parameter list UML 2.1.2 UML 2.2 Resolved closed
UML22-403 PackageMerge relationships UML 2.1.2 UML 2.2 Resolved closed
UML22-413 Section: 7.3.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-412 Section: 11.3.30,12.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-410 Section: 13.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-411 Section: 12.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-408 The behavior of an OpaqueExpression should itself be opaque UML 2.1.2 UML 2.2 Resolved closed
UML22-409 Section: 13.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-402 Classifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-407 Section: 7.3.35 UML 2.1.2 UML 2.2 Resolved closed
UML22-468 Packaging Issues with Stereotype Extension UML 2.1.2 UML 2.2 Resolved closed
UML22-467 inconsistency with how constraints are specified in UML and OCL UML 2.1.2 UML 2.2 Resolved closed
UML22-470 Allowing multiple Associations in a Package with the same name UML 2.1.2 UML 2.2 Resolved closed
UML22-469 P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo UML 2.1.2 UML 2.2 Resolved closed
UML22-472 Figure 18.2 (which describes the contents of the Profiles package) is currently misleading UML 2.1.2 UML 2.2 Resolved closed
UML22-466 ParameterableElement as a formal template parameter UML 2.1.2 UML 2.2 Resolved closed
UML22-465 UML. Clarify relationship of Substitution and InterfaceRealization UML 2.1.2 UML 2.2 Resolved closed
UML22-462 UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid UML 2.1.2 UML 2.2 Resolved closed
UML22-464 transitionkind Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-463 UML 2.2 figure 8.10 has arrows the wrong way around UML 2.1.2 UML 2.2 Resolved closed
UML22-461 UML2.2 Section 9.3.1 Presentation Options section UML 2.1.2 UML 2.2 Resolved closed
UML22-460 UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter UML 2.1.2 UML 2.2 Resolved closed
UML22-471 Figure 2.2 contains more than four packages, description referes to four packages UML 2.1.2 UML 2.2 Resolved closed
UML22-327 Behaviors Owned by State Machines UML 2.1 UML 2.2 Resolved closed
UML22-326 Section: 12.3.41 Streaming parameters for actions UML 2.1.1 UML 2.2 Resolved closed
UML22-316 Section: 13.3.24 UML 2.1.1 UML 2.2 Resolved closed
UML22-315 Section: 15.3.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-321 Wrong subsets UML 2.1 UML 2.2 Resolved closed
UML22-320 Section: 15.3.11 UML 2.1.1 UML 2.2 Resolved closed
UML22-328 information flow source and target UML 2.1 UML 2.2 Resolved closed
UML22-318 description of 14.3.24 MessageSort (from BasicInteractions) - typo UML 2.1 UML 2.2 Resolved closed
UML22-317 drawing a frame to represent Combined Fragment or an Interaction Occurrence UML 2.1 UML 2.2 Resolved closed
UML22-325 Section: 14 Interactions: Lifeline representing an actor UML 2.1.1 UML 2.2 Resolved closed
UML22-324 Section: 9 Composite Structures / Port notation UML 2.1.1 UML 2.2 Resolved closed
UML22-323 Section: 16.3.2 Classifier (from UseCases) UML 2.1.1 UML 2.2 Resolved closed
UML22-322 Section 18.3.1 UML 2.1 UML 2.2 Resolved closed
UML22-247 Section: Common Behavior - isReentrant should default to true UML 2.1.1 UML 2.2 Resolved closed
UML22-246 Actions on non-unique properties with location specified UML 2.1.1 UML 2.2 Resolved closed
UML22-243 Section: Actions - Output of read actions for no values UML 2.1.1 UML 2.2 Resolved closed
UML22-242 Section: Actions - InputPin semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-245 Section: Activities - Output pin semantics clarification UML 2.1.1 UML 2.2 Resolved closed
UML22-244 Section: Activities - ForkNode semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-241 Section: Activities - Preserving order of multiple tokens offered. UML 2.1.1 UML 2.2 Resolved closed
UML22-250 Bad cross reference for InterfaceRealization Notation UML 2.0 UML 2.2 Resolved closed
UML22-249 PrimitiveTypes access by UML (M1) models UML 2.0 UML 2.2 Resolved closed
UML22-253 Unclear which Property has aggregation UML 2.0 UML 2.2 Resolved closed
UML22-252 Move Property::isId from MOF to UML UML 2.0 UML 2.2 Resolved closed
UML22-248 Notation for stereotypes on Comments and other elements UML 2.0 UML 2.2 Resolved closed
UML22-251 text-diagram out of synch in Infrastructure 11.4.1 UML 2.0 UML 2.2 Resolved closed
UML22-254 Clarify isRequired UML 2.0 UML 2.2 Resolved closed
UML22-375 definition of 'isCompatibleWith' for ValueSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-374 formal definitions of 'isCompatibleWith' (pages 622, 647, 649) UML 2.1.2 UML 2.2 Resolved closed
UML22-373 association 'ownedTemplateSignature' of a Classifier UML 2.1.2 UML 2.2 Resolved closed
UML22-376 term 'templatedElement' not defined UML 2.1.2 UML 2.2 Resolved closed
UML22-309 Usage of "Element::ownedMember" UML 2.1 UML 2.2 Resolved closed
UML22-308 Consistency in description of ends owned by associations UML 2.1 UML 2.2 Resolved closed
UML22-306 Section: 12.3.30 UML 2.1.1 UML 2.2 Resolved closed
UML22-312 Section: 15.3.12 UML 2.1 UML 2.2 Resolved closed
UML22-311 "PackageableElement::visibility" uses "false" as default value UML 2.1 UML 2.2 Resolved closed
UML22-302 Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05 UML 2.1 UML 2.2 Resolved closed
UML22-301 Page: 155, 162 UML 2.1 UML 2.2 Resolved closed
UML22-305 Section: 17/17.5.7 UML 2.1.1 UML 2.2 Resolved closed
UML22-304 Port.provided:Interface UML 2.1 UML 2.2 Resolved closed
UML22-300 Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions) UML 2.1 UML 2.2 Resolved closed
UML22-299 Section: 12.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-303 UML2: Actor cannot have ownedAttributes UML 2.1 UML 2.2 Resolved closed
UML22-314 State Machines UML 2.1.1 UML 2.2 Resolved closed
UML22-313 Section: 18.3.8 UML 2.1.1 UML 2.2 Resolved closed
UML22-310 "Constraint::context" is marked as derived in the metaclass description UML 2.1 UML 2.2 Resolved closed
UML22-222 discrepancies between package dependencies and XMI file for Superstructure UML 2.1 UML 2.2 Resolved closed
UML22-224 Section: Figure 14.5 UML 2.1 UML 2.2 Resolved closed
UML22-223 Section: Appendix F UML 2.1 UML 2.2 Resolved closed
UML22-218 Section: 8.3.1 UML 2.1.1 UML 2.2 Resolved closed
UML22-217 General ordering cycles UML 2.0 UML 2.2 Resolved closed
UML22-215 What exactly is a state list? UML 2.0 UML 2.2 Resolved closed
UML22-214 Section: 9.14.2 UML 2.0 UML 2.2 Resolved closed
UML22-213 Section: 11.1.3 UML 2.0 UML 2.2 Resolved closed
UML22-212 Action inputs/outputs UML 2.0 UML 2.2 Resolved closed
UML22-225 Section: 7.3.44 UML 2.1.1 UML 2.2 Resolved closed
UML22-221 Section: 7.2 UML 2.1 UML 2.2 Resolved closed
UML22-220 Page: 64 & 112 UML 2.1.1 UML 2.2 Resolved closed
UML22-219 Completion event modeling UML 2.0 UML 2.2 Resolved closed
UML22-216 Editorial bug in 2.1 Superstructure Convenience document UML 2.0 UML 2.2 Resolved closed
UML22-183 7.3.4 Association Class UML 2.0 UML 2.2 Resolved closed
UML22-334 UML 2.2 scope statement UML 2.1 UML 2.2 Resolved closed
UML22-333 Property::isAttribute() query needs no argument UML 2.1 UML 2.2 Resolved closed
UML22-330 Section: 11.4 UML 2.1 UML 2.2 Resolved closed
UML22-329 Section: 11.4 Classifiers Diagram UML 2.1 UML 2.2 Resolved closed
UML22-340 Actor concept was indeed changed UML 2.1 UML 2.2 Resolved closed
UML22-339 Section: 13.3.3 UML 2.1 UML 2.2 Resolved closed
UML22-343 composite subsets UML 2.1 UML 2.2 Resolved closed
UML22-342 UML 2.1.2: Path names for CMOF files UML 2.1 UML 2.2 Resolved closed
UML22-332 Section: 7.3.21 figure 7.47 UML 2.1.1 UML 2.2 Resolved closed
UML22-331 Section: 7.3.21 UML 2.1.1 UML 2.2 Resolved closed
UML22-337 Section: Abstractions (02) UML 2.1 UML 2.2 Resolved closed
UML22-336 Section: Constructs UML 2.1 UML 2.2 Resolved closed
UML22-338 Namespace URI for Standard Profile(s) UML 2.1 UML 2.2 Resolved closed
UML22-335 Section: Abstractions UML 2.1 UML 2.2 Resolved closed
UML22-341 Section: 14.3.3 UML 2.1.1 UML 2.2 Resolved closed
UML22-264 Invalid mandatory compositions and associations UML 2.0 UML 2.2 Resolved closed
UML22-263 11.3.47 on StructuralFeatureAction (and related sections on subclasses) UML 2.0 UML 2.2 Resolved closed
UML22-262 Section: 9.16.1 UML 2.0 UML 2.2 Resolved closed
UML22-261 Section: 9.19.1 UML 2.0 UML 2.2 Resolved closed
UML22-258 Section: 9.12.1 UML 2.0 UML 2.2 Resolved closed
UML22-257 Merged Metam.:Property::class with redefinition of non-inherited property UML 2.0 UML 2.2 Resolved closed
UML22-265 Invalid redefinitions introduced into metamodel UML 2.1 UML 2.2 Resolved closed
UML22-267 Section: 13.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-266 Section: 11.3.5 UML 2.1 UML 2.2 Resolved closed
UML22-256 navigating from link to link ends UML 2.0 UML 2.2 Resolved closed
UML22-255 ExtensionEnd description refers to old use of navigability UML 2.0 UML 2.2 Resolved closed
UML22-260 Section: 9.10.3 UML 2.0 UML 2.2 Resolved closed
UML22-259 Section: 9.13 UML 2.0 UML 2.2 Resolved closed
UML22-270 Section: 7.3.3 UML 2.1.1 UML 2.2 Resolved closed
UML22-269 Figure 7.31 UML 2.1 UML 2.2 Resolved closed
UML22-268 Section: Annex C.1 UML 2.1.1 UML 2.2 Resolved closed
UML22-355 StructuredActivityNode [UML 2.1.1] UML 2.1.2 UML 2.2 Resolved closed
UML22-357 UML2 Issue - 'abstract' not listed in keyword Annex UML 2.1.2 UML 2.2 Resolved closed
UML22-356 UML2 issue: ProfileApplication treated as Import UML 2.1.2 UML 2.2 Resolved closed
UML22-348 context of Constraint UML 2.1.1 UML 2.2 Resolved closed
UML22-347 Section: 18.3.6 Profile (from Profiles) UML 2.1.1 UML 2.2 Resolved closed
UML22-354 Section: 7.3.33 UML 2.1.1 UML 2.2 Resolved closed
UML22-353 In section 7.3.12 Figure 7.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-351 Incorrect word renders sentence meaningless: Chap. 12.3.41 UML 2.1.1 UML 2.2 Resolved closed
UML22-350 The section titled "Changes from previous UML" is not complete UML 2.1.1 UML 2.2 Resolved closed
UML22-346 first constraint for CombinedFragment UML 2.1.1 UML 2.2 Resolved closed
UML22-345 Section: 12.3.1 AcceptEventAction UML 2.1.1 UML 2.2 Resolved closed
UML22-344 RedefinableTemplateSignature UML 2.1.1 UML 2.2 Resolved closed
UML22-352 ElementImport UML 2.1.1 UML 2.2 Resolved closed
UML22-349 UML 2.1.1 - fig 7.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-287 Section: 7 UML 2.1.1 UML 2.2 Resolved closed
UML22-286 Section: 15 UML 2.1 UML 2.2 Resolved closed
UML22-285 Section: 15 UML 2.0 UML 2.2 Resolved closed
UML22-295 UML 2.1 Spec, Interactions: 14.3.18 UML 2.1 UML 2.2 Resolved closed
UML22-294 UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse UML 2.1 UML 2.2 Resolved closed
UML22-293 A_outgoing_source and A_incoming_target should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-289 UML 2 Superstructure/Components/overly stringent constraints UML 2.1 UML 2.2 Resolved closed
UML22-288 AcceptCallAction has not operation UML 2.1 UML 2.2 Resolved closed
UML22-291 Section: 14.3.10 UML 2.0 UML 2.2 Resolved closed
UML22-290 Section: 14.3.14 UML 2.0 UML 2.2 Resolved closed
UML22-297 UML2: notation issue UML 2.1 UML 2.2 Resolved closed
UML22-296 Section: e. g. 12.2. page 287 UML 2.0 UML 2.2 Resolved closed
UML22-292 A_end_role should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-298 ReplyAction::replyValue type is incorrct UML 2.1 UML 2.2 Resolved closed
UML22-201 assembly connectors UML 2.0 UML 2.2 Resolved closed
UML22-200 New Issue on multiple guillemot pairs for same element UML 2.0 UML 2.2 Resolved closed
UML22-210 11.3.26 OpaqueAction UML 2.0 UML 2.2 Resolved closed
UML22-209 Definition of stereotype placement requires a name UML 2.0 UML 2.2 Resolved closed
UML22-206 the default for a Property should not be inconsistent with its type UML 2.0 UML 2.2 Resolved closed
UML22-205 Section: 7.3.10 UML 2.1.1 UML 2.2 Resolved closed
UML22-204 packagedElement UML 2.0 UML 2.2 Resolved closed
UML22-203 ptc/06-01-02:14.3.14, Notation UML 2.0 UML 2.2 Resolved closed
UML22-207 UML's support for null values and semantics is unclear UML 2.0 UML 2.2 Resolved closed
UML22-211 UML 2/ Super / SendSignalEvent erratum UML 2.0 UML 2.2 Resolved closed
UML22-199 Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter UML 2.0 UML 2.2 Resolved closed
UML22-208 "Property::lowerValue" is not a good name UML 2.0 UML 2.2 Resolved closed
UML22-202 Fig 7.14 UML 2.0 UML 2.2 Resolved closed
UML22-370 Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..." UML 2.1.1 UML 2.2 Resolved closed
UML22-369 Datatypes in UML profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-364 TemplateSignature / TemplateParameter / StructuredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-363 inability to specify ordering of messages connected to gates is problematic UML 2.1.2 UML 2.2 Resolved closed
UML22-372 The semantics of an assembly connector remains unspecified UML 2.1.2 UML 2.2 Resolved closed
UML22-371 Table 8.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-362 UML2: Missing ActionOutputPin UML 2.1.2 UML 2.2 Resolved closed
UML22-361 The spec needs to clarify the isConsistentWith() method for transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-367 paragraph on "deferred events" on page 552 UML 2.1.2 UML 2.2 Resolved closed
UML22-366 Section 14.3.19 UML 2.1.2 UML 2.2 Resolved closed
UML22-360 Figure 7.6 UML 2.1.2 UML 2.2 Resolved closed
UML22-359 Section: 12 UML 2.1.1 UML 2.2 Resolved closed
UML22-368 15.3.14: This paragraph refers to signal and change events UML 2.1.2 UML 2.2 Resolved closed
UML22-358 Section: 8.3.2 Connector UML 2.1.1 UML 2.2 Resolved closed
UML22-365 UML 2.1.1 Issue: Invalid association end in Figure 7.20 UML 2.1.2 UML 2.2 Resolved closed
UML22-275 Section: 17.5 UML 2.0 UML 2.2 Resolved closed
UML22-274 UML 2 state machines / entry point outgoing transitions UML 2.1 UML 2.2 Resolved closed
UML22-278 Page 60 of the pdf UML 2.1 UML 2.2 Resolved closed
UML22-277 UML2: Parameter::isException overlaps with Operation::raisedException UML 2.1 UML 2.2 Resolved closed
UML22-279 uml.xsd schema file in ptc/2006-04-05 is not correctly generated UML 2.1 UML 2.2 Resolved closed
UML22-284 UML2: ReadSelfAction with a context cannot access behavior owned attributes UML 2.1 UML 2.2 Resolved closed
UML22-283 Activity shape UML 2.0 UML 2.2 Resolved closed
UML22-273 12.3.27 ExpansionRegion UML 2.1.1 UML 2.2 Resolved closed
UML22-272 12.3.26 ExpansionNode UML 2.1.1 UML 2.2 Resolved closed
UML22-281 Meaning of Constraint visibility UML 2.1 UML 2.2 Resolved closed
UML22-280 Section: 7.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-276 Section: 12.3.2 Action UML 2.1.1 UML 2.2 Resolved closed
UML22-271 redefined properties UML 2.1 UML 2.2 Resolved closed
UML22-282 Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE- UML 2.1 UML 2.2 Resolved closed
UML22-240 Section: Activities - Pin ordering semantics UML 2.1.1 UML 2.2 Resolved closed
UML22-239 Section Activities: Default weight UML 2.1.1 UML 2.2 Resolved closed
UML22-235 text of specs and corresponding XMI specs should be clarified UML 2.0 UML 2.2 Resolved closed
UML22-234 UML 2: "isLeaf" UML 2.0 UML 2.2 Resolved closed
UML22-227 Section: 15.3.14 Transition UML 2.0 UML 2.2 Resolved closed
UML22-226 Section: 7 UML 2.1.1 UML 2.2 Resolved closed
UML22-238 Figure 7.4 invalid redefines UML 2.0 UML 2.2 Resolved closed
UML22-237 EnumerationLiteral should constrain InstanceSpecification UML 2.0 UML 2.2 Resolved closed
UML22-233 Stereotype attributes inherited from Class UML 2.0 UML 2.2 Resolved closed
UML22-232 Section: 12.3.8 UML 2.1.1 UML 2.2 Resolved closed
UML22-231 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-228 Notation (p 154, formal/05-07-04 ) UML 2.0 UML 2.2 Resolved closed
UML22-230 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-229 Section 10.2.1 "Class" (in Basic) UML 2.0 UML 2.2 Resolved closed
UML22-236 Section: 15.3.12 UML 2.1.1 UML 2.2 Resolved closed
UML22-192 Section: 7.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-191 AssociationClass is severely underspecified UML 2.0 UML 2.2 Resolved closed
UML22-190 Show an example of correct notation for the metamodel UML 2.0 UML 2.2 Resolved closed
UML22-185 Page: 338, 339 UML 2.1 UML 2.2 Resolved closed
UML22-184 Optional name attribute in NamedElement is misleading and insufficient UML 2.0 UML 2.2 Resolved closed
UML22-197 UML 2 Super / Components / connectors to interfaces UML 2.0 UML 2.2 Resolved closed
UML22-187 reference to Figure 12.87 missing UML 2.0 UML 2.2 Resolved closed
UML22-186 Section: 14.4 UML 2.0 UML 2.2 Resolved closed
UML22-194 No ObjectEvent corresponding to SendObjectAction UML 2.0 UML 2.2 Resolved closed
UML22-193 Fig 12.10 UML 2.0 UML 2.2 Resolved closed
UML22-189 Page: 625 UML 2.1 UML 2.2 Resolved closed
UML22-188 UML 2.1/Superstructure/ call triggers vs signal triggers UML 2.0 UML 2.2 Resolved closed
UML22-196 Section: 12.3.48 UML 2.1 UML 2.2 Resolved closed
UML22-198 UML 2.2 RTF issue - line styles for profiles UML 2.0 UML 2.2 Resolved closed
UML22-195 UML 2 Super / Composite Structure / ambiguous constraint UML 2.0 UML 2.2 Resolved closed
UML22-132 Section: 15.3.12 UML 2.0 UML 2.2 Resolved closed
UML22-131 Section: 11.5.1 DataType (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-141 event parameters UML 2.0 UML 2.2 Resolved closed
UML22-140 Meaning of navigability UML 1.4.2 UML 2.2 Resolved closed
UML22-130 Section: 11.3.13 TypedElement (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-129 Section: 11.3.6 Classifiers diagram UML 2.0 UML 2.2 Resolved closed
UML22-139 Page: 62 UML 2.0 UML 2.2 Resolved closed
UML22-138 page 134, Chapter 11.4.1 UML 1.4.2 UML 2.2 Resolved closed
UML22-137 page 97, Chapter 10.2.2. MultiplicityElement UML 1.4.2 UML 2.2 Resolved closed
UML22-125 Page: 129 UML 2.0 UML 2.2 Resolved closed
UML22-124 Page: 369/370 UML 2.0 UML 2.2 Resolved closed
UML22-136 Page: 157,162,163 UML 2.0 UML 2.2 Resolved closed
UML22-135 ObjectNode UML 1.4.2 UML 2.2 Resolved closed
UML22-127 9.1 BehavioralFeature package UML 2.0 UML 2.2 Resolved closed
UML22-126 Page: 532 UML 2.0 UML 2.2 Resolved closed
UML22-134 UseCase and Actors UML 1.4.2 UML 2.2 Resolved closed
UML22-133 Page: 423 UML 2.0 UML 2.2 Resolved closed
UML22-128 Section: 10.1 Types Diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-93 Figure 179 (Control nodes) UML 1.4.2 UML 2.2 Resolved closed
UML22-92 Section: D.4 UML 2.0 UML 2.2 Resolved closed
UML22-91 Section: 15.3.8 (second issue) UML 2.0 UML 2.2 Resolved closed
UML22-90 Section: 18.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-89 Section: 17 UML 2.0 UML 2.2 Resolved closed
UML22-102 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-101 Section: Actions UML 1.4.2 UML 2.2 Resolved closed
UML22-100 CombinedFragment Loop notation UML 1.4.2 UML 2.2 Resolved closed
UML22-99 Section: 7.3.36 UML 2.0 UML 2.2 Resolved closed
UML22-98 editorial in section 12 UML 1.4.2 UML 2.2 Resolved closed
UML22-97 UML 2 Different constraints for Property in Super and Infra UML 1.4.2 UML 2.2 Resolved closed
UML22-107 Activities UML 2.0 UML 2.2 Resolved closed
UML22-106 Clarify multiple inputs to expansion regions UML 2.0 UML 2.2 Resolved closed
UML22-105 DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode UML 2.0 UML 2.2 Resolved closed
UML22-87 Add constraints on conditional, loop, sequence to rule out node contents UML 2.0 UML 2.2 Resolved closed
UML22-86 Section: Activities, LoopNode UML 2.0 UML 2.2 Resolved closed
UML22-96 rewording isuse? UML 1.4.2 UML 2.2 Resolved closed
UML22-95 reword sentence UML 1.4.2 UML 2.2 Resolved closed
UML22-94 A test cannot be empty UML 1.4.2 UML 2.2 Resolved closed
UML22-104 Misleading statement about multiplicity in AssociationClass UML 2.0 UML 2.2 Resolved closed
UML22-103 Client/supplier on dependencies UML 2.0 UML 2.2 Resolved closed
UML22-88 Constrain conditional node to have body pins if there is a result pin. UML 2.0 UML 2.2 Resolved closed
UML22-2 Starting state machine UML 1.4 UML 2.2 Resolved closed
UML22-3 Starting a state machine UML 1.4 UML 2.2 Resolved closed
UML22-5 saying {nonunique} on one end of a binary association is meaningless UML 1.5 UML 2.2 Resolved closed
UML22-4 behaviour of the shallow history state and deep history state UML 1.5 UML 2.2 Resolved closed
UML22-173 On page 26, Figure 7.9 UML 2.0 UML 2.2 Resolved closed
UML22-172 choice of terminolgy for TransitionKind is non-intuitive UML 2.0 UML 2.2 Resolved closed
UML22-171 Section: 15.3.15 UML 2.0 UML 2.2 Resolved closed
UML22-170 Section 8.3.2 sub-section "Notation" starting on page 149 UML 2.0 UML 2.2 Resolved closed
UML22-169 inconsistency wrt UML2 classifier behavior UML 2.0 UML 2.2 Resolved closed
UML22-168 keyword, "buildcomponent", and a stereotype, "buildComponent" UML 2.0 UML 2.2 Resolved closed
UML22-182 Element and Comment in Basic UML 2.0 UML 2.2 Resolved closed
UML22-181 Description of Element UML 2.0 UML 2.2 Resolved closed
UML22-180 Unclear relationship between the Basic and Abstractions packages UML 2.0 UML 2.2 Resolved closed
UML22-179 XMI file: Core::Constructs::Operation::bodyCondition should have upper boun UML 2.0 UML 2.2 Resolved closed
UML22-178 /qualifiedName attribute missing on Core::Constructs::NamedElement UML 2.0 UML 2.2 Resolved closed
UML22-177 Operation::ownedParameter should be ordered in XMI? UML 2.0 UML 2.2 Resolved closed
UML22-176 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-175 constraints owned by these properties have no context UML 2.0 UML 2.2 Resolved closed
UML22-174 Operation should be a specialization of TypedElement and MultiplicityElemen UML 2.0 UML 2.2 Resolved closed
UML22-167 section, 12.3.27 ExpansionRegion(from ExtarStructureActivities UML 2.0 UML 2.2 Resolved closed
UML22-166 (merged) compliance levels L2 and L3 UML 2.0 UML 2.2 Resolved closed
UML22-165 (merged) compliance level L1 UML 2.0 UML 2.2 Resolved closed
UML22-164 Section: 14.3.20 Message (from BasicInteractions) UML 2.0 UML 2.2 Resolved closed
UML22-163 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-22 UML 2 Issue: Qualified pathnames UML 1.5 UML 2.2 Resolved closed
UML22-35 show object flow or interactions UML 1.5 UML 2.2 Resolved closed
UML22-34 UML 2 Super/Interactions/Need constraints that cover multiple Lifelines UML 1.5 UML 2.2 Resolved closed
UML22-24 ptc-03-09-15/Separate classification and generalization in Core::Basic UML 1.5 UML 2.2 Resolved closed
UML22-23 Ports in Protocol State Machines UML 1.5 UML 2.2 Resolved closed
UML22-33 StateMachine - Constraints UML 2.0 UML 2.2 Resolved closed
UML22-32 transtion UML 2.0 UML 2.2 Resolved closed
UML22-27 UML2 Super/Kernel Classes UML 1.5 UML 2.2 Resolved closed
UML22-26 UML Superstructure FTF : isRoot property disappeared UML 1.5 UML 2.2 Resolved closed
UML22-30 Inheritance of 'Enumerations' is not detailed UML 2.0 UML 2.2 Resolved closed
UML22-29 Part subtype UML 1.5 UML 2.2 Resolved closed
UML22-31 manage simultaneity of events UML 2.0 UML 2.2 Resolved closed
UML22-25 Federated models - UML2 issue UML 1.5 UML 2.2 Resolved closed
UML22-28 UML 2.0 Kernel Operations Diagram and Features Diagram and mdl UML 1.5 UML 2.2 Resolved closed
UML22-112 External exceptions. UML 2.0 UML 2.2 Resolved closed
UML22-111 Clarify which classifier or operation this is referring to UML 2.0 UML 2.2 Resolved closed
UML22-110 represents and occurrence keywords are switched UML 2.0 UML 2.2 Resolved closed
UML22-114 Events in Sequence diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-113 1. Deployment UML 1.4.2 UML 2.2 Resolved closed
UML22-116 Section: Action/Activity UML 2.0 UML 2.2 Resolved closed
UML22-115 Nested Nodes UML 1.4.2 UML 2.2 Resolved closed
UML22-119 Input tokens to LoopNodes should be destroyed when the loop is done UML 2.0 UML 2.2 Resolved closed
UML22-118 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-123 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-122 Section: 12.3.2 Action UML 2.0 UML 2.2 Resolved closed
UML22-109 In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec UML 2.0 UML 2.2 Resolved closed
UML22-108 StructuredActivityNode, Semantics, third paragraph, first sentence, UML 2.0 UML 2.2 Resolved closed
UML22-117 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-120 Return message UML 1.4.2 UML 2.2 Resolved closed
UML22-121 multiplicity should not be used/shown in an communicates association UML 1.4.2 UML 2.2 Resolved closed
UML22-76 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-75 Section: 14.3.18 UML 2.0 UML 2.2 Resolved closed
UML22-74 RemoveStructuralFeatureValueAction specification UML 2.0 UML 2.2 Resolved closed
UML22-73 inconsistent description UML 1.4.2 UML 2.2 Resolved closed
UML22-82 Decision node UML 2.0 UML 2.2 Resolved closed
UML22-81 Section: Actions UML 2.0 UML 2.2 Resolved closed
UML22-80 UML 2 Super / Kernel / invalid restriction in isConsistentWith() UML 1.4.2 UML 2.2 Resolved closed
UML22-67 namespace UML 1.4.2 UML 2.2 Resolved closed
UML22-66 Figure 89 on page 158 is incorrect UML 1.4.2 UML 2.2 Resolved closed
UML22-72 Section: 13.3.17 UML 2.0 UML 2.2 Resolved closed
UML22-71 Section: 13.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-70 UML2/Infra section 11.6.2/ Enumerations should not have attributes UML 1.4.2 UML 2.2 Resolved closed
UML22-79 Default values for ValueSpecification are not specified properly UML 1.4.2 UML 2.2 Resolved closed
UML22-78 Section 15 UML 2.0 UML 2.2 Resolved closed
UML22-77 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-69 Section: 12.3.40 UML 2.0 UML 2.2 Resolved closed
UML22-68 Section: 12.3.33 UML 2.0 UML 2.2 Resolved closed
UML22-84 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-83 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-65 Section: 10.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-85 Section: Interactions UML 2.0 UML 2.2 Resolved closed
UML22-155 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-154 Section: Classes (02) UML 2.0 UML 2.2 Resolved closed
UML22-153 Section: Common Behavior (02) UML 2.0 UML 2.2 Resolved closed
UML22-152 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-151 Property ownership must be consistent across association redefinitions UML 2.0 UML 2.2 Resolved closed
UML22-150 Missing notation for association classes UML 2.0 UML 2.2 Resolved closed
UML22-149 Page: 346-347 UML 2.0 UML 2.2 Resolved closed
UML22-148 Page: 255 UML 2.0 UML 2.2 Resolved closed
UML22-147 Behavior UML 2.0 UML 2.2 Resolved closed
UML22-144 UML 2 - Invalid subsetting of composition ends UML 2.0 UML 2.2 Resolved closed
UML22-143 UML 2 Super / Actions / Compliance Levels of Actions UML 2.0 UML 2.2 Resolved closed
UML22-162 Page: 53-55 UML 2.0 UML 2.2 Resolved closed
UML22-161 "ownedType" is not a valid element UML 2.0 UML 2.2 Resolved closed
UML22-158 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-157 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-156 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-146 UML SuperStructure - Inconsistency re State Machine terms UML 2.0 UML 2.2 Resolved closed
UML22-145 Section: 14.3.20 UML 2.0 UML 2.2 Resolved closed
UML22-160 Section: 16.3.3 UML 2.0 UML 2.2 Resolved closed
UML22-159 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-142 Page: 420 UML 2.0 UML 2.2 Resolved closed
UML22-36 Connector - "provided Port" and "required Port" not defined Constraint 1 UML 2.0 UML 2.2 Resolved closed
UML22-46 isComposite inconsistency in UML 2.0 and MOF 2.0 UML 1.4.2 UML 2.2 Resolved closed
UML22-48 Section: 9.14.1 UML 2.0 UML 2.2 Resolved closed
UML22-47 should retain Comment and its associations to Element UML 1.4.2 UML 2.2 Resolved closed
UML22-42 Notation sections for TimeObservation and DurationObservation UML 2.0 UML 2.2 Resolved closed
UML22-41 completion transitions UML 1.5 UML 2.2 Resolved closed
UML22-38 Connector - inconsistencies in Constraint[3] UML 2.0 UML 2.2 Resolved closed
UML22-37 Connector - inconsistencies in Constraint [2] UML 2.0 UML 2.2 Resolved closed
UML22-40 Connector - inconsistencies in Constraint[5] UML 2.0 UML 2.2 Resolved closed
UML22-39 Connector - inconsistencies in Constraint[4] UML 2.0 UML 2.2 Resolved closed
UML22-50 Presentation Options UML 2.0 UML 2.2 Resolved closed
UML22-49 Use case extension inconsistencies UML 1.4.2 UML 2.2 Resolved closed
UML22-45 AssociationClass UML 1.5 UML 2.2 Resolved closed
UML22-44 useless example on p.330, Figure 247 UML 2.0 UML 2.2 Resolved closed
UML22-43 Property defines an association "datatype" which is redundant UML 2.0 UML 2.2 Resolved closed
UML22-57 Multiple typos in ptc/04-10-02 UML 2.0 UML 2.2 Resolved closed
UML22-56 Clarify the differences between redefining element and redefined element. UML 2.0 UML 2.2 Resolved closed
UML22-55 All sections UML 2.0 UML 2.2 Resolved closed
UML22-54 ClassifierInState not supported in UML2.0 ? UML 1.4.2 UML 2.2 Resolved closed
UML22-64 Section: 9.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-63 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-51 constrainedElement direction UML 2.0 UML 2.2 Resolved closed
UML22-53 Association specialization semantics UML 1.4.2 UML 2.2 Resolved closed
UML22-52 Derived union notation UML 2.0 UML 2.2 Resolved closed
UML22-61 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-60 Section: 9.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-62 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-58 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-59 Section: 9.3.4 UML 2.0 UML 2.2 Resolved closed
UML22-7 Reentrancy 1 UML 1.5 UML 2.2 Resolved closed
UML22-6 Suspension Region UML 1.5 UML 2.2 Resolved closed
UML22-18 UML 2 Super / Missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-17 03-04-01 Chap 2 p. 112/Components: Different ways to wire components UML 1.5 UML 2.2 Resolved closed
UML22-20 UML 2 Issue: AssociationEnd UML 1.5 UML 2.2 Resolved closed
UML22-19 instantiations of Classifiers UML 1.5 UML 2.2 Resolved closed
UML22-15 Section 9.3.3 UML 1.5 UML 2.2 Resolved closed
UML22-14 UML 2 Super/Interactions/missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-10 UML 2 Super/Metamodel/redefinition and substitutability UML 1.5 UML 2.2 Resolved closed
UML22-9 Target pin notation UML 1.5 UML 2.2 Resolved closed
UML22-12 Notes versus curly braces UML 1.5 UML 2.2 Resolved closed
UML22-11 Activity OCL UML 1.5 UML 2.2 Resolved closed
UML22-16 UML2 super/ad-03-04-01/Derived attributes and associations UML 1.5 UML 2.2 Resolved closed
UML22-13 UML 2 super / Dependencies / improper subsetting? UML 1.5 UML 2.2 Resolved closed
UML22-8 State extension UML 1.5 UML 2.2 Resolved closed
UML22-1 Semantics of firing compound transitions still appears to be circular UML 1.3 UML 2.2 Resolved closed

Issues Descriptions

UML 2 Issue: isUnique

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

    PROBLEM STATEMENT
    "When one or more ends of the association have isUnique=false, it is
    possible to have several links associating the same set of instances."
    (Superstructure, p. 81)

    As Pierre-Alain Muller demonstrated in an informal conversation with Bran
    Selic during a lunch in San Francisco in the last UML Conference (I also was
    taking part in that conversation), isUnique must have the same value for all
    ends in an association.

    This has implications, for example, for the property strings that can be
    placed near the association ends (

    {ordered}

    ,

    {bag}

    ,

    {seq}

    ). According to the
    table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
    the opposite end must be a Set or an OrderedSet, too; and if one end is a
    Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

    PROPOSED SOLUTION
    Explain this in the Spec.

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

    This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/
    trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an
    association end is derived from the links that instantiate the association as modified by the isUnique marking.
    So, even if there are two links targeting an instance in the extent of the association, if the property is
    marked as unique then there will only be one instance in the collection. This interpretation allows there to
    be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation
    is in fact the intended interpretation of the current spec, and should be clarified as such.
    Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in
    contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass
    that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is
    clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to
    give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5.
    This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently
    nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it
    once, then that should be legal, even though the size of the value of B is larger than that of A.
    The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use
    of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified
    definition.
    This also resolves issue 5977.

  • Updated: Mon, 9 Jan 2023 12:17 GMT

New proposal for conjugate types for ports

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

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

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

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

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

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

    Is this acceptable?

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

    This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
    But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
    For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
    This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
    However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
    Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Semantics of Ports in Components and CompositeStructures are incompatible

  • Key: UML22-459
  • Legacy Issue Number: 13140
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as “interaction point objects” typed by the type of the port. Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply. The sentence from 8.3.1 “The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time” clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects. These contradictions should be resolved

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted.
    The remainder of the issue can be handled by some explanatory text as proposed below.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Explanation of Observation notation

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

    UML2 Superstructure 2.1.1:Interactions

    In Fig 14.26 there are various time annotations shown which relate to the Simple Time package.

    The notation sections for TimeObservation and DurationObservation read thus:

    TimeObservation: “A time observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    DurationObservation: “A duration observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    However the notations in Figure 14.26 look like this:

    TimeObservation: “t=now”

    DurationObservation: “d=duration”

    I don’t see how the example notation is consistent with the notation descriptions

  • Reported: UML 2.1 — Fri, 27 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 17841

  • Updated: Sun, 11 Jun 2017 11:36 GMT

Repr. of applied stereotypes and their properties insufficiently described

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

    Issue: UML representation of applied stereotypes and their properties is
    insufficiently described
    Nature: Clarification
    Severity: Significant
    Summary:

    1. In the Superstructure spec 2.1.1, it is not clearly stated what an
    applied stereotype is in terms of metaclasses. The spec talks
    about "instance of a Stereotype", but it fails to sufficiently
    clarify the so-called meta-level crossing, i.e. the fact that an
    instance of the Stereotype metaclass at the same time is a new
    metaclass. The description of Stereotype says in the Semantics
    section: "An instance “S” of Stereotype is a kind of (meta) class
    ". I think "a kind of" as well as putting "(meta)" in parenthesis
    is confusing. I suggest to say: "An instance “S” of the Stereotype
    metaclass is itself a metaclass.". Also, the text currently does
    not describe what the name and particularly the namespace of the
    metaclass corresponding to the instance of the Stereotype
    metaclass would be. Because of the current uncertainty, UML tools
    have taken different (and incompatible) interpretations on how an
    applied stereotype should be represented in terms of UML
    metaclasses.

    2. It is not described currently how any property values of applied
    stereotypes are represented in terms of instances of metaclasses.
    When looking at generated XMI, it seems that this representation
    is quite different from Property metaclass instances that are
    ownedAttributes of user model classes, so there is a need to
    clarify this. Because of the current uncertainty, UML tools have
    taken different (and incompatible) interpretations on how these
    values should be represented in terms of UML

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

    No Data Available

  • Updated: Mon, 11 May 2015 23:49 GMT

Section: 7.3.10/Associations

  • Key: UML22-1380
  • Legacy Issue Number: 12383
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain why constrainedElement has to be an ordered set and not a set

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.2
  • Disposition Summary:

    Duplicate

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

Instance modeling does not take into account stereotypes properties

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

    Instance modeling does not take into account stereotypes properties.

    Assume I create a stereotype that I apply to some Class. That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class.

    I believe I should be able to create a slot for 'p' and assign some value to it.

    Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification. The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

  • Reported: UML 2.1.2 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    withdrawn by issue submitter

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

Comments owned by Packages (02)

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

    Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Comments owned by Packages

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

    A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is not quite right to say that “a package can only own packageable elements”. The spec only says that “Only packageable elements can be owned members of a package.” That is, any owned members of the package, considered as a namespace, must be packageable elements – this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.

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

section 15.3.14 Transition :: Constraints

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

    Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732 section 15.3.14 Transition :: Constraints)):
    [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()

    This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers. As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Regarding the quote on p128

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

    In the 2.1.1 specification (070205):

    Regarding the quote on p128:
    "All redefinitions should be made explicit with the use of a

    {redefines <x>}

    property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other."

    I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model.
    This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts.

    Two features of the same kind defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2.2 superstructure section 9.3.11 page 184: Port.isService

  • Key: UML22-458
  • Legacy Issue Number: 13083
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition of Port.isService appears to be redundant with the concept of public/private visibility. Is it valid for an isService=true Port to be private, or for an isService=false Port to be public? What about protected and package visibility for Ports?

  • Reported: UML 2.1.2 — Mon, 17 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    From Bran Selic:
    Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific – in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside.

    It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering.

    If you remove this capability, you will certainly invalidate a lot of models based on this notion.

    Revised Text:
    None.

    Disposition: Closed, no change.

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

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"?

  • Key: UML22-456
  • Legacy Issue Number: 12985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

  • Reported: UML 2.1.2 — Thu, 23 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.

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

Inconsistency in Superstructure 2.2 p. 550

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

    There seems to be an inconsistency in the spec.

    Supersturcture v2.2 ptc/2008-05-xx
    p 550

    The spec mentions:
    A state with isSimple=true is said to be a simple state. A simple state does not have any regions **and it does not refer to any submachine state machine.**

    It also says in the constraints section ( constraint [4] ) :
    A simple state is a state without any regions. isSimple = region.isEmpty()

    The constraint seems to be missing the part about not refering to any submachine state machine.

  • Reported: UML 2.1.2 — Tue, 7 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The submitter is correct. Add the missing constraint to the isSimple() operation of State by adding that the
    isSubmachineState attribute has to be false

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

InstanceSpecifications

  • Key: UML22-454
  • Legacy Issue Number: 12912
  • Status: closed  
  • Source: University of Kassel ( Carsten Reckord)
  • Summary:

    To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png

  • Reported: UML 2.1.2 — Mon, 6 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 9961

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

specificMachine association should be changed to be type StateMachine

  • Key: UML22-453
  • Legacy Issue Number: 12855
  • Status: closed  
  • Source: NASA ( Alexander Murray)
  • Summary:

    The specificMachine association of metaclass ProtocolConformance is of type ProtocolStateMachine, which would seem to prohibit the specificMachine from being a BehaviorStateMachines::StateMachine. However, the text sections of section 15.3.5, including the Description and Semantics sections, are very clear that the conforming StateMachine may be a BehavioralStateMachine::StateMachine, which make sense. So the specificMachine association should be changed to be type StateMachine. Also, Figure 15.5 should be similarly changed.

  • Reported: UML 2.1.2 — Wed, 17 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The protocol conformance relationship was explicitly intended to model relationships between protocol state machines
    (this is clearly stated in the spec). It is unclear what would be the precise meaning of that type of relationship between
    different kinds of state machines, but, whatever it might be, it is likely to be complex, dealing with issues such as
    behavioral equivalence. This is still an open research topic with many different approaches and not something one
    should standardize as yet.
    Disposition: Closed - No Change

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

p269-p270 Constraint

  • Key: UML22-452
  • Legacy Issue Number: 12851
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
    270 UML Superstructure Specification, v2.2
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [4] The open end must be navigable.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [5] Visibility of the open end must allow access to the object performing the action.
    let host : Classifier = self.context in
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 6462 (resolved in UML 2.3) for disposition

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

operation allConnections

  • Key: UML22-451
  • Legacy Issue Number: 12850
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1)>[1] The operation allConnections results in the set of all AssociationEnds of the Association.

    "AssociationEnds" is "Properties", isn't it?

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

TYPO p.54 Additional Operations

  • Key: UML22-450
  • Legacy Issue Number: 12848
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query allParents() gives all of the direct and indirect
    ancestors of a generalized Classifier.
    Classifier::allParents(): Set(Classifier);
    allParents = self.parents()>union(self.parents()>collect(p |
    p.allParents())

    It seems to be lack of the last parenthesis.

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed, there is a missing closing parenthesis.

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

Classifier has association end "attribute"

  • Key: UML22-446
  • Legacy Issue Number: 12844
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Classifier has association end "attribute". The association should have the opposite
    side of "attribute". Such association end should be "Classifier::attribute".
    In the case of "Class", "Datatype", "StructuredClassider" (however, there is a typo),
    "Signal", such element have "Classifier::attribute" association end.
    However, Interface and Artifact don't have such association end.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Typo 9.3.13 p190

  • Key: UML22-445
  • Legacy Issue Number: 12843
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    ownedAttribute : Property[0..*]
    References the properties owned by the classifier. (Substes StructuredClassifier:: role,
    Classifier.attribute...
    ~~~~~~~~~~~~~~~~~~~~
    Classifier::attribute?

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Metaclass Property is denoted in Interfaces Package on p.36

  • Key: UML22-449
  • Legacy Issue Number: 12847
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    However, according to the class description for Property,
    Property is "from Kernel and AssociationClass".
    Property is defined in Interfaces Package.
    Therefore, it seems Property is "from Kernel, Interfaces and AssociationClass".

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

7.3.33 p100

  • Key: UML22-448
  • Legacy Issue Number: 12846
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "clientDependency: Dependency[*]
    Indicates the dependencies that reference the client."

    This explanations is described in "Attribute" clause, not Associations" of NemedElment.
    It seems to be in incorrect clause.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Property 7.3.44 p125

  • Key: UML22-447
  • Legacy Issue Number: 12845
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "A property related to a classifier by ownedAttribute represents an attribute..."
    and in its semantics
    "When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of
    the class or data type."

    However, in the case of "StructuredClassifier", "Signal", "Artifact",
    "Interface".
    "attribute" is not necessary

    The specification should modified as followings.

    p125 L7:
    "A property related to a classifier by attribute represents an attribute,"

    and

    p128 L17
    "When a property is owned by a classifier other than an association, then it represents an attribute of the classifier."

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is not correct. All attributes are in fact owned via a property called ownedAttribute, different in each case,
    but this is true for all subclasses of Classifier including Interface, Signal, Artifact, etc. So the text is correct.
    Disposition: Closed - No Change

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

7.3.44 additional operation P128

  • Key: UML22-444
  • Legacy Issue Number: 12842
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [4]The query isAttribute() is true if the Property is defined as an attribute of
    some classifier.
    context Property::isAttribute(p : Property) : Boolean
    post : result = Classifier.allInstances->exists(C|c.attribute->includes(p))

    This OCL means there is at least one element of Property.
    Then, it is better to represent as "not classifier->isEmpty, not "Classifer.allinstances"
    like opertation [3]. It is better to represent similar style in a same block.

    This issue relates to aleady mentioned issue(Issue 11120). However, it is not exactly same.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11120

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

first paragraph of section 7.8 UML kernel

  • Key: UML22-399
  • Legacy Issue Number: 12436
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The first paragraph of section 7.8 suggests that the UML kernel is the merge of Core::Abstractions packages. To obtain Classifier in the UML kernel, we would have to merge Classifiers, Super and Generalizations from Core::Abstractions. How is this possible given that: a) there are no generalization relationships among Classifier metaclasses in these Abstractions packages b) there are two matching operations:

    {Super,Generalizations}

    ::Classifier::parents (a) means that Generalizations::Classifier::parents cannot redefine Super::Classifier::parents. Even if there were a generalization, the resulting merged model would be ill-formed because it would include a generalization self-loop. (b) means that the merge is ill-formed because it violates constraint #4 defined in the general package merge rules in 11.9.3 (p. 164) POSSIBLE WORKAROUND: - split Core::Abstractions::Super in two packages: Super and SuperParents which only defines Classifier::parents - ditto for Core::Abstractions::Generalizations - if Super is to be merged but Generalizations isn't, then merge SuperParents as well. - if both Super and Generalizations are to be merged, then merge GeneralizationsParent but not SuperParents This is a kludge but that's the only short-term workaround I can find for this bug at this time.

  • Reported: UML 2.1.2 — Sun, 11 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 7.3.7 and 8.3.1

  • Key: UML22-398
  • Legacy Issue Number: 12432
  • Status: closed  
  • Source: THALES ( Sebastien Madelenat)
  • Summary:

    page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

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

    This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership.
    We can resolve these by adding two constraints to Component:
    · A Component's nestedClassifier collection is always empty.
    · If a Component is nested in a Class, then its packagedElement collection is empty.

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

Port

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

    for Port, there is a constraint that say :

    [1] The required interfaces of a port must be provided by elements to which the port is connected.

    I believe that ports are connected by delegation connector, this constraint may not be checked!

    Am I right?

  • Reported: UML 2.1.2 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.

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

Section 14 Interaction

  • Key: UML22-400
  • Legacy Issue Number: 12455
  • Status: closed  
  • Source: Research Group Software Construction, RWTH Aachen ( Alexander Nyßen)
  • Summary:

    As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

  • Reported: UML 2.1.2 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Changing this cardinality in the metamodel is a breaking change, and is unnessary.
    It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
    .something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
    to be added later.
    There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
    type of the ConnectableElement associated with a Lifeline.
    Disposition: Closed - No Change

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

Section: 15.3.11/Notation

  • Key: UML22-389
  • Legacy Issue Number: 12380
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    In chapter 15.3.12 (p. 568) the keyword "final" is informally introduced for states: "the states VerifyCard, OutOfService, and VerifyTransaction in the ATM state machine in Figure 15.42 have been specified as

    {final}" This should be mentioned in capter 15.3.11 (State (from BehaviorStateMachines, ProtocolStateMachines)) in section "Notation". Suggestion: "A state that is a leaf (i.e. isLeaf=TURE) can be shown using the keyword {final}

    after or below the name of the State."

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. The “final” keyword should be explained in the section describing the notation for state machines
    and not in the examples paragraph, it should also be added to the list of keywords in Table C.1 in the
    appendix

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

Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten

  • Key: UML22-388
  • Legacy Issue Number: 12379
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Section 11.3.25 gives the definition of MultiplicityElement::compatibleWith as: compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.includesCardinality implies other.includesCardinality) While technically correct, this may be a little impractical for any OCL interpreting tool. I think an alternative, that simply uses the upper and lower bounds, would be: compatibleWith(other) = other.includesMultiplicity(self)

  • Reported: UML 2.1.2 — Tue, 15 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

interpreting InstanceSpecification

  • Key: UML22-396
  • Legacy Issue Number: 12427
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    Various readers are interpreting InstanceSpecification differently. One interpretation is that a particular InstanceSpecification specifies a particular instance. A second interpretation is that a particular InstanceSpecification may be used to specify more than one instance. I prefer the second interpretation. This is supported by the Note at the bottom of page 83 that refers to "... such structures."

  • Reported: UML 2.1.2 — Fri, 2 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is clear from this sentence: “As an InstanceSpecification may only partially determine the properties of an
    individual, there may actually be multiple individuals in the modeled system that satisfy the requirements
    of the InstanceSpecification.”
    But some of the earlier text seems to imply different - this text is changed.

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

Figure showing an AssociationClass as a ternary association

  • Key: UML22-395
  • Legacy Issue Number: 12406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please insert a figure showing an AssociationClass that is a ternary association to make clear whether the dashed line is to be connected to a line or the diamond. (Use can re-use figure 7.21 on page 44).

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8974

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

Section: 7.3.10/Associations

  • Key: UML22-391
  • Legacy Issue Number: 12382
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain constrainedElement has to be an ordered set and not a set.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The order of the constrainedElements may make a significant difference on the meaning of the constraint. For instance,
    a constraint on two numeric elementsmay require that one is less than the other, or a constraint on two sets may require
    one to be a subset of the other.
    Disposition: Closed - No Change

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

Section: 13.3.3/ Changes from previous UML

  • Key: UML22-390
  • Legacy Issue Number: 12381
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Chapter 13.3.3, section “Changes from previous UML“: “The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.” RedefinableElement does not have the property isRoot.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Car dependency example

  • Key: UML22-394
  • Legacy Issue Number: 12405
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The car dependency example on page 63 of the UML Super Structure Specification appears wrong to me. The description indicates to me that the arrow should be going from the car to the carfactory not the other way around as depicted.

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11489

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

Section: 12.3.8/Generalizations

  • Key: UML22-393
  • Legacy Issue Number: 12385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ActivityNode need not specialize “NamedElement (from Kernel, Dependencies)” because is specializes ““RedefinableElement (from Kernel)” which in turn specializes “NamedElement (from Kernel, Dependencies)”.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

qualifiers

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

    Are qualifiers displayed at opposite end of association than role name (or multiplicity) or near the role name (or multiplicity)?

    E.g. composition diamond is displayed at opposite end, multiplicity value – at the same end. How about qualifiers?

    UML 2.1.2 page 124:

    qualifier : Property [*] An optional list of ordered qualifier attributes for the end.

    Notation (page 128):

    The qualifier is attached to the source end of the association.

    What is the “source of the association” ???

    Look at figure from UML spec (first sample):

    Are these qualifiers owned in association end typed by Bank or Person?

  • Reported: UML 2.1.2 — Thu, 20 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 15 StateMachines: doActivity and internal transitions

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

    What happens with the do activity if a internal transition fires? It is not mentioned in the specification.

  • Reported: UML 2.1.2 — Wed, 7 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Since the state is not exited, the do activity is unaffected by the firing of the internal transition.
    Add a clarifying statement to make this point explicit

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

Section: 7.3.10/Associations - insert reference

  • Key: UML22-392
  • Legacy Issue Number: 12384
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    “Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML” Please insert a reference to the document containing the predefined constraints

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9617 for disposition

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

Unspecified constraint [1] on ActivityNode

  • Key: UML22-432
  • Legacy Issue Number: 12790
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityNode (12.3.8) is unspecified:

    [1] Activity nodes can only be owned by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes can only be owned by activities or groups.
    self.activity=self.owner xor self.inGroup->includes(self.owner.oclAsType(ActivityGroup))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

constraint [4] on AcceptEventAction and unordered result:OutputPin property

  • Key: UML22-431
  • Legacy Issue Number: 12789
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    This constraint implicitly requires that the AcceptEventAction.result property should be ordered to enable order-sensitive comparison with corresponding properties in Signal.ownedAttribute.

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved.

    {Subsets Action::output}

    The
    [4a] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent.
    [4b] The number of result output pins must be the same as the number of attributes of the signal.
    [4c] The type and ordering of each result output pin must be the same as the corresponding attribute of the signal.
    [4d] The multiplicity of each result output pin must be compatible with the multiplicity of the corresponding attribute.
    self.isUnmarshall implies
    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))


    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the result property to the following:

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved. This association end is ordered. {Subsets Action::output}

    Change the specification of the constraint to the following:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set{1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Note: if the result property is not ordered, this constraint can be approximated in the following manner:

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

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

figure 13.12

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

    In the latest 2.2 version of the UML spec, there was a change for issue : 11409 - redirect TimeEvent::when to TimeExpression (from ValueSpecification).
    In the resolution to that issue, figure 13.13 (p427) was properly updated but it looks like figure 13.12 has a problem in that the association from TimeEvent should go to TimeExpression

  • Reported: UML 2.1.2 — Tue, 19 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    At first it seems like this would be any easy resolution - just update Figure 13.12. The problem is that the Event classes in Figure 13.12, including TimeEvent, are in the CommonBehaviors::Communications package, which is merged in at L1, while TimeExpression is in CommonBehaviors::SimpleTime, which is merged in at L2. Thus, having TimeEvent associated with TimeExpression - which is actually the case in the metamodel - causes a problem in the construction of L1 (which causes issues with the generation of XMI for L1).
    Now, one possibility would be to make the TimeEvent class in SimpleTime a merge increment. But the merging of typed elements has the constraint (see 7.3.40):
    "Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same."
    While not entirely clear, the implication is that the resulting type is the common supertype. In this case, TimeEvent::when has type ValueSpecification in Communications and type TimeExpression, a subclass of ValueSpecification, in SimpleTime. The common superclass is thus ValueSpecification - but if you end up with TimeEvent::when having type ValueSpecification in the merged L2, then there isn't much point in typing it as TimeExpression in SimpleTime!
    Another possibility would be to leave the type of TimeEvent::when as ValueSpecification, which would allow a TimeExpression to be used when SimpleTime is included at L3. But this was explicitly changed in the UML 2.2 RTF, indicating a strong desire that the type of TimeEvent::when be TimeExpression (which does make some sense).
    It also doesn't seem to be a good idea to merge SimpleTime into L1 instead of L2, just to be able to have TimeExpression available for TimeEvent.
    So, the proposed resolution is that TimeEvent be moved into SimpleTime. This means that time events would only be allowed at L2, not L1. But since state machines aren't included until L2 and accept event actions not until L3, it seems unlikely that this would be a real problem.

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

Unspecified constraint [1] on ActivityNode (StructuredActivities)

  • Key: UML22-433
  • Legacy Issue Number: 12791
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.8) is unspecified:

    [1] Activity nodes may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Clarification on use of Profiles.

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

    would like to get some clarification on the use of Profiles.

    Although it does not explicitly state this in the UML superstructure specification, there seems to be an implication that only Profiles should actually own Stereotype. The fact that Stereotype can be owned by any Package seems to be an unintended side effect of inheritance. Is it true that the only feature intended to own a Stereotype is Profile::ownedStereotype ?

    If it is true that only Profile can own a Stereotype, then it makes working with profiles with many stereotypes somewhat unruly (consider having 50 stereotypes). It would be nice to be able to group stereotypes within nested packages under a profile.

    Nesting profiles within profiles does not seem like an appropriate solution since: in order to satisfy constraint [2] in 18.3.6 the nested profile would also have to reference a metamodel; inconvenient. And, how would users use such a profile? Would they apply each nested profile separately? This seems to raise more problems than it solves.

    Either way, I would suggest that the spec. should provide some rules or guidelines in this area.

  • Reported: UML 2.1.2 — Thu, 4 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Property – Additional Operations, page 127.

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

    Property – Additional Operations, page 127.

    In the description of “isConsistentWith” –

    [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property.”

    The last word, “property”, should be “derived”.

  • Reported: UML 2.1.2 — Thu, 21 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

7.3.44 Property P128

  • Key: UML22-443
  • Legacy Issue Number: 12841
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query isNavigable() indicates whether it is possible to navigate across the property.
    Propery::isNavigable():Boolean
    isNavigable = not classifier->isEmpty() or
    association.owningAssociation.navigableOwnedEnd->includes(self)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    "association", and "owningAssociation" are also associationend on Property.
    Then, expression "association.owningAssociation" is not appropriate.
    It seems "association" in the expression should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

18.3.8 Stereotype

  • Key: UML22-442
  • Legacy Issue Number: 12840
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    For example in UML, States, Transitions, Activities,
    Use cases, Components, Attributes, Dependencies, etc.
    ~~~~~~~~~~
    In UML2.2, Attribute isn't model element.
    This seems incorrect.
    This explanation is example, then, it seems term "Attributes" should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Problem is now out of date.
    Disposition: Closed - No Change

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

Unspecified constraint [3] on Activity

  • Key: UML22-430
  • Legacy Issue Number: 12788
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [3] The groups of an activity have no supergroups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [3] The groups of an activity have no supergroups.
    self.group->forAll(superGroup->isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Typo P205 10.3.4

  • Key: UML22-440
  • Legacy Issue Number: 12838
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:


    Attribute -> Attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

On the table 2.3, page 8

  • Key: UML22-439
  • Legacy Issue Number: 12836
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Sturcute CompositeStructure::InternalStructure.
    Is it correct?
    It seems typo. "CompositeStructures"

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

On the communication diagram in Fig 6.2 (second issue)

  • Key: UML22-438
  • Legacy Issue Number: 12835
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    The sequence expression is denoted as "A1", "B1", "A3".
    According to the specification, those messages means
    asynchronous messages.
    If so, the diagram doesn't show original intention.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

On the communication diagram in Fig 6.2 (P12)

  • Key: UML22-437
  • Legacy Issue Number: 12834
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    There are underlined lifeline.
    According to UML 2.2 specfication (chapter 14),
    lifeline label refrains from underlined notation.
    It seems these are not appropriate

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

7.3.11 DataType, P61

  • Key: UML22-441
  • Legacy Issue Number: 12839
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "The Attributes owned by the Data Type. This is an ordered collection.
    ~~~~~~~~~~
    Subsets Classifier::attribute and Element::ownedMember."

    Attributes->attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Well spotted.

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

UML 2.1.2:18.3.5 Package (from Profiles)

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

    18.3.5 Package (from Profiles)

    Description

    A package can have one or more ProfileApplications to indicate which profiles have been applied.

    Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.”

    A Profile is a subclass of InfrastructureLibrary::Constructs::Package, which cannot own ProfileApplications and so you can’t apply a profile to a profile.

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Profiles does subclass Constructs::Package, but when Profiles is merged with Kernel::Classes::Package in UML compliance level L3, Package gets the ability to have applied profiles, as does its subclass, Profile. So whether a profile can be applied to a profile depends on what Profiles is merged with.

    Note that Profiles cannot stand alone, with just an import of Constructs since it defines Class as a merge increment (in order to add extensions). Profiles::Class has no ownedAttributes, so without a merge, Stereotypes would not be able to have Properties.

    However, applying a profile to a profile would extend the extensibility mechanisms of UML in non-standard ways that would not be supported by most tools. This would limit interoperability and break model interchange. So it should not be possible to apply a profile to another profile.
    Disposition: Closed, no change.

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

UML Super 2.1.2:Feature

  • Key: UML22-382
  • Legacy Issue Number: 12275
  • Status: closed  
  • Source: Mathworks ( Alan Moore)
  • Summary:

    The Semantics section for Feature says:

    “A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier’s instances considered individually (not static), or of the classifier itself (static).

    A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another.”

    It seems to me that the second sentence is simply a reiteration of the description of property “/ featuringClassifier: Classifier [0..*]

    The third sentence could be expressed more usefully as a constraint.

    I’m also puzzled by the 0..* multiplicity on featuringClassifier. It would be useful if the description of Feature explained when a feature can have more than one featuring classifier.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue refers to obsolete text. This resolution addresses its final paragraph. We discussed
    this in our face-to-face meeting in Reston in March 2013 and decided to change the multiplicity of Feature::
    featuringClassifier to 0..1 (because this is a logical consequence of the remainder of the UML spec and
    does not affect serialization), and change the wording accordingly, pointing out the special case of Properties
    used as qualifiers which have no featuringClassifier.

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

A final node that returns to the caller but leaves alive any parallel flow

  • Key: UML22-384
  • Legacy Issue Number: 12284
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The regular ActivityFinalNode stops all possible parallel flows in the activity before
    returning to the caller.
    There are some cases where it would be interesting to have a variant of this behavior
    which would allow returning immediately but without affecting the execution of any
    parallel flow.

    A use case for this "soft return" construct: An application process a user "search" request.
    When it founds a first set of results it returns immediately the response to the user but it
    the meantime continues looking for another set of requests to anticipate possible additional
    request from the user, without loosing the context of the user request.

    For this use case we will use the "soft return" final node to return when finding the first
    set of responses and will use a FlowFinalNode at the end of a parallel branch looking for
    additional responses.
    For sure, it is always possible to encode this use case differently, but such new kind of
    final node would allow to model the intended behavior more directly.

    Rq: What would happen if a "soft return" is reached after a "soft return" already happened:
    I guess the semantics would be to behave as a FlowFinalNode (cannot return twice).
    And what if a "regular" ActivityFinalNode is reached after a "soft return": I guess all
    existing parallel are stopped but there is no return to the caller (since already returned).

  • Reported: UML 2.1.2 — Tue, 18 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A behavior that is initially invoked via a synchronous call does not have its own thread of control, so it would be a fundamental semantics change to somehow allow it to continue executing after returning from the call. Fortunately, however, the functionality desired by the submitter can be easily achieved using existing UML mechanisms, by first starting the activity asynchronously, either as a classifier behavior or as a standalone behavior execution. Such an executing activity can then accept client requests using an accept event action and respond to them without terminating, as the submitter envisions. The activity can even accept a synchronous call via an accept call action and reply using a reply action, without terminating. In this case, the reply action acts, in effect, as the "soft return" suggested by the submitter.
    Revised Text:
    None
    Disposition: Closed No Change

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

section '10.3.12 Property (from Nodes)'

  • Key: UML22-380
  • Legacy Issue Number: 12271
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    In section '10.3.12 Property (from Nodes)', the Description states "In the metamodel, Property is a specialization of DeploymentTarget", but a corresponding generalization is not defined under 'Generalization'. Proposed resolution: Add '"DeploymentTarget (From Nodes)" on page 205' to the Generalization section of 10.3.12.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

PackageableElement (from Kernel), subsection: "Attribute"

  • Key: UML22-379
  • Legacy Issue Number: 12266
  • Status: closed  
  • Source: System ( Mehran Touhidi)
  • Summary:

    section: PackageableElement (from Kernel), subsection: "Attribute" is writen "Default value is false." that it cannt has that value because its type is VibilityKind and can only has one of its enumerated value.

  • Reported: UML 2.1.2 — Sat, 8 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10379 for disposition

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

CMOF file for UML2 does not have derived Associations marked as such

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

    For example A_ownedMember_namespace

    Has both its ends marked with isDerived=”true” but not the Association itself.

  • Reported: UML 2.1.2 — Thu, 27 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 8.3.3

  • Key: UML22-385
  • Legacy Issue Number: 12356
  • Status: closed  
  • Source: University Karlsruhe ( Conny Kuehne)
  • Summary:

    On Page 23 of the UML Infrastructure Spec. it is stated, that "The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).". This implies that omitting to define the multipl. of an association end A means that the multiplicity of A is * (between zero and infinity). However this contradicts most books I know and some examples in the specification itself.

  • Reported: UML 2.1.2 — Wed, 26 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

description of MessageOccurenceSpecification

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

    The description of MessageOccurenceSpecification defines a property called event. It is useless, because MessageOccurenceSpecification inherits from OccurenceSpecification that already owns this property, as denoted in the figure 14.5.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

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

The list of literal described for the ennumeration MessageSort is not compl

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

    The list of literal described for the ennumeration MessageSort is not complete according to it sdescription as shown in figure 14.5.

  • Reported: UML 2.1.2 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

undefined term 'Element::redefinedElement' occurs three times in standard

  • Key: UML22-381
  • Legacy Issue Number: 12273
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The undefined term 'Element::redefinedElement' occurs three times in the standard where 'RedefinableElement::redefinedElement' is expected.

  • Reported: UML 2.1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 7.4 figure 7.1 missing dependency

  • Key: UML22-419
  • Legacy Issue Number: 12749
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    The first sentence of 7.4 states: As was depicted in Figure 7.1, the Profiles package depends on the Core package, .... Figure 7.1 does not shown any dependency between the Profiles package and the Core package

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

UML2: Need a better mechanism for integrating UML2 Profiles

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

    UML2 Superstructure specifies how to define a Profile, how Profiles can reference other Profiles through PackageImport and ElementImport, and how one stereotype could extend another through generalization/specialization. However, this is insufficient for profile integration as it results in too much coupling between profiles. What is needed is a more flexible mechanism for integrating UML2 profiles.

    For example, both UPDM and SysML are UML2 profiles. UPDM would like to reuse certain stereotypes from SysML in order to provide effective integration in cases where consumers want to use both. However, UPDM would also like to be able to stand alone in cases where SysML isn't needed. The problem is how to model the overlapping stereotypes and classes without creating coupling that would require all applications of the UPDM profile to also require an application of SysML.

    Consider a concrete example of overlap between the profiles, the stereotype ViewPoint. Both UPDM and SysML have a similar concept of ViewPoint, for similar purposes. However, each has its own specializations of ViewPoint, and possibly associations between ViewPoint and other stereotypes. There are a number of approaches for handling this overlap, but none are adequate or practical.

    1. Profile refactoring: Each profile could factor its stereotypes into packages, and arrange the navigability of its associations to decouple its stereotypes in order to support anticipated reuse. This is what UML2 did, quite unsuccessfully, with the Abstractions packages. This isn't practical because 1) no existing profiles do it, 2) it is impossible to anticipate all the possible reuse opportunities and to design a profile to support them, and 3) it is sometimes impossible to define the associations between stereotypes to ensure the necessary decoupling.

    2. Use ElementImport to select only the stereotypes you need, then subclass to minimize the coupling: This can work, but it results in complex profiles with possibly a lot of subclasses simply to integrate with other profiles. For example, UPDM couldn't use ViewPoint directly, it would have to create a subclass, either coming up with a new name, or putting its ViewPoint in a different Package so that it wouldn't collide with SysML. This is confusing, and results in stereotypes with either the same meaning but different names, or two stereotypes with the same name in different packages. This also requires both profiles to exist, even though the both don't need to be applied. This is again an undesirable side-effect of too much coupling.

    Both of these approaches end up inhibiting profile integration and reuse resulting in limited integration between OMG submissions. UPMS had wanted to include integrations with many other submissions including RAS, BPDM, BPMN, ODM, QoS, and BMM. However we could not determine a practical way to do this with current technologies and did not include many of these integrations because of the resulting risk, complexity and coupling. This is a particular problem when we consider the OMG specifications, profiles, and metamodels in an enterprise architecture context where the relationships between the parts are critical to delivering value.

    UML2 provides a solution to this problem for extensions created using MOF metamodels to model capabilities. PackageMerge can be used to merge metaclasses with the same name from different capabilities in order to mixin their capabilities. What is needed is a similar capability for UML2 profiles.

    A proposed solution would be to extend UML2 Profiles to include similar merge semantics when multiple profiles containing the same classes or stereotypes are applied to the same model. When a Profile is applied to a Package, the Classes and Stereotypes in the Profile would be merged with Classes and Stereotypes of other Profiles that have already been applied. The rules for PackageMerge can be used to define how this merge is done as they already apply to Class, and can equally apply to Stereotype which is a specialization of Class. Conflicts resulting from the merge could be considered defects against the profiles that could be handled in an RTF.

    Consider the same example above; both UPDM and SysML define ViewPoint.

    3. Profile Merge: The UPDM submitters would be careful to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM conuld extend ViewPoint with additional properties and associations for its purposes. The UPDM submission could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling or need for SysML. Later on, another user could decide to apply SysML to the same model in order to use its modeling capabilities. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Similarly, users could have started with SysML and later applied UPDM to achieve the same effect.

    This is a significant change to UML2, but may be an urgent issue due to the number of other profiles and submissions looking for a solution to this problem.

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Regression in XMI from UML 2.1.2 to UML 2.2

  • Key: UML22-421
  • Legacy Issue Number: 12774
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    At 03:12 PM 8/13/2008, Pete Rivett wrote:

    Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all!
    Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs.
    The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable.

    In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP.

    >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant.

    Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this.

    Pete

    From: Nicolas Rouquette [ nicolas.rouquette@jpl.nasa.gov]
    Sent: 13 August 2008 19:15
    To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor
    Subject: unalabelled association-owned memberEnd property names affect the name of an association

    I noticed strange differences between the XMI serialization of the UML superstructure in:

    UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof
    UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    For example, in UML 2.1.2, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    whereas in UML 2.2beta1, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec.

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

    The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 – i.e., the name of the class with a lowercase initial.

    Is it OK for association names to change in this manner from one rev to another or is this a bug?

    Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes.

  • Reported: UML 2.1.2 — Wed, 13 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 2.2-2.4 compliance level clarifiction needed

  • Key: UML22-420
  • Legacy Issue Number: 12750
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    Section 2.2 introduces two compliance levels: L0 and LM. Section 2.3 states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level. This also implies full realization of all language units in all the levels below that level. “Full realization” for a language unit at a given level means supporting the complete set of modeling concepts defined for that language unit at that level. Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1." This is confusing as there is no such thing as Level 1 or Level 2 defined. This concept is repeated in section 2.4: "(as a rule, Level (N) includes all the packages supported by Level (N-1))" It may be worth mentioning that the superstructure document will introduce further levels on top of the infrastructure level L0. Also, if I understand it correctly: LM builds on L0, and so does L1. So we have two parallel paths of compliance: L0 <- LM and L0 <- L1 <- L2 <- L3 So how does LM fit in with the L(N) compliant is also L(N-1) compliant scheme? Do you need to specify L2 and LM compliance?

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Unspecified constraint [1] on AcceptEventAction

  • Key: UML22-424
  • Legacy Issue Number: 12782
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [1] AcceptEventActions may have no input pins.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] AcceptEventActions may have no input pins.
    self.input->isEmpty()

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

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

Incorrect OCL expression for constraint [1] on BehavioredClassifier

  • Key: UML22-423
  • Legacy Issue Number: 12781
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: incorrect OCL constraint

    Summary:

    The following constraint on BehavioredClassifier (13.3.4) is incorrectly specified:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.specification->isEmpty()

    Discussion:

    self.specification does not resolve to any attribute of BehavioredClassifier.
    self.classifierBehavior resolves to a Behavior which can have 0 or 1 BehavioralFeature specification.
    Hence, the correct OCL navigation expression should be self.classifierBehavior.specification instead of self.specification.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

OCL 2.0 8.2 Real

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

    OCL reuses Boolean, Integer, String, UnlimitedNatural from UML Infrastructure.

    OCL uses Real in a very similar fashion, but there is no corresponding
    definition of Real in either OCL or UML Infrastructure.

  • Reported: UML 2.1.2 — Sat, 19 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The primitive type “Real” needs to be added to the PrimitiveTypes package for consistency with the OCL Real type. “Real” has also been defined separately by SysML and MARTE specifications and the new Diagram Definition Submission, so adding it to the PrimitiveTypes package will encourage reuse.
    Another argument for adding a primitive type “Real” is that there is currently no normative way to notate real numerals in UML models. So, even if some model library adds a “Real” primitive type, there is technically still no normative way to write a literal for that type in a UML model. This suggests the need for a Real Literal definition as well.
    (Note that the revised text below presumes the resolution to Issue 13993.)

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

UML2 issue regarding RedefinableTemplateSignature

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

    UML Superstructure V2.2, Section 17.5.9 RedefinableTemplateSignature.

    The paragraph in the "Semantics" section RedefinableTemplateSignature mentions the following:
    All the formal template parameters of the extended signatures are included as formal template parameters of the extending signature, along with any parameters locally specified for the extending signature.

    I beleive this would imply that the "parameter" feature would need to be derived which it is currently not.

  • Reported: UML 2.1.2 — Fri, 18 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    /inheritedParameter is indeed derived and is a subset of parameter, which corresponds to the semantics.
    Disposition: Closed - No Change

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

Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities)

  • Key: UML22-427
  • Legacy Issue Number: 12785
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies
    (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Unspecified constraint [2] on ActivityEdge

  • Key: UML22-426
  • Legacy Issue Number: 12784
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [2] Activity edges may be owned only by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] Activity edges may be owned only by activities or groups.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Unspecified constraint [2] on Activity

  • Key: UML22-429
  • Legacy Issue Number: 12787
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.
    self.isActive implies (self.getContext()>isEmpty() and self.classifierBehavior>isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Unspecified constraint [1 on Activity

  • Key: UML22-428
  • Legacy Issue Number: 12786
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.
    self.node->select(oclIsKindOf(ActivityParameterNode)).oclAsType(ActivityParameterNode).parameter->asSet()>symmetricDifference(self.ownedParameter>asSet())->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

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

Section 7.3.50 "substitution"

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

    As describe, a "Substitution" looks more like a derived property than like a relationship, except if it must be interpreted as an explicit inheritence restricted to the external contracts (with possible redefinition). The point is that is not clear with the current description

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The revised text in UML 2.5 is clearer.
    Disposition: Closed - No Change

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

Keyword ambiguity for DataType Section

  • Key: UML22-416
  • Legacy Issue Number: 12584
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    Keyword ambiguity for DataType Section 7.3.11 Describes the use of the 'dataType' keyword (along with Figure 7.36). Whereas, the example depicted in Figure 7.39 shows a DataType with the 'datatype' keyword.

  • Reported: UML 2.1.2 — Wed, 23 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Unspecified constraint [1] on ActivityEdge

  • Key: UML22-425
  • Legacy Issue Number: 12783
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [1] The source and target of an edge must be in the same activity as the edge.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    let edgeActivity:Set(Activity) = self.inGroup->closure(inGroup).inActivity->asSet()>union(self.activity>asSet()) in
    let sourceActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    let targetActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    edgeActivity->symmetricDifference(sourceActivity)->isEmpty() and
    edgeActivity->symmetricDifference(targetActivity)->isEmpty()

    Change the Superstructure XMI accordingly.

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

Section: 9.3.8

  • Key: UML22-422
  • Legacy Issue Number: 12775
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    There is an association of EncapsulatedClassifier (9.3.8) ownedPort which is derived and subsets Class::ownedAttribute. The problem I have is that I don't see how ownedPort can subset Class::ownedAttribute. I don't see an inheritance path from EncapsulatedClassifier to Class. Also, which Class is it referring to? Class (from Kernel), Class (from StructuredClasses), etc. This problem exists for all "subsets" statements in the specification. Thank you.

  • Reported: UML 2.1.2 — Thu, 14 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It should in fact refer to StructuredClassifier::ownedAttribute

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

Section 10.3.10

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

    Shouldn't be a constraint or a redefinition in order to specify that the client of a manisfestation is its owning artefact?

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The requested logic is already provided because artifact subsets owner. Since artifact also subset client, the artifact is
    clearly identified as the client. No additional constraints are required.
    Disposition: Closed - No Change

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

definition of RedefinableElement::isLeaf

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

    Version of Spec: 2.1.1 2007--2-05, Section 7.3.46 p.130

    The definition of RedefinableElement::isLeaf indicates that "If the value is true, then it is not possible to further specialize the RedefinableElement". However there is no explicit constraint that actually enforces this (at least none that I could find). I believe that a constraint should be created to address this.

  • Reported: UML 2.1.2 — Tue, 17 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is not a duplicate of issue 9831 which is closely related to issue 10515.

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

Behavior's parameter list

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

    We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature.

    >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint:
    [1] The parameters of the behavior must match the parameters of the implemented behavioral feature

    We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync.

    We would like to request that this constraint is removed from the specification.

  • Reported: UML 2.1.2 — Fri, 13 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 7626

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

PackageMerge relationships

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

    The way the PackageMerge relatrionships are used in the specification doesn't seem to be rigorous or, at least, are not clear. For instance: * §7.3.7 indicates that the "Class" from Kernel metaclass is a specialization of “Classifier (from Kernel, Dependencies, PowerTypes)”. That is not correct if you refere to the corresponding package diagram: "Class" from Kernel doesn't inherit from Dependencies and PowerType merge increment of "Classifier" * §7.3.6 "BehavioredClassifier" from Interfaces) is a merge increment of "BehavioredClassifier" from BasicBehavior) but not for "BehavioredClassifier" from Communications (it's the opposite). * etc... Then, i suggest to define PackageMerge relationships of the metamodele in a more formal way than simple diagrams and to validate that metaclass definition are consistent with these relationships.

  • Reported: UML 2.1.2 — Tue, 10 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 7.3.36

  • Key: UML22-413
  • Legacy Issue Number: 12569
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 6. 6.1 Operation is having very wide type (Type) as an exception instance (raisedException). Theoretically it is possible that Association may be thrown as an exception. ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. I wish that this was the only place where the metamodel suffers from overgeneralization. Unfortunately, this is almost endemic in how things are done in UML.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    If we were to constrain the type of exceptions, we might invalidate user models. There seems no reason to make a
    change here.
    Disposition: Closed - No Change

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

Section: 11.3.30,12.3.23

  • Key: UML22-412
  • Legacy Issue Number: 12567
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 4 4.1. Exceptions raising is provided on L2 compliance level (RaiseExceptionAction from Actions/StructuredActions) while handling is provided on L3 (ExceptionHandler from Activities/ExtraStructerdActivities). That functionality is an integrated part and raising and handling exceptions should be provided on the same compliance level. ++++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. We did not focus too much on the modeling of exceptions – it was not a priority item at the time. It should probably be so now. Your work is definitely timely. Andrzej Zielinski: That is about my Ph.D thesis

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.

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

Section: 13.3.3

  • Key: UML22-410
  • Legacy Issue Number: 12564
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 2 2.1 Relation raisedException of Operation and BehavioralFeature classes not consistently set (CommonBehaviors/Communications) (L2 compliance). Operation (Classes/Kernel) (L1 compliance level ) inherits from BehavioralFeature (Classes/Kernel) (L1) and redefines raisedException to Type. On that level there is no problem. But in CommonBehaviors/Communications BehavioralFeature redefines raisedExceptions to point to Classifier. As a result Operation points to Type, while BehavioralFeature to Classifier. Classifier is more specific than Type (Classifier inherits from Type) +++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There does not seem to be any reason for Communications::BehavioralFeature to have a raisedException attribute. It is not used anywhere in Communications. Kernel::BehavioalrFeature already has a raisedException property that will be included when the BehavioralFeature merge increments are actually merged.

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

Section: 12.2

  • Key: UML22-411
  • Legacy Issue Number: 12565
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 1 Some classes in certain packages are abstract, while they are not in packages that are on a higher (or the same) compliance level. 1.3. Pin in Activities/BasicActivities (L1 compliance level) (Fig. 12.4 p.299 ) and Activities/CompleteActivities (L3) (Fig.12.16 p. 305) are not abstract, while in they are in package ActionsBasicActions (L1) (Fig. 11.3 p. 221) ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

The behavior of an OpaqueExpression should itself be opaque

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

    The behavior of an OpaqueExpression should itself be opaque

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Under Subclause 13.3.21, it says that the extension to OpaqueExpression "Provides a mechanism for precisely defining the behavior of an opaque expression." It is hard to see how one can precisely define behavior, if the behavior is itself opaque. Indeed, specifying the behavior of an OpaqueExpression with, say, an activity is the only way to model an expression in UML in terms of executable actions, so this should not be precluded.
    Revised Text:
    None.
    Disposition: Closed No Change

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

Section: 13.3.23

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

    The multiplicity of the "signal" property of a Reception is [0..1]. What's the semantic of a Reception that would be associated with no signal?

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Areception should be required to specify a signal.

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

Classifiers

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

    Classifiers are specialized to hold useCase properties in the UseCases package but this package is not merged/imported by any other ones. Does it formally mean that - for instance - no version of the metaclass "Class" should be able to hold use cases?

  • Reported: UML 2.1.2 — Wed, 4 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 7.3.35

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

    In order to be complinat with the semantics, "body" and "language" properties of an OpaqueExpression shall be ordered

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Packaging Issues with Stereotype Extension

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

    Section: 18.3.2 (Extension)

    Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

    However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

    UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

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

    The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly.
    A couple of decisions need making about this metamodel, which we?ve discussed extensively in email:
    1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package.
    2. Do we apply any stereotypes such as «metamodel» or «metaclass» in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use «metamodel». Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: “A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» …”

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

inconsistency with how constraints are specified in UML and OCL

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

    In OCL 2.0 specification, section Operation Body Expression, it specifies that
    expression must conform to the result type of the operation.

    However, in UML 2.1.2 specificaiton, it is specified that bodyCondition of an
    operation is a constratin which must evaluates to a boolean expression.

    The problem is that UML equates the term "constraint" with "boolean-valued
    expression that holds true at some time." The OCL usage of the term is not so
    narrow. A constraint is a model element that specifies more precise semantics
    for another model element than what its structure alone can achieve.

    So, for example, an attribute constrains its values to conform to some type,
    but a derivation expression (whose value conforms to the attribute type) more
    precisely constrains its values. Likewise the operation body expression
    constrains the value of an operation by computing it from the parameters and
    the context object. Note that OCL actually calls this constraint a "body
    expression," not a "body condition" as UML does. OCL's notion of "constraint"
    even extends to definition of helper operations and attributes.

    Consider what it means to require boolean values for operation body
    constraints. They must be formulated like postconditions, as boolean
    expressions on the "result" variable. In OCL, the body condition does not have
    a "result" variable; only post-conditions have it. Furthermore, consider an
    example: an operation phi() defined in the Real primitive type. According to
    UML's rules, it could be defined like this:

    context Real::phi() : Real
    body: result = (1.0 + 5.0.sqrt()) / 2.0

    or like this:

    context Real::phi() : Real
    body: (result - 1.0) = (1.0 / result)

    These are isomorphic constraints, but neither is friendly to OCL tool
    implementations (certainly not the second). According to OCL, the constraint
    would by formulated like this:

    context Real::phi() : Real
    body: (1.0 + 5.0.sqrt()) / 2.0

    and there really is no other kind of formulation. IMO, this is much more
    practical for all concerned.

    Consider an operation that has parameters, for which I write an ineffectual
    body constraint like this:

    context Foo::doSomething(bar1 : Bar, bar2 : Bar) : Baz
    body: bar1 <> bar2

    What does this mean?

    All in all, it is far mare useful to have an OCL expression that can readily be
    evaluated to compute the value of the operation. This leaves no room for
    ambiguity.

    The UML stipulation that Constraints in all contexts must be boolean
    expressions, as in operation precondition and classifier invariant context, is
    unnecessary. What is the benefit? It would be nice to see it removed in UML
    2.3.

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

    merged with 15259

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

Allowing multiple Associations in a Package with the same name

  • Key: UML22-470
  • Legacy Issue Number: 13330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I had a recent ‘argument’ with Steve Cook on his blog. There is a lot of confusion with regards to whether there can be multiple Associations with the same name in a Package. Steve made the valid point that Association does not redefine “isDistinguishableFrom”, which it gets from being a NamedElement. This is overridden for BehavioralFeature, but not for Association, thus based on that rule from NamedElement, I assume that there may not be multiple Associations with the same name (including empty) in a Package.

    However, I came across the following cases that seem to ignore this notion:

    1) In the rules for PackageMerge (7.3.40), they allow for the ability to have multiple Associations with the same name by taking into account their member ends: “Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties).”

    2) The MOF 2.0 XMI file almost never names its’ Associations, thus having many Associations with the same name.

    3) The UML 2.1.1 Superstructure XMI file also has multiple associations with the same name. As an example, see the package with id “AuxiliaryConstructs-Templates”. It owns 3 associations with the name “A_templateParameter_parameteredElement” (ids “A_templateParameter_parameteredElement”, “A_templateParameter_parameteredElement.1” and “A_templateParameter_parameteredElement.2”).

    Is it intended that multiple Associations with the same name be allowed in a Package or not? If not, then we need to fix Superstructure, MOF, and we can also relax the PackageMerge rule for Associations. If we do allow it, then we should add a new redefinition of “isDistinguishableFrom” for Association that specifies a similar rule to the one described in PackageMerge, that an Association type is distinguishable from another Association if the set of its name and the names of all its member ends is not equal to the corresponding set of the other Association.

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

    A redefine of isDistinguishableFrom for Association is not desired. As such, the PackageMerge rule for Association, which implies the possibility of multiple Associations in a Package with the same name, including if they have no name, provided their member ends differ in some way, is to be amended as it can result in ill-formed merged Packages. This is supported by the following 2 constraints:

    1. MOF 2.0 Specification, under section "12.4 EMOF Constraints" there is the following constraint (which would be violated if the Associations have no name):
    "[3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool)."

    2. In "9.14.2 Namespace" of the UML 2.1.2 Infrastructure Specification there is the following constraint (which would be violated if the Associations have the same name):
    "[1] All the members of a Namespace are distinguishable within it."

    As such, explicit rules are also to be added to PackageMerge requiring well-formedness of the merged Package.

    The XMI elements cited as examples of clashing Association names are to be renamed.

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

P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo

  • Key: UML22-469
  • Legacy Issue Number: 13327
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding UML 2.2 Superstructure

    P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences

    ExecutionOccurences
    ~~

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

    No Data Available

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

Figure 18.2 (which describes the contents of the Profiles package) is currently misleading

  • Key: UML22-472
  • Legacy Issue Number: 13844
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them.

  • Reported: UML 2.1.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

ParameterableElement as a formal template parameter

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

    Say we want to expose a ParameterableElement as a formal template parameter.
    If we want to create the following List<E>, then the template parameter would refer to some parameterable element E whose type we would have to choose (say uml:Class).
    Now, say we wanted to create List< Interface >, or List < Class >, or List < DataType >. I don't think we would be able to then create TemplateParameterSubstitution for all these elements since the type of formal and actual parameters are inconsistent.

    The problem is that we must pick a concrete type for that ParameterableElement - we can't for example use Classifier as the template parameter because it's abstract.

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

    This is a general issue with the way TemplateParameters are handled in the UML abstract syntax, and it would require
    a major change in the approach to templates to resolve it in general. However, the specific (and most common) case
    mentioned in the issue, that of a template for which it is desired to expose a Classifier as a parameter, is actually
    covered by a special case in the specification.
    In the UML 2.5 specification, subclause 9.3.3 describes the semantics of ClassifierTemplateParameters, which are
    TemplateParameters where the parameteredElement is a Classifier, optionally constrained by a set of constraining-
    Classifiers. Toward the end of this section, it says “if the constrainingClassifier property is empty, there are no constraints
    on the Classifier that can be used as an argument.” Thus, in defining a template List<E>, it is possible for the
    parameteredElement of the formal TemplateParameter E to be a Class, but to still, in a binding for List, substitute for
    E with an argument that is any kind of Classifer (including Interface, DataType, etc.).
    Disposition: Closed - No Change

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

UML. Clarify relationship of Substitution and InterfaceRealization

  • Key: UML22-465
  • Legacy Issue Number: 13164
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification of ClassifierTemplateParameter has a flag allowSubstitutable. The definition of ClassifierTemplateParameter::constrainingClassifier says “If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted”. What does “compatible” mean? If we look in Templates::Classifier we find this:

    Semantic Variation Points If template parameter constraints apply, then the actual classifier is constrained as follows. If the classifier template parameter:

    • has a generalization, then an actual classifier must have generalization with the same general classifier.

    • has a substitution, then an actual classifier must have a substitution with the same contract.

    • has neither a generalization nor a substitution, then an actual classifier can be any classifier.

    If template parameter constraints do not apply, then an actual classifier can be any classifier.

    Firstly, the spec for classifier template parameters needs to clarify what compatible means; and this clarification must surely include the possibility that the relationship between the constrainingClassifier and the template parameter can be an InterfaceRealization as well as a Substitution.

    Secondly, this text for Semantic Variation Points is weird. Presumably it means that the constraints on substitutability of ClassifierTemplateParameter are a SVP. If so it should say so, and the SVP text should be under ClassifierTemplateParameter.

    Finally, it appears that given the existence of Substitution, InterfaceRealization is completely redundant. A good simplification would be to eliminate InterfaceRealization altogether; failing that to make it a subclass of Substitution to clarify that it has contract compatibility semantics.

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

    Most of this issue is obsolete: these semantic variation points have been clarified in the text. Changing the metamodel
    as suggested in the final point would be too disruptive.
    Disposition: Closed - No Change

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

UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid

  • Key: UML22-462
  • Legacy Issue Number: 13146
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL definitions of how Component.provided and Component.required are still invalid, even though they were altered in 2.2. The subexpressions self.implementation and self.realizingClassifier, which appear in both derivations, are not valid: there are no such properties on Component.

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

    It seems that the first "let" clause of each constraint is supposed to do what the second "let" actually does. So we'll delete the first one.

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

transitionkind Constraints

  • Key: UML22-464
  • Legacy Issue Number: 13163
  • Status: closed  
  • Source: Individual ( Jerry Wang)
  • Summary:

    In transitionkind Constraints, the document said: [1] The source state of a transition with transition kind local must be a composite state. [2] The source state of a transition with transition kind external must be a composite state. Does these two constraint means that simple state can not have a outgoing transition?

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

    The cited constraints are not present in the UML 2.5 version of the spec.
    Disposition: Closed - No Change

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

UML 2.2 figure 8.10 has arrows the wrong way around

  • Key: UML22-463
  • Legacy Issue Number: 13147
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The dependencies in 8.10 should surely point from the Component (the client) to the realizing Classifiers (the suppliers). Also there is a redundant sentence “Alternatively, they may be nested within the component shape” above that figure which is repeated below.

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

    The first part of this issue is wrong (see resolution to 11008 for explanation). The notation for the diagram is wrong which will be fixed by 10651.
    The second part is correct.

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

UML2.2 Section 9.3.1 Presentation Options section

  • Key: UML22-461
  • Legacy Issue Number: 13142
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The Presentation Options section of 9.3.1 seems both inappropriately named and in entirely the wrong place. It is about usage dependencies, constructors and instance specifications and should appear somewhere in chapter 7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter

  • Key: UML22-460
  • Legacy Issue Number: 13141
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Section 9.3.1 the second paragraph starts “A class acts as the namespace ...”. This semantic about nested classes is part of normal classes and should be moved to 7.3.7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Figure 2.2 contains more than four packages, description referes to four packages

  • Key: UML22-471
  • Legacy Issue Number: 13665
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the paragraph describing Figure 2.2, the text refers to "four packages". Figure 2.2 contains more than four packages. The corresponding figure in Version 2.0 of the Superstructure displayed four packages; presumably the text wasn't updated along with the figure.

  • Reported: UML 2.1.2 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Behaviors Owned by State Machines

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

    State and Transition currently own the behaviors that they invoke. This is very restrictive because it makes it impossible to reuse Behaviors across state machines, or even across transitions and states.

    Consider allowing States and Transitions to merely reference behaviors rather than owning them.

  • Reported: UML 2.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Interesting idea, but it's too large a change to be considered for the current RTF. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A
    Disposition: Closed, out of scope

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

Section: 12.3.41 Streaming parameters for actions

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

    Semantics, 2nd paragraph about streaming: "Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning." Since an action represents a single step and is atomic. I think it is not possible that an atomic action comsumes further parameters during execution.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The stated issue presumes that action execution is atomic, which is not necessarily the case, and is certainly not the case for a call action to a behavior with streaming parameters. The whole point of streaming parameters is the semantics given in the quoted sentence, and they would be useless if this was not possible.
    However, the quoted sentence is poorly worded, since it is behaviors that have parameters and are invoked, not actions. This may be causing the confusion and should be corrected.

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

Section: 13.3.24

  • Key: UML22-316
  • Legacy Issue Number: 10960
  • Status: closed  
  • Source: International Business Machines ( Mr. Anders Ek)
  • Summary:

    There is an association defined for the Signal metaclass as follows: signal: Signal [1] The signal that is associated with this event. It is unclear what this associaiton is intended to represent. Should this association really be there?

  • Reported: UML 2.1.1 — Thu, 19 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disucssion: Duplicate of 9576. Disposition: Duplicate

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

Section: 15.3.14

  • Key: UML22-315
  • Legacy Issue Number: 10959
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    On page 569 in section 15.3.4 (Transitions), constaint # 5 identifies which outgoing transitions, given their source pseudostates, may not have triggers: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() This OCL is incorrect since transitions leaving either a Junction Point, Initial State or a Join should not have triggers. The given OCL specifies the inverse - that only those pseudostates may have triggers. One contradiction to the above OCL exists on page 537 in section 15.3.8 (Pseudostates), constraint #9: [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard. (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty()) Furthermore, transitions leaving a fork are also not allowed triggers (constraint #1), so this could also be contained in the transition's OCL constraint (#5). Therefore the OCL for constraint #5 should be written as: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind = #junction) or (source.kind = #join) or (source.kind = #initial) or (source.kind = #fork)) implies trigger->isEmpty()

  • Reported: UML 2.1.1 — Wed, 18 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Text has already been fixed in the UML 2.2 specification to be
    [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate).
    (source.oclIsKindOf(Pseudostate) and
    (source.kind <> #initial)) implies trigger->isEmpty()
    which resolves the above issue

    Revised Text:
    N/A

    Disposition: ClosedNoChange

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

Wrong subsets

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

    Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).

    ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation).

    Required changes:

    "abstraction" must subset "supplier" and "realizingClassifier" must subset "client".

  • Reported: UML 2.1 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Section 7.3.45 does indeed make it clear that the specification is the supplier and the implementation is the client. The implementation depends upon the specification; the specification does not depend upon the implementation.

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

Section: 15.3.11

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

    State.stateInvariant should subset ownedRule The stateInvariant property of State currently subsets Element.ownedElement. Given that a State is a Namespace and a stateInvariant is a Constraint, the stateInvariant property of State should subset ownedRule. Likewise, the opposite end of this association should subset Constraint.context instead of Element.owner. This change is needed so that a state invariant has a context and, thus, can be specified using OCL.

  • Reported: UML 2.1.1 — Mon, 30 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

information flow source and target

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

    UML 2.1.1 includes fix - "source" and "target" of InformationFlow are renamed to "informationSource" and "informationTarget".
    These changes are made in diagrams, but not in text under InformationFlow chapter (17.2.1).

  • Reported: UML 2.1 — Wed, 6 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

description of 14.3.24 MessageSort (from BasicInteractions) - typo

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

    On page 495, in the description of 14.3.24 MessageSort (from BasicInteractions) , the definition of createMessage seems not to start on a new line, instead following straight on from the definition of asynchSignal

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

drawing a frame to represent Combined Fragment or an Interaction Occurrence

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

    I seem to remember that when drawing a frame to represent a Combined Fragment or an Interaction Occurrence there is a notation that indicates whether a given lifeline overlapped by the frame is actually covered by the fragment/occurrence or not. I believe that it hinged on whether the frame obscured the lifeline or not. However, I can't find reference to it in the spec. It would be good to have this notation described with an example, to avoid different vendors inventing their own notations.

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is correct that there is no such notation suggested in the standard. The ITU standard Z.120 has a specific notation for lifelines that are not covered by a combined fragment, but we have not included that in UML 2. The reason, I believe, is that it is basically a matter of taste whether you want to include as covered in a combined fragment a lifeline that has no internal fragments (such as occurrence specifications). Disposition: Closed, no change

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

Section: 14 Interactions: Lifeline representing an actor

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

    It is common usage to model a lifeline in a interaction that represents an actor. I can't see how that could be done formally correct. A lifeline represents a connectable element, e.g. a property. It is not allowed to define a property that is typed by an actor.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 9 Composite Structures / Port notation

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

    It is unclear if it is allowed to show the provided and required interfaces of a port in a composite structure diagram (ball and socket notation). That notation is already used for example in SysML. However I can't find the definition of it.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Ball and socket notation is only allowed for Components.

    Revised Text:

    Disposition: Closed, no change.

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

Section: 16.3.2 Classifier (from UseCases)

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

    The notation section of the classifier refers to the standard notation for nested classifiers. 1. I can't find that standard notation in the spec. 2. Nested classifiers are a feature of classes and not of classifiers. It seems that nesting and owning of classifiers is mixed up here

  • Reported: UML 2.1.1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section 18.3.1

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

    18.3.1 – Class claims that it is a merge increment on InfrastructureLibrary::Constructs::Class, when in fig 18.1 it seems that Profile merely imports Constructs rather than merging it.

  • Reported: UML 2.1 — Thu, 24 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9830

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

Section: Common Behavior - isReentrant should default to true

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

    isReentrant should default to true

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

    Having isReentrant default to false, as it currently does, means that, by default, there can be no concurrent invocations of a behavior, nor can a behavior be recursive. This does not seem to be the normal expectation of modelers when they model the invocation of behavior. Rather, the expected default it that behaviors are reentrant-with the ability to declare them not to be if that makes sense.
    On the other hand, it is often the case that, within an activity modeling, for example, a business or manufacturing process, an action invoking a behavior may be locally non-reentrant, in the sense that one invocation must complete before a new one can begin, because there is only a single performer to carry out the action. However, this case is more specifically addressed by Issue 6111. Once this is resolved at the local level, the default for the "global" isReentrant property on Behavior can be allowed to default to true, while "local" reentrancy for actions defaults to false.

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

Actions on non-unique properties with location specified

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

    Actions on non-unique properties with location specified. Clarify what happens in the actions applying to non-unique features / association ends when they specify location and an existing value (eg, RemoveStructuralFeature and Destroy actions) if the value to be acted on is not at the position specified.

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

    Currently, the WriteStructuralFeatureAction and WriteVariableAction superclasses specify a required value input pin, so all kinds of write structural feature actions must have such a pin in all cases. However, when a removeAt pin is required for a RemoveStructuralFeatureValueAction or RemoveVariableValueAction (that is, when the feature or variable is ordered and non-unique and isRemoveDuplicates is false), the expectation is that whatever value is at the given position is removed. Having to provide any value at all is counterintuitive. If the value is ignored, then it is pointless. If the value has to be the same as the value at the given position, then it is extremely inconvenient and redundant to have to read the value at that position just to remove it!
    Therefore, the remove value actions should not have a value input pin in the case they are required to have a removeAt pin. This means that the value input pin should be optional in the write action superclasses, but should then be constrained to be required for the add value actions.

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

Section: Actions - Output of read actions for no values

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

    Output of read actions for no values. In the various read actions (links, structural features, variables), what is the output when there are no values read? Is it a null token or no tokens at all?

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

    Suppose the result output pin of a read action is connected by an object flow to an action with an input pin with a multiplicity lower bound of zero. Assuming the second action has no other inputs or incoming control flows, it still will not fire unless it receives some token on its input pin (note that this semantic interpretation of enabled actions is explicit in the Foundational UML specification). Thus, if the read action produces no token in the case that no values are read, then the second action will not fire, even though its input is optional. In order to ensure that the second action can actually fire with no input values, it would be necessary to also model an explicit control flow from the read action to the second action, which is inconvenient and can lead to ordering and sequencing issues between control and object tokens in the case when the read action does produce values.
    On the other hand, if the read action produces a null token when no values are read, then this will be offered to the second action, which can accept it, since its input multiplicity allows the case of no values. The second action will thus fire with an empty input, as would be intuitively expected. Note that if the second action's input pin had a multiplicity lower bound greater than zero, the semantics would not be effected by the offering of a null token, since this still would not provide the minimum number of values required for the action to fire.
    Therefore, in the framework of the token offer semantics of activities, it makes the most sense for a read action to produce a null token when there are no values to read. Note that this is also consistent with the semantics for call actions implied by the statement in Subclause 12.3.41 that if, at the time an activity finishes execution, "some output parameter nodes are empty…they are assigned null tokens", in which case one would expect the null tokens to be offered by the corresponding output pins of a call action for the activity. That is, call actions should also offer null tokens in the case that an output has no values.

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

Section: Actions - InputPin semantics wording

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

    InputPin semantics wording. In Actions, InputPin, Semantic, second sentence, replace "how many values" with "the maximum number of values that can be".

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

    accepted

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

Section: Activities - Output pin semantics clarification

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

    Output pin semantics clarification. The current semantics for Action says it won't complete without the output pins having the minimum number of tokens, as specified by the minimum multiplicity. It should be clarified that the output values are not put in the output pins until it the action completes, so the tokens already in the output pins are not included in meeting the minimum multiplicity.

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

    agreed

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

Section: Activities - ForkNode semantics wording

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

    ForkNode semantics wording. In semantics of ForkNode, the phrase "keep their copy in an implicit FIFO queue until it can be accepted by the target" should not be different from other situations of ordered offers to refusing targets. In particular, it should be refined to clarify that the acceptance of offers by a fork is the same as acceptance by object nodes in the sense that they can't be revoked once accepted, and that for the edges leading to refusing targets, the offers are standing along those edges in the order they were received.

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

    In general, the ForkNode semantics needs to be more carefully worded in terms of offers of tokens, rather than just the tokens themselves "arriving" at a fork node.

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

Section: Activities - Preserving order of multiple tokens offered.

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

    Preserving order of multiple tokens offered. In Activities, ActivityEdge, when tokens are offered in groups, for example for weight greater than 1, if the source and target are pins, the multiplicity ordering of the source node, if any, should be preserved in the target node.

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

    The real issue is preserving the ordering of offers as made by the source, whether the source is a pin or not. The relationship of multiplicity ordering on pins to the ordering of offers is handled by the resolution to Issue 9860.

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

Bad cross reference for InterfaceRealization Notation

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

    The notation part of Section 7.3.25 says "See Interface(from
    Interfaces)". However this has nothing to do with Realization. The
    cross-reference should in fact be to Realization - section 7.3.45 -
    which does have the notation needed.

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

    No Data Available

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

PrimitiveTypes access by UML (M1) models

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

    UML allows M1-level models to reuse the primitive types defined in the PrimitiveTypes package in the UML Infrastructure (e.g., Integer, String, etc.). Currently, this package is merged into L0 and is not separately accessible and should have its own URI so that it can be imported by M1 models without having to import the UML metamodel.

    This may also mean that instead of merging the package PrimitiveTypes into L0, the package should be imported

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Unclear which Property has aggregation

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

    Where a diagram has a diamond it is not clear which end has the aggregation metaproperty. This can be discovered but only with a lot of detecetive work. For example 7.3.3 states "An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. ". Nothing makes sufficiently clear that, for an aggregate property, that the diamond is depicted at the opposite end to the multiplicity and other annotations for that property.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Move Property::isId from MOF to UML

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

    It is a general requirement to be able to indicate candidate keys in UML models. This should be in Infrastructure (s still usable by MOF) and merged into Superstructure.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Notation for stereotypes on Comments and other elements

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

    Section 18.3.8, Notation, states "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. " However several elements do not have names - for example Comment and LiteralString (the ODM Profile does define stereotypes on the latter).

    SysML contains the following.
    A comment note box may contain stereotype keywords or icons even though Comment is not a named element. UML specifies placement of a stereotype keyword relative to the name of the element. SysML makes explicit that they may appear inside a comment box as well. The stereotype keywords, if present, should appear prior to the comment text. The stereotype properties, if present, should appear after the comment text. The typical placement of stereotype icons is in the upper-right-hand corner of the containing graphical node.
    This approach should be used by UML and generalized for other non-named elements

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9706

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

text-diagram out of synch in Infrastructure 11.4.1

  • Key: UML22-251
  • Legacy Issue Number: 9885
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Bran at the Boston meeting remarked on the practical difficulty of keeping the Infrastructure doc up to date and in synch, text to diagrams and diagrams to underlying xmi.

    This is a report of a place where the text is out of synch with metamodel diagrams in doc.

    reference is to 06-04-03 Infrastructrue v2.1 doc.

    11.4.1 Classifier

    Associations • feature : Feature [*] Redefines the corresponding association in Abstractions. Subsets Namespace::member and is a derived union. Note that there may be members of the Classifier that are of the type Feature but are not included in this association (e.g., inherited features). Constraints No additional constraints Semantics No additional semantics

    Problem here is that Figure 11.16, the Constructs classifier diagram, shows the important general association, Classifier to Classifier, which is not mentioned in the text, needs to be documented under 11.4.1 Associations and probably also Semantics

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Clarify isRequired

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

    18.3.2 the description for isRequired, while technically correct, is somewhat terse and does not make clear that the references to 'multiplicity are to the lower and upper properties of ExtensionEnd

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

definition of 'isCompatibleWith' for ValueSpecification

  • Key: UML22-375
  • Legacy Issue Number: 12251
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The definition of 'isCompatibleWith' for ValueSpecification starts with 'Property::isCompatibleWith[...]', instead it has to start with 'ValueSpecification::isCompatibleWith[...]'.

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

formal definitions of 'isCompatibleWith' (pages 622, 647, 649)

  • Key: UML22-374
  • Legacy Issue Number: 12250
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The three formal definitions of 'isCompatibleWith' start with: 'isCompatibleWith = p->oclIsKindOf(self.oclType) and [...]'. This is wrong, p and self have to be swapped, that is: 'isCompatibleWith = self.oclIsKindOf(p.oclType) and [...]'. Rationale: As defined in the OCL-specification formal/06-05-01, the function 'oclIsKindOf(t)' determines if t is either the direct type or one of the supertypes of the object, on which this function is called. That is, if the function returns true, the type t is a generalization or equal to the type of the current object. The corresponding has to be valid for 'isCompatibleWith(p)': If the function returns true, the type of p has to be the same or a generalization of the type of the object, on which this function is called (otherwise, the constraints [1] of 17.5.4 and 17.5.5 would make no sense).

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. (The operations in question are ParameterableElement::isCompatibleWith, ValueSpecification::
    isCompatibleWith and Property::isCompatibleWith.)
    This also resolves Issue 17870.

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

association 'ownedTemplateSignature' of a Classifier

  • Key: UML22-373
  • Legacy Issue Number: 12244
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    For the association 'ownedTemplateSignature' of a Classifier, 'Subsets Element::ownedElement' is specified. This should be replaced by 'Redefines TemplateableElement::ownedTemplateSignature' (because a Classifier inherits 'ownedTemplateSignature' from its superclass TemplateableElement). Correspondingly, in figure 17.18 '

    {subsets ownedElement}

    ' should be replaced by '

    {redefines ownedTemplateSignature}

    '.

  • Reported: UML 2.1.2 — Wed, 27 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

term 'templatedElement' not defined

  • Key: UML22-376
  • Legacy Issue Number: 12252
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    There are two occurrences of the term 'templatedElement' in the Standard (both in an OCL-expression), but this term is nowhere defined. I propose to replace 'templatedElement' by 'template' on page 629 respectively 'Template::templatedElement' by 'TemplateSignature::template' on page 636.

  • Reported: UML 2.1.2 — Fri, 29 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Usage of "Element::ownedMember"

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

    In the Superstructure spec 2.1.1, there are a few occurences where an
    association end "ownedMember" in metaclass "Element" is referenced.
    This should be changed to reference the end "ownedElement" instead.

    The places I found, are:
    "Class::nestedClassifier"
    "Enumeration::ownedLiteral"
    "DataType::ownedAttribute"
    "DataType::ownedOperation"

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

    According to the metamodel diagrams,

    {subsets ownedMember}

    would refer to the closest inherited ownedMember attribute which would be Namespace, not Element. For example, see figure 7.12.
    Change all references of Element::ownedMember to Namespace::ownedMember.

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

Consistency in description of ends owned by associations

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

    In the Superstructure spec 2.1.1, association ends owned by
    associations between UML metaclasses are not currently described in
    the descriptions of the metaclasses. Only ends owned by the
    associated classes are. In the abstract syntax diagrams, in a few
    cases, ends owned by the associations have labels and/or other
    specifications.

    It is quite confusing to not mention those association ends in some
    places, but to mention them in others. If the end is important enough
    to be described, this should be done consistently. If the end is
    irrelevant enough not to be described, it should consistently not be
    described (and thus be subject to the default naming rules).

    I suggest to establish consistency by determining for each such end,
    whether it is relevant or not to describe it. If it is relevant to
    describe it, then the end should be labeled in the diagrams, and it
    should be described in the metaclass descriptions. Otherwise, the end
    should be unlabeled and have no specifications in the diagrams and
    should not be described in the metaclass descriptions.

    Here is the set of ends owned by associations that is labeled in
    diagrams:
    Figure 7.5: "ValueSpecification::owningUpper"
    Figure 7.5: "ValueSpecification::owningLower"
    Figure 7.6: "ValueSpecification::expression"
    Figure 7.7: "ValueSpecification::owningConstraint"
    Figure 7.8: "ValueSpecification::owningSlot"
    Figure 7.8: "ValueSpecification::owningInstanceSpec"
    Figure 7.10: "ValueSpecification::owningParameter"
    Figure 7.10: "Parameter::ownerFormalParam"
    Figure 7.11: "Constraint::preContext"
    Figure 7.11: "Constraint::postContext"
    Figure 7.11: "Constraint::bodyContext"
    Figure 7.12: "ValueSpecification::owningProperty"
    Figure 7.12: "Classifier::class"
    Figure 7.14: "PackageableElement::owningPackage"
    Figure 7.15: "NamedElement::supplierDependency"

    Here is the set of ends owned by associations that is unlabeled but
    has specifications in diagrams:
    Figure 7.16: The right end of the aggregation between "Property"
    and "Interface" has a "

    {subsets ...}

    " specification.

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

    No Data Available

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

Section: 12.3.30

  • Key: UML22-306
  • Legacy Issue Number: 10818
  • Status: closed  
  • Source: ELIOP ( Ignacio Gonzalez)
  • Summary:

    Figur 12.95 - Fork node example has an error. Instead of: |-> Fill Order Fill Order -->| |> Send Invoice It should be: |> Ship Order Fill Order -->| |-> Send Invoice

  • Reported: UML 2.1.1 — Tue, 13 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Section: 15.3.12

  • Key: UML22-312
  • Legacy Issue Number: 10832
  • Status: closed  
  • Source: Delphi ( Kirk Bailey)
  • Summary:

    The problem is with the definition of the ancestor query on page 559. I believe that the algorithm, as stated, determines whether s1 is an ancestor of s2, not whether s2 is an ancestor of s1.

  • Reported: UML 2.1 — Fri, 16 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This method is testing that s2 is nested within s1, and such s1 would be the ancestor. The method description is therefore wrong and needs to be fixed as suggested.
    Furthermore, the check that s1 has a container has no bearing on whether s2 is contained within it. And the parameters of the function accept states but we are passing the container which will be a region.

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

"PackageableElement::visibility" uses "false" as default value

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

    In the Superstructure spec 2.1.1, the description of
    "PackageableElement::visibility" says: "Default value is false."
    However, "false" is not a valid value for the type "VisibilityKind".

    I suggest that the default visibility be defined as "public". While
    it may make sense for properties in a class to be private by default,
    this is not the case for packageable elements, here it makes way more
    sense to have a public default. The description should be changed
    accordingly.

    Second, the UML Metamodel CMOF files define metaclass
    "PackageableElement" to be a specialization of metaclass
    "NamedElement" without redefining "visibility". However, the
    metaclass description in the superstructure spec does redefine
    "visibility". The CMOF files should be adjusted to make the same
    redefinitions the description makes.

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

    Regarding the first point,.PackageableElement::visibility already has „public? as a default value in the normative CMOF models, so the description in the spec text needs to be corrected as suggested in the issue.
    Regarding the second point, PackageableElement::visibility in the CMOF models already redefines NamedElement::visibility, matching the spec doc, so no change is needed.

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

Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

  • Key: UML22-302
  • Legacy Issue Number: 10778
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Possible Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

    Please clarify the effects of the merge increments of 'Class' on its descendants, esp. on the 'Behavior' subtypes. IMHO the fact that 'behavior' inherits from 'Class (from Kernel)' implies that in turn it does NOT inherit features from 'BehavioredClassifier' or 'EncapsulatedClassifier' even on Compliance level L1. This would mean that e.g. an interaction may not have ownedPorts or ownedBehaviors, but nestedClassifier.

    If this is not the case, please clarify the precedence between the merge and inheritance constructs.
    Example:
    L1 (as seen in Fig. 2.2) merges Kernel, BasicBehaviors and InternalStructures and thus provides the 'Class', 'BehavioredClassifier' and 'EncapsulatedClassifier' constructs simultanously.

    • If inheritance comes before merging (which is what the diagrams suggest), 'Behavior' will have neither ownedPorts nor ownedBehaviors.
    • If merging comes before inheritance (which is what the XSD suggests), 'Behavior' will both have ownedPorts and ownedBehaviors.

    In the second case, the question arises that if even in L1 the three constructs mentioned above are provided, why does 'Behavior' not simply inherit from 'Class (from StructuredClasses)', directly being an EncapsulatedClassifier?

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

    No Data Available

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

Page: 155, 162

  • Key: UML22-301
  • Legacy Issue Number: 10651
  • Status: closed  
  • Source: DMR Consulting ( Jasmin Bouchard)
  • Summary:

    In the notation for ComponentRealization on section 8.3.4 (page 162), it is stated that a ComponentRealization is notated in the same way as a realization dependency, "i.e., as a general dashed line with an open arrow-head". This contradicts the notation presented for Realization in section 7.3.45 (page 133), where it is stated that "A Realization dependency is shown as a dashed line with a triangular arrowhead at the end". If the notation of section 8.3.4 is indeed in error, Figure 8.10 (page 155) should be corrected to use triangular arrowheads, since it is a representation of the realization of a complex component.

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

    Resolution:
    This is a duplicate of 11007 (incorrect arrowhead in text) and 8705 (incorrect fig 8.10).

    Revised Text:
    None.
    Disposition: Duplicate of 8705 and 11007

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

Section: 17/17.5.7

  • Key: UML22-305
  • Legacy Issue Number: 10802
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Missing constraint for template binding in classifier context There seems to be an omitted constraint for template binding in the context of the classifier metaclass on page 667. Indeed, there is no restriction to the kind of template element to which a classifier can be bound. For example, nothing forbids a class to be bound to a data type or association or even an operation defined as template. There is a need for a constraint similar to the one defined on page 57, where it is stated that a classifier can only specialize classifiers of a valid type. Something like, self.templateBinding -> forAll(tb | self.oclIsKindOf(tb.signature.template.oclType)) Note that the variable oclType is not a valid OCL expression, even though it is referenced more than once in the UML Superstructure document (e.g definition of maySpecializeType on page 58). We therefore here assume that the oclType expression returns the associated metatype of the uml element to which it is applied. Thanks in advance for any feedback Jean-Frédéric Etienne

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

    This is covered in constraint [1] of TemplateParameterSubstitution, section 17.5.5.
    Revised Text:
    Disposition: Closed, no Change

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

Port.provided:Interface

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

    ptc/2006-04-02/p187.

    The spec for Port.provided:Interface says: “References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface.”

    This would seem to indicate that a Port typed by an Interface cannot have more than one provided interface. Clarify that this was the intention, or fix if not.

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

    I cannot see how it can mean anything else. This specification was modified in the resolution to 13080 and the meaning is clear there.

    Revised Text:

    Disposition: Closed, no change.

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

Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions)

  • Key: UML22-300
  • Legacy Issue Number: 10650
  • Status: closed  
  • Source: Softeam ( Cédric MARIN)
  • Summary:

    About "8784 - add ReceiveOperationEvent and ReceiveSignalEvent metaclasses" issue, the "ReceiveSignalEvent" (14.3.28 p522) metaclass seems to have the same meaning as "SignalEvent" (13.3.25 p468) and is then redundant. This issue should be resolved by either: - detailing the differences between ReceiveSignalEvent and SignalEvent - removing the ReceiveSignalEvent metaclass

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

    See issue 14629 for disposition

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

Section: 12.3.38

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

    Is "Set of <name>" a keyword? Or is it allowed to write for example "<name>List" or "<name>Container"?

  • Reported: UML 2.1.1 — Fri, 2 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue applies to Figure 15.49 in Subclause 15.4.4 of the UML 2.5 beta specification. Since ObjectNodes
    are not MultiplicityElements, the only way that an ObjectNode can contain a set or other collection is if its
    type is a collection type. Since UML does not provide any standard such types, the notation cannot be fully
    standardized

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

UML2: Actor cannot have ownedAttributes

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

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

    An Actor is a BehavioredClassifier and therefore cannot have ownedAttributes. The constraint above would have to iterate over all the associations in the model and insure that if one ownedEnd is an Actor or UseCase, the other ownedEnd must be a UseCase or Actor respectively.

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

    Agreed. This also resolves issues 13948 and 14875

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

State Machines

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

    Execution semantics of deferrable triggers. The execution semantics of deferrable triggers in the notation section of Transition, under Figure 15.44, conflicts with the semantics given in State. The description of deferrable trigger in the State attribute and semantics sections say a deferred event remains deferred until the machine reaches a state where it is consumed. The notation section of Trigger says the deferred event is lost when the machine reaches a state where the event is not consumed and not deferred

  • Reported: UML 2.1.1 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 18.3.8

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

    The description how values of a stereotyped element can be shown offers three ways. But all of them requires a graphical node. There is no description how to show the values of a stereotyped element that has no graphical notation, e.g. an attribute

  • Reported: UML 2.1.1 — Tue, 20 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution: Duplicate of 9877

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

"Constraint::context" is marked as derived in the metaclass description

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

    In the Superstructure spec 2.1.1, the description of the "context"
    association end in metaclass "Constraint" has the leading slash,
    marking it as derived. This is probably wrong. Besides not making
    much sense for this end to be derived, the following places support
    the view that "context" is meant to be non-derived:

    • The text in the description of the "context" end does not state
      from what or how the end would be derived.
    • In the UML Metamodel CMOF files, the end is not defined to be
      derived.
    • In figure 7.7, the "context" end is shown as non-derived.

    The description of the "context" end in the Superstructure spec
    should be changed to remove the derived-mark (leading slash) from it.

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

    Constraint::context is not derived in the metamodel. See figure 7.7. This is already correct in InfrastructureLibrary.

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

discrepancies between package dependencies and XMI file for Superstructure

  • Key: UML22-222
  • Legacy Issue Number: 9818
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    I verified the alignment between the package dependencies (packageImport and packageMerge) in the XMI file Superstructure.cmof (contained in ptc-06-01-04) and the package dependency diagrams in the convenience document, and noticed some discrepancies. Assuming the XMI file is correct, these discrepancies are: - Part I, Figure 1 (p.19): the packageImports from Classes to CommonBehaviors and AuxiliaryConstructs are missing. - Figure 7.2 (p.22): the packageImport from Dependencies to Kernel is missing. - Figure 9.1 (p.168): the packageImports from Ports to Kernel and Interfaces are missing. - Figure 10.1 (p.202): the packageImport from Nodes to Kernel is missing. - Part II, Figure 1 (p.225): the packageImports from StatesMachines, Activities and Interactions to CompositeStructures are missing. - Part II, Figure 1 (p.225): the packageImport from Activities to StateMachines is missing. - Part II, Figure 1 (p.225): the packageImport from CommonBehaviors to Actions is missing. - Part II, Figure 1 (p.225): the packageImport from UseCases to CommonBehaviors is not correct: it is not present in the XMI file. There only exists a packageMerge relation from UseCases to BasicBehaviors. - Figure 11.1 (p.230): the packageImports from CompleteActions to Kernel and BasicBehaviors are missing. - Figure 11.1 (p.230): the packageImport from IntermediateActions to Kernel is missing. - Figure 11.1 (p.230): the packageMerge from IntermediateActions to BasicBehaviors is missing. - Figure 12.1 (p.309): the packageImports from CompleteActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageImports from IntermediateActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageMerge from BasicActivities to BasicBehaviors is missing. - Figure 15.1 (p.546): the packageMerge from BehaviorStateMachines to Communications is missing. - Part III, Figure 1 (p.631): the packageImport from AuxiliaryConstructs to Classes is missing.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Figure 14.5

  • Key: UML22-224
  • Legacy Issue Number: 9820
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The editorial fix in Figures 14.5 is not carried out: OccurenceSpecification is still abstract, not concrete. Please note that there is no editorial fix planned for, or applied to Figures 14.3 and 14.4. However, in these figures OccurenceSpecification is also shown as abstract. All of the figures pertaining to the package BasicInteractions should at least show the same view of OccurenceSpecification

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Appendix F

  • Key: UML22-223
  • Legacy Issue Number: 9819
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The Classifier taxonomy in Appendix F shows a Generalization from Collaborations::Collaboration (child) to Collaborations::Classifier (parent). This Generalization is not present in the metamodel in Figure 9.6 (p. 172), and I therefore believe it to be in error.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 8.3.1

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

    Fig. 8.12 shows delegate connectors that are directly connected with an interface. According to the metamodell that's not possible. A connector end can only be connected with connectable elements.

  • Reported: UML 2.1.1 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by the changes specified in 8168.

    Revised Text:
    None.
    Disposition: Duplicate of 8168.

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

General ordering cycles

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

    There should be a constraint preventing the definition of general ordering cycles (involving occurrence specifications), as there is with generalizations

  • Reported: UML 2.0 — Tue, 6 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

What exactly is a state list?

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

    The UML2.1 specification defines a state list:

    The special case of the transition from the junction having a history as
    target may optionally be presented as the target
    being the state list state symbol. See Figure 15.27 and Figure 15.28 for
    examples.

    I couldn't map that definition to the example. There is no junction and
    no history state. Can someone
    provide fig. 15.27 in another notation without state list?

    I'm not the first one who's asking this. Probably we should provide such
    an example in the spec.

  • Reported: UML 2.0 — Tue, 30 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 9.14.2

  • Key: UML22-214
  • Legacy Issue Number: 9760
  • Status: closed  
  • Source: Self-Employed ( Steven Coco)
  • Summary:

    The definition of Namespace lists as a generalization, Namespace. This appears to be an error: it appears this is intented to refer to NamedElement.

  • Reported: UML 2.0 — Wed, 24 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 11.1.3

  • Key: UML22-213
  • Legacy Issue Number: 9752
  • Status: closed  
  • Source: Watt Systems Technologies ( Kenneth Lloyd)
  • Summary:

    Element reads "Constructs::Element reuses the definition of Element from Abstractions::Comments." Since this element has been removed should this read "Constructs::Element reuses the definition of Element from Abstractions::Ownerships." as reflected in the merge?

  • Reported: UML 2.0 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Action inputs/outputs

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

    Seeing as Action::input and Action::output are derived compositions that subset Element::ownedElement, all subsets of them should be compositions (I thought Karl had added a constraint to this effect?). In particular, OpaqueAction::inputValue, OpaqueAction::outputValue, AcceptEventAction::result, AcceptCallAction::returnInformation, UnmarshallAction::result should be composite

  • Reported: UML 2.0 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.44

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

    In the defintion of the Property concept, the type of the default attribute is a String. I believe it would be more powerful to type default with ValueSpecification

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

    Actually, Property::defaultValue is a ValueSpecification, which gives what is required. Property::/default is
    a derived string, although its current documentation—“A String that is evaluated to give a default value for
    the Property when an instance of the owning Classifier is instantiated” — is misleading. Property::/default
    only exists at all because of earlier efforts to align superstructure and infrastructure through package merge.
    Its derivation makes no sense for default values that are not strings. Since it is derived, removing it would
    not affect model serialization. Delete it.

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

Section: 7.2

  • Key: UML22-221
  • Legacy Issue Number: 9817
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    In paragraph 7.2 it says: "Figure 7.2 shows the package dependencies of the Kernel packages". However, this should read "...dependencies of the Classes packages." The caption of figure 7.2 is correct.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Page: 64 & 112

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

    The section 7 contains two concepts, ElementImport and PackageImport, that seems to quite redundant. I believe that the semantics of ElementImport covers the semantics of PackageImport. SO, either clarify the difference (if there are?), or delete the PackageImport or make PackageImport a specialization of ElementImport.

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

    No Data Available

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

Completion event modeling

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

    Completion events are an explicit concept in UML statecharts. However, there is no corresponding metaclass either in the Common Behavior section or in Statecharts. Since completion events trigger transitions, it may be necessary to have an explicit CompletionEvent metaclass. For instance, we may want to model an interaction in which execution occurrences are initiated by completion events.

  • Reported: UML 2.0 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Requires the addition of a new meta class. This needs to be postponed to a later revision when we will have more time to investigate this proposal and its impacts.

    Revised Text:
    N/A
    Disposition: Closed, out of scope

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

Editorial bug in 2.1 Superstructure Convenience document

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

    The Convenience document is inconsistent with the resolution with 9087 and itself: the spec shows Package::packagedElement as derived in the Associations section of 7.3.37 whereas it's clearly not in the resolution. Figure 7.14 is actually OK as is the metamodel.

  • Reported: UML 2.0 — Mon, 5 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

7.3.4 Association Class

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

    The specification should state when navigation between an association class and the endpoints of that association class are allowed. When there is an association class between two classes, OCL allows navigation between these classes and the association class itself (see Sections 7.5.4 and 7.5.5 of the OCL 2.0 specification ptc/2005-06-06). However, navigability in UML2 is defined with respect to the metaclass Property and the semantics describe navigability in terms of navigating across an association via a property, i.e., from one endpoint to the other (see the definition of isNavigable() in Section 7.3.44, subsection Additional Operations, and descriptions of navigability in sections 7.3.3 - Association, 7.3.7 - Class, and 7.3.44 – Property.) No mention of navigability to and from association classes is found in section 7.3.4 – Association Class, nor any place else in the specification. One simple possibility would be for navigation involving association classes to respect navigation between its endpoints. For example, if classes C1 and C2 are connected by an association class A, then if one can navigate from C1 to C2 (C1->C2), then one can navigate from C1 to A (C1->A) and from A to C2 (A->C2). Another simple possibility would be to always allow navigation from an association class to its endpoints while requiring navigation from an endpoint to the association class to respect navigability. For example, if the association is one-way navigable from C1 to C2 (C1->C2) then one could navigate from C1 to A (C1->A) and from A to C2 (A->C2) as above and, in addition, from A to C1 (A->C1). Anything more complex than these two simple alternatives requires deeper investigation into the semantics of the UML metamodel or even changing the metamodel. For example, the association ownedEnd: Property for Association in section 7.3.3 could subset Classifier::attribute instead of Classifier::feature. Or in the definition of Association Class in 7.3.4 one could allow the inherited associations ownedAttribute: Property and ownedEnd: Property to overlap, i.e., be non-disjoint, although this may have technical difficulties because these two associations are compositions.

  • Reported: UML 2.0 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2.2 scope statement

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

    Current Scope section in UML 2.1.1 Infrastructure
    =================================================

    This UML 2.1.1: Infrastructure is the first of two complementary
    specifications that represent a major revision to the Object Management
    Group's Unified Modeling Language (UML), for which the previous current
    version was UML v1.5. The second specification, which uses the
    architectural foundation provided by this specification, is the UML 2.1.1:
    Superstructure. The UML 2.1.1: Infrastructure defines the foundational
    language constructs required for UML 2.1.1. It is complemented by UML
    2.1.1: Superstructure, which defines the user level constructs required for
    UML 2.1.1.

    Current Scope section in UML 2.1.1 Superstructure
    =================================================

    This Unified Modeling Language: Superstructure is the second of two
    complementary specifications that represent a major revision to the Object
    Management Group's Unified Modeling Language (UML), for which the most
    current version is UML v2.0. The first specification, which serves as the
    architectural foundation for this specification, is the Unified Modeling
    Language: Infrastructure.

    This Unified Modeling Language: Superstructure defines the user level
    constructs required for UML 2. It is complemented by Unified Modeling
    Language: Infrastructure which defines the foundational language constructs
    required for UML 2. The two complementary specifications constitute a
    complete specification for the UML 2 modeling language.

    Proposed Scope section
    ======================

    This specification defines the Unified Modeling Language (UML), revision 2.
    The objective of UML is to provide system architects, software engineers,
    and software developers with tools for analysis, design, and implementation
    of software-based systems as well as for modelling business and similar
    processes.

    The initial versions of UML (UML 1) originated with three leading
    object-oriented methods (Booch, OMT, and OOSE), and incorporated a number
    of best practices from modelling language design, object-oriented
    programming and architectural description languages. Relative to UML 1,
    this revision of UML has been enhanced with significantly more precise
    definitions of its abstract syntax rules and semantics, a more modular
    language structure, and a greatly improved capability for modelling
    large-scale systems.

    One of the primary goals of UML is to advance the state of the industry by
    enabling object visual modeling tool interoperability. However, to enable
    meaningful exchange of model information between tools, agreement on
    semantics and notation is required. UML meets the following requirements:

    • A formal definition of a common MOF-based metamodel that specifies the
      abstract syntax of the UML. The abstract syntax defines the set of UML
      modelling concepts, their attributes and their relationships, as well as
      the rules for combining these concepts to construct partial or complete UML
      models.
    • A detailed explanation of the semantics of each UML modelling concept.
      The semantics define, in a technology-independent manner, how the UML
      concepts are to be realised by computers.
    • A specification of the human-readable notation elements for representing
      the individual UML modelling concepts as well as rules for combining them
      into a variety of different diagram types corresponding to different
      aspects of modelled systems.
    • A detailed definition of ways in which UML tools can be made compliant
      with this specification. This is supported (in a separate specification)
      with an XML-based specification of corresponding model interchange formats
      (XMI) that must be realised by compliant tools.
  • Reported: UML 2.1 — Thu, 12 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Property::isAttribute() query needs no argument

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

    The Property::isAttribute() OCL query (see p. 133 of 07-02-03) is currently defined to take an argument:

    [4] The query isAttribute() is true if the Property is defined as an
    attribute of some classifier
    context Property::isAttribute(p : Property) : Boolean
    post: result = Classifier.allInstances->exists(c|
    c.attribute->includes(p))

    This argument (p) is not necessary, as the query should be based on the context property. Note that the OCL body for this query does not appear to be correct either.

  • Reported: UML 2.1 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is wrong. Fix it. This also resolves issue 12842.

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

Section: 11.4

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

    The derivation of Classifier.inheritedMember is incorrect: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) The "collect" in that should be "select". I'd also appreciate it if someone could tell me why the spec does not match the l3-merged.cmof here, and particularly, whether the transformation of the above into a query/derivation (by removal of the includesAll) was intentional in the l3-merged.cmof, or just some accident which suggests that the l3-merged.cmof is not up-to-date with the specification .pdf.

  • Reported: UML 2.1 — Fri, 29 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 15267 for disposition

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

Section: 11.4 Classifiers Diagram

  • Key: UML22-329
  • Legacy Issue Number: 11109
  • Status: closed  
  • Source: Department of Computer Science and Technology, Nanjing University ( Zhang, Tian)
  • Summary:

    In "Figure 11.16 - The Classifiers diagram of the Constructs package", the end of the association between Classifier and Feature are named as "/featuringClassifier" and "/feature". But in "11.4.1 Classifier" the Assciations part illustrates the feature without slash. Also, in "11.4.2 Feature" the featuringClassifier is demonstrated without slash neither. According to UML series specifications, "/featuringClassifier" and "/feature" are different from "featuringClassifier" and "feature".

  • Reported: UML 2.1 — Fri, 22 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.10 indicates that Classifier::/feature and Feature::/featuringClassifier are both derived unions. Classifier:: /feature is shown as derived in section 7.3.8 where it is described. Feature::/featuringClassifier is shown as derived in section 7.3.19 where it is described. So there are no issues for Superstructure

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

Actor concept was indeed changed

  • Key: UML22-340
  • Legacy Issue Number: 11200
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The constraints on associations include a condition that an Actor not be associated with a Behavior, which blocks the owned behavior and classifier behavior, but in that case, it is a mystery to me why Actors were made to be BehavioredClassifiers.

    This is not an issue with the consistency or clarity of the spec.
    It is an issue with understanding the use of UML 2 as contrasted with UML 1.n

    The 2.1.1 spec, section 16.3.1, says:

    Changes from previous UML There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have names.

    But a very important change was introducing BehavioredClassifier (there was no BehavioredClassifier in UML 1) , and then making it the generalization of Actor, which gives Actors

    1. ability to own behaviors
    2. ability to have a unique classifier behavior
    3. and own triggers.

    some remarks on the intended pragmatics of this change would make UML spec better.

    Merely citing the change in the "Changes.." section provide accuracy without value, but explaining what use is foreseen for this change, would provide value.

  • Reported: UML 2.1 — Tue, 24 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 13.3.3

  • Key: UML22-339
  • Legacy Issue Number: 11162
  • Status: closed  
  • Source: Patterndigm ( Ben Bovee)
  • Summary:

    In, "Table 12.1 - Graphic nodes included in activity diagrams," the 'Notation' entry for 'ActivityNode' should exclude "ExecutableNode" (unless such an entry is added--or found elsewhere).

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

composite subsets

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

    There are several places in metamodel where non-derived composite property is subset of other non-derived composite property.
    In this case element is owned in two collections, so how it should be reflected in XMI where element could appear just once?
    We can leave element just in subset, and merge collections after load, but is this correct?

    Below are these occurrences:

    classes::mdKernel::Operation::bodyCondition subsets ownedRule

    statemachines::mdBehaviorStateMachines::Transition::guard subsets ownedRule

    classes::mdKernel::Operation::postcondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::postCondition
    subsets ownedRule

    classes::mdKernel::Operation::precondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::preCondition
    subsets ownedRule

    Profile::metaclassReference subsets elementImport

    uml2.1.1::mdProfiles::Profile::metaclassReference subsets packageImport

  • Reported: UML 2.1 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2.1.2: Path names for CMOF files

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

    The (new) path names for the CMOF files, based on the naming proposal that was presented in Brussels, need to be listed next to the bullet points in Appendix H of the UML specification. This change should be made as part of the urgent ballot for UML 2.1.2.

  • Reported: UML 2.1 — Wed, 25 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 7.3.21 figure 7.47

  • Key: UML22-332
  • Legacy Issue Number: 11116
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Figure 7.47 - Power type notation Specific classifier-2 has powertype 'classifier-1' but inherits from PowerType Classifier-2. Should the inheritance lines not point to the 'General Classifier'?

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.21

  • Key: UML22-331
  • Legacy Issue Number: 11115
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Inconsistancy between background fill colouring. Default colour preferences are normally white background, black text, and this issue is then not visible. Changing to a custom colouring to green backgrond, black text, one sees that that some boxes are filled white, whereas others are the same as the selected background colour. Is this intentional? Does this have any semantic meaning? Example in Figure 7.47 (b) Power type notation. The PowerType classifiers use the page background

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Abstractions (02)

  • Key: UML22-337
  • Legacy Issue Number: 11156
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Generalization of Parameter to NamedElement in redundant in Abstractions. Would be easier on serialization to remove the multiple inheritance.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: Constructs

  • Key: UML22-336
  • Legacy Issue Number: 11155
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Package import is defined in the context of Namespace. This has two consequences: 1. Namespaces such as Classe, Node, and UseCase can import Packages. This does not seem to be a good design goal. 2. There is a circular definition between Package and Namespace: Package is a sub-type of Namespace and Namespace requires the definition of Package and PackagedElement.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Namespace URI for Standard Profile(s)

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

    The UML (Superstructure) specification does not define the namespace URI for the standard profile(s) - it should. Note that the currently recommended convention (from p. 703, section 18.3.6 of 07-02-03) for such URIs is

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

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Abstractions

  • Key: UML22-335
  • Legacy Issue Number: 11154
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 14.3.3

  • Key: UML22-341
  • Legacy Issue Number: 11201
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the Notation part of CombinedFragment, in the part 'Presentation Options for “coregion area"' the text refers to Figure 14.12 for an example of a coregion. However, on Figure 14.12 there is no coregion. The reference should be changed to Figure 14.22

  • Reported: UML 2.1.1 — Thu, 26 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Invalid mandatory compositions and associations

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

    I initially thought this just affected chapter 11 and compositions, but the more I looked the wider the impact: this seems quite a systemic problem.

    There are several significant metamodel errors that would prevent population of models in repositories that enforce association semantics. These affect both the diagrams and the metamodel (though I have not checked every association in the metamodel XMI).
    The common problem is metaclasses being shown with multiple mandatory composite owners (i.e. a multiplicity of 1 as opposed to 0..1) next to the black diamond. In some cases this is implicit (the default multiplicity being 1..1, in others explicitly '1'). Since any instance can have at most one composite owner, to have more than one such owner mandatory makes for an 'impossible' (to be valid) metamodel.

    There are non-composition cases where it also does not make sense to have associations mandatory. Often the mandatory nature is implicit (there is not explicit multiplicity shown on the diagrams).

    Here is the list of diagrams and the problematic classes:
    Figure 7.7 Element (not every Element will be constrained)
    Figure 7.8 StructuralFeature (not every StructuralFeature will have a Slot defined for it in some instance model) and Classifier (again not every Classifier will have at least one InstanceSpecification)
    Figure 7.9 NamedElement, Classifier (for redefinedElement, general), RedefinableElement (for redefinedElement, redefinitionContext)
    Figure 7.10 Type
    Figure 7.12 Type (via endType), Class(via superClass), and Property (via opposite, redefinedProperty, subsettedProperty)

    Figure 8.2 Classifier (not every Classifier will realize a Component) and Interface (not every Interface will be both provided and required by at least one Component)

    Figure 10.2 Artifact (inverse of nestedArtifact is mandatory - not every Artifact will be nested in another)
    Figure 10.3 Node (ditto for nestedNode)

    Figure 11.3 InputPin and OutputPin
    Figure 11.4 InputPin and OutputPin
    Figure 11.5 InputPin
    Figure 11.8 InputPin
    Figure 11.13 InputPin
    Figure 11.17 InputPin and OutputPin.

    Figure 11.2 does not have mandatory composition but requires each InputPin (and OutputPin) to be the inputValue of an OpaqueAction which seems quite wrong.

    Figure 12.10 ValueSpecification
    Figure 12.11 ValueSpecification
    Figure 12.13 Constraint
    Figure 12.14 ValueSpecification
    Figure 12.19 ValueSpecification

    Figure 13.12 ValueSpecification
    Figure 13.13 ValueSpecification and Observation (the latter is not a composition error but it seems wrong)

    Figure 14.3 Constraint
    Figure 14.5 NamedElement (again not composition but not every NamedElement should be the signature of a Message)
    Figure 14.7 ValueSpecification

    Figure 15.2 Trigger (there is only one mandatory composition but it makes the optional composition useless since the latter could never be set)

    Figure 17.16 ParameterableElement (not a composition but each ParameterableElement will not be the default of a TemplateParameter)

    Proposed Resolution: mark all the above association ends as 0..1 and update the metamodel accordingly

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

    No Data Available

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

11.3.47 on StructuralFeatureAction (and related sections on subclasses)

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

    Consider a link object that is an instance of an association
    > class that owns its ends. In this case, according to the
    > metamodel, it is the association class that is the
    > featuring classifier of the end properties (owningAssociation
    > subsets featuringClassifier). The properties of the object
    > input pin of a StructuralFeatureAction are determined by the
    > featuring classifier of the feature, which would imply that
    > the object being accessed in the case of an owned feature of
    > an association class is the link object that is the instance
    > of that association class.
    >
    > BUT, the semantics of StructuralFeatureAction say that "If
    > the structural feature is an association end, then actions on
    > the feature have the same semantics as actions on the links
    > that have the feature as an end. See specializations of
    > StructuralFeatureAction" – which is consistent with your
    > claims. This is an inconsistency in the spec. For the
    > semantics to work correctly, the syntactic constraints (on
    > typing of the object, visibility,
    > etc.) would have to be adjusted for the case of an
    > association end owned by an association class.

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    (Note that the StructuralFeatureAction subclause is numbered 11.3.48 in Version 2.2.)
    The issue summary states that "the properties of the object input pin of a StructuralFeatureAction are determined by the featuring classifier of the feature." However, the specification does not actually formally require this. Rather, Subclause 11.3.48 includes instead the following constraint:
    [2] The type of the object input pin is the same as the classifier of the object passed on this pin.
    This statement is actually tautological if the normal typing rules are enforced, and does not place any constraint on the relationship of the type of the object input pin and the featuring classifier of the feature.
    The intent really is that a StructuralFeatureAction for a structural feature that is an association end have the same semantics as for the appropriate link action. The ownership of the association end should not matter. For example, this allows a ReadStructuralFeatureAction to be used to read the navigable opposite end of a binary association, whether that end is owned by the opposite end type or owned by the association itself (in which case the ReadStructuralFeatureAction acts like a ReadLinkAction). This way, the action does not have to be changed just because the model may be updated to change the end ownership - the ability to read the end depends only on its navigability.
    If this is clarified and formalized in the specification, then the above issue becomes moot.

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

Section: 9.16.1

  • Key: UML22-262
  • Legacy Issue Number: 10007
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Double declaration: RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; RedefinableElement::isRedefinitionContextValid (redefined:RedefinableElement):Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)) ) Is the "isRedefinitionContexValid" declaration redundant?

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Appears to have already been fixed. See Additional Operation [2] in section 7.3.46. Editorial note: However the fix has not been applied to Infrastructure.

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

Section: 9.19.1

  • Key: UML22-261
  • Legacy Issue Number: 10006
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of hasVisibilityOf() Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()>collect(c | c.member)>includes ... if (self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true ... should be: if (not self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There is more wrong than suggested in the issue. If you work through the logic of hasVisbilityOf, you end up with a tautology as demonstrated by Ed with the following argument:
    To determine if a.hasVisibilityOf is true, assuming n is private, we need to be able to deduce that (including the proposed change)
    if (not a.inheritedMember->includes) then false else true
    is true, under the constraint that
    a.inheritedMember->includesAll(a.inherit(a.parents()->collect(p | p.inheritableMembers(a)))
    where
    p.inheritableMembers(a) = p.member->select(m | a.hasVisibilityOf(m))
    Clearly, given the above constraint, not a.inheritedMember->includes is true if
    not (a.inherit(a.parents()>collect(p | p.member>select(m | a.hasVisibilityOf(m)))->includes)
    This, in turn, is equivalent to
    not (a.parents().member->includes and a.hasVisibilityOf and a.inherit)
    The conclusion so far is, therefore, that a.hasVisibilityOf is true if the above expression is false, that is, if
    a.parents().member->includes and a.hasVisibilityOf and a.inherit implies a.hasVisibilityOf
    Now, if either a.parents().member->includes or a.inherit are false, then the antecedent in the above implication is false, which means that a.hasVisibilityOf must be false. On the other hand, if both a.parents().member->includes and a.inherit are true, then the implication reduces to the tautology
    a.hasVisibilityOf implies a.hasVisibilityOf
    which is true whether or not a.hasVisibilityOf is true.
    However, it is not apparent why if (not a.inheritedMember->includes) is needed at all. If we simply define hasVisibilityOf as n.visibility <> private, i.e. members are visible in a child if they are not private, we remove the tautology and simplify the logic.

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

Section: 9.12.1

  • Key: UML22-258
  • Legacy Issue Number: 10003
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    In UML Infrastructure version 2.0 formal/05-07-05 p.67 I've found that nonterminal <upper> has the alternative '', but <unlimited_natural> nonterminal range already contains '' as a possible deducible terminal sequence. <multiplicity> ::= <multiplicity-range> <multiplicity-range> ::= [ <lower> ‘..’ ] <upper> <lower> ::= <integer> <upper> ::= ‘*’ | <unlimited_natural>

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Merged Metam.:Property::class with redefinition of non-inherited property

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

    Merged metamodel has Property::class with redefinition of a non-inherited property
    ----------------------------------------------------------------------------------------------------------------------

    In UML 2.1 we have the following:
    Kernel defines Class which inherits from Classifier, and has Class::ownedAttribute of type Kernel::Property.

    Composite Structures also defines Class which inherits from EncapsulatedClassifier which inherits from StructuredClassifier which inherits from Kernel::Classifier (curiously not Collaborations::Classifier in the same section).
    Now StructuredClassifier also defines property StructuredClassifier::ownedAttribute of type InternalStructures::Property

    So in the Merge, we have:
    L3::Class with property L3::Class::ownedAttribute of type L3::Property
    this will inherit from:
    L3::Classifier and L3::EncapsulatedClassifier, with the latter inheriting from L3::StructuredClassifier.
    And L3::StructuredClassifier will continue to have a property L3::StructuredClassifier::ownedAttribute.
    This would be inherited by L3::Class which has its own ownedAttribute.

    Hence there must be a redefinition L3::Class::ownedAttribute redefines L3::StructuredClassifier::ownedAttribute (there is).
    Likewise there must also be a generalization between the 2 associations (there is).

    However there is a change of the property ownership: at the subclass Property::class is owned by Property, and L3::A_ownedAttribute_structuredClassifier::structuredClassifier is owned by the Association.
    And there is no redefinition (or subsetting) between the two.

    Note that Figure 9.2 of ptc/06-04-02 does show a redefinition - but of "_structuredClassifier" with an underscore (not sure what that is supposed to mean).

    Proposed resolution:

    The Property::class property should be owned by the association (but still be navigable), and a redefinition needs to be added in section 9.3.12

    {redefines structuredClassifier}

    .

    Add Property::classifier as a derived union and have all opposites of ?::ownedAttribute subset it.
    This way, access to a property's (owning) classifier can be obtained uniformly - note that a number of the OCL expressions are currently written (incorrectly) with this assumption.

  • Reported: UML 2.0 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Invalid redefinitions introduced into metamodel

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

    There seem to be cases where redefinitions have appeared in the metamodel that were not in the spec. I think something is needed but overall I think subsetting is probably more appropriate for these cases.

    It appears that these redefinitions between non-navigable properties (owned by associations) may have been inadvertently introduced by the tool processing the metamodel before the ends were assigned names. In the first example I suspect that the opposites of DirectedRelationship::target and Generalization::general were detected as being involved in an implicit redefinition because their names were empty (the same). The tool can probably be tweaked to produce a complete list of such redefinitions which we can then itemize and remove to resolve this issue..

    The cause of the second example is the same, but was likely introduced before Package::ownedMember was renamed to Package::packagedElement and never cleaned up.

    For example, in Fig 7.9, the Classifiers diagram, the end opposite to Generalization::general is completely unlabeled. But in the metamodel we have
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_general_generalization-generalization" name="generalization" type="Generalization" association="A_general_generalization" redefinedProperty="A_target_directedRelationship-directedRelationship"/>

    I'm not sure I see the need for a redefinition here - especially when its sibling (Classifier-generalization) is as follows and has no such redefinition:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Classifier-generalization" name="generalization" lower="0" upper="*" type="Generalization" association="A_generalization_specific" subsettedProperty="Element-ownedElement" isComposite="true">

    This has no reference at all to the general Association A_source_directedRelationship - to be consistent I would have expected redefinedProperty="A_source_directedRelationship-directedRelationship. As I mentioned at the start though a subsets seems more appropriate - since the other ends use

    {subsets source}

    etc.

    One that has an additional problem is the following:

    <ownedMember xmi:type="cmof:Association" xmi:id="A_ownedStereotype_profile" name="A_ownedStereotype_profile" general="A_packagedElement_owningPackage" memberEnd="Profile-ownedStereotype A_ownedStereotype_profile-profile">
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_ownedStereotype_profile-profile" name="profile" type="Profile" association="A_ownedStereotype_profile" redefinedProperty="A_member_namespace-namespace"/>

    Here the Association inherits from A_packagedElement_owningPackage but the End redefines A_member_namespace-namespace which is not even a direct member of the specialized Association - and furthermore is a derivedUnion - so we have no real Slot to base the end on. If anything I would have expected a redefine of A_packagedElement_owningPackage-owningPackage

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

    No Data Available

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

Section: 13.2

  • Key: UML22-267
  • Legacy Issue Number: 10081
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    The body property of OpaqueBehavior (as well as OpaqueExpression and OpaqueAction) should be declared not unique. The OpaqueBehavior can be used to store user code and the given language that it was written in. The specifiction identifies the lists of languages and bodies to be ordered (and by default unique). It makes sense for the list of languages to be uniuqe, but not the bodies. For example, consider the user has written the same code but in 2 different languages (say c and c+, or written an identical comment in c and c+ and java). Currently the UML specification disallows one to have the same body even though it may semantically make sense in both languages

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

    Agreed. In addition, the body and language attributes should be ordered

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

Section: 11.3.5

  • Key: UML22-266
  • Legacy Issue Number: 10080
  • Status: closed  
  • Source: ISP ( Leonid)
  • Summary:

    The grammar below is wrong, because there is no rule for the non-terminal <prop-property>. <prop-modifier> should be used instead. <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-property > [‘,’ <prop-property >]* ’}

    ’]

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

    No Data Available

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

navigating from link to link ends

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

    It is not possible to navigate from link to connected instances if slots are not created or Association is not assigned as type.
    Is it possible to create slots in instance of Association even if properties are owned in connected Classes? Are they required? Are they for navigating?

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An InstanceSpecification can have slots for a Classifier corresponding to any of the members that are StructuralFeatures.
    This is deducable from the OCL but not at all clear in the text.
    See also the resolution to 18177 which allows slots to be created for private members and clarifies further
    which features are slottable.
    This also resolves 12912.

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

ExtensionEnd description refers to old use of navigability

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

    18.3.3 second paragraph of description uses the old definition of navigability as implying property ownership

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 9.10.3

  • Key: UML22-260
  • Legacy Issue Number: 10005
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of value association: value : InstanceSpecification [*] should be: value : ValueSpecification [*]

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This appears to have been fixedin Superstructure, The text “value: InstanceSpecification” does not appear in the specification. The property value is typed by ValueSpecification in Superstructure.

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

Section: 9.13

  • Key: UML22-259
  • Legacy Issue Number: 10004
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    MultiplicityElement is derived from itself

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.3

  • Key: UML22-270
  • Legacy Issue Number: 10140
  • Status: closed  
  • Source: Thought, Systems Consulting & Engineering, Inc. ( Marc W George)
  • Summary:

    Use of only the link name as the default for the association name limits the use of both namespace::membersAreDistinguishable() and nameElement::isDistinguishableFrom() operations. The full association name for creating the signature of the element should be at least the concatenation of "memberEndA name - link name - memberEndB name".

  • Reported: UML 2.1.1 — Thu, 24 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Figure 7.31

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

    Figure 7.31 shows the association-like notation for attributes. However this still sues the navigability arrow in the 'old' way. It would be consistent to use the new 'dot' notation to show the class owning the property representing the attribute.

  • Reported: UML 2.1 — Mon, 7 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Annex C.1

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

    Language unit for stereotype create should be named Classes::Dependencies instead of just Dependencies

  • Reported: UML 2.1.1 — Fri, 4 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

StructuredActivityNode [UML 2.1.1]

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

    StructuredActivityNode, based on both common sense and its semantics, requires input and output pins. However StructuredActivityNode::input and StructuredActivityNode::output, both inherited from Action are derived unions and so cannot be used directly. StructuredActivityNode::result is a concrete property but has a special meaning.

    What is needed is some solution that subsets StructuredActivityNode::input and StructuredActivityNode::output but can be used to describe input and output pins of StructuredActivityNode.

  • Reported: UML 2.1.2 — Thu, 8 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The semantics of StructuredActivityNode does, indeed, talk specifically about pins on such nodes. Further, having pins on StructuredActivityNodes is assumed as being allowed in and is required by the Java to UML activity model mapping in the Foundational UML specification. The submitter is correct, however, that the abstract syntax model itself does not seem to explicitly support this.

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

UML2 Issue - 'abstract' not listed in keyword Annex

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

    I just noticed that in formal/07-02-05 section 7.3.8, Classifier, includes:

    An abstract Classifier can be shown using the keyword

    {abstract}

    after or below the name of the Classifier.

    However this is not listed in Annex B of keywords.

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

    Merged with 18454

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

UML2 issue: ProfileApplication treated as Import

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

    Section 13.1.6, figure 13.11 (of Infra) and 18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement “(since profile application is a kind of import)”. However this is not the case: ProfileApplication only inherits from DirectedRelationship.

    To achieve the end effect of the example there seem to be two alternatives:

    a) Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions.

    b) Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.

    This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.

  • Reported: UML 2.1.2 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.

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

context of Constraint

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

    Context of the Constraint is described as derived property

    • / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace.

    However it is not derived in Figure 7.7 - Constraints diagram of the Kernel package.

    So should it be derived or not? One of these places shall be fixed.

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

    See issue 10830 for disposition

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

Section: 18.3.6 Profile (from Profiles)

  • Key: UML22-347
  • Legacy Issue Number: 11343
  • Status: closed  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    In the first serialization example, the memberEnd refers to property 'id4' and 'id5'. This would lead to 2 inconsistencies: 1. the 'id7' is in ownedEnd, but not in memberEnd. This contradicts the subset defined in chapter 7.3.3. 2. there are two candidates for the derived 'metaclass' attribute of 'Extension': id4.type and id5.type. This contradicts the definition in chapter 18.3.2. Instead it should refer to id7 and id5. The correct XMI file excerpt looks like that: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember>

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.33

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

    Figure 7.15 - Contents of Dependencies package There is a rolename supplierDependency that it not defined in §7.3.33 for NamedElement.

  • Reported: UML 2.1.1 — Tue, 23 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    supplierDependency is a non-navigable end and, therefore, cannot be owned by NamedElement. Per the usual style in the UML specification document, non-owned ends are not listed in the documentation for a class.
    Revised Text:
    None.
    Disposition: Closed No Change

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

In section 7.3.12 Figure 7.38

  • Key: UML22-353
  • Legacy Issue Number: 11489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    As described above the Figure 7.38 I think the arrow should point from Car to CarFactory.

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.5 specification, the corresponding figure is 7.19 in subclause 7.7.5. The direction of the
    dependency in the diagram is correct: the CarFactory instantiates Cars and so depends on the Car class, but
    the Car class does not need to depend on CarFactory specifically instantiating it.
    However, the text above the diagram says “the Car Class has a Dependency on the CarFactory Class”, which
    is incorrect.
    This also resolves duplicate issues 12405, 13136, 13947 and 17804.

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

Incorrect word renders sentence meaningless: Chap. 12.3.41

  • Key: UML22-351
  • Legacy Issue Number: 11414
  • Status: closed  
  • Source: Kratzer Automation AG ( Tom Riedl)
  • Summary:

    Incorrect word renders sentence meaningless: Chap. 12.3.41, "Parameter (from CompleteActivities)" Section "Semantics", 1st paragraph, Beginning of last sentence: Suggestion: Replace: "Arrange for separate executions of the activity to use separate executions of the activity..." by: "Arrange for separate invocations of the activity to use separate executions of the activity..."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

The section titled "Changes from previous UML" is not complete

  • Key: UML22-350
  • Legacy Issue Number: 11413
  • Status: closed  
  • Source: n/a ( Brian Arbuckle)
  • Summary:

    The section titled "Changes from previous UML" is not complete "The following changes from UML 1.x have been made: to be written."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

first constraint for CombinedFragment

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

    The first constraint for CombinedFragment:

    [1] If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand.” ..

    should also include the assert operator.

  • Reported: UML 2.1.1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 12.3.1 AcceptEventAction

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

    Figures 12.25-27 show examples of the AcceptEventAction. The actions have an outpin pin which can be omitted in the diagram. But the target actions should show the input pins, e.g. action "Cancel order" needs an input pin "Cancel order request".

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced diagrams are correct as drawn when the edges are interpreted as control flows rather than data flows.
    Revised Text:
    None
    Disposition: Closed, no change

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

RedefinableTemplateSignature

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

    RedefinableTemplateSignature::classifier owns this template signature, so it shall redefine inherited TemplateSignature::template, because it is used for the same purpose and subsets Element::owner.

  • Reported: UML 2.1.1 — Tue, 7 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

ElementImport

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

    Element is restricted to be imported only once (not possible to import the same element into different namespaces).
    I think this is clear bug in Figure 7.4 - Namespaces diagram of the Kernel package
    ElementImport multiplicity (on association between ElementImport and PackageableElement) shall be changed from [1] to [*] (as multiplicity of PackageImport).

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

UML 2.1.1 - fig 7.14

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

    This seems odd to me. The ‘owningPackage’ role of PackageableElement is non-navigable, whereas I would expect it to be navigable so that it is possible from a Packageable Element to find its owner. Interestingly Type, which is a PackageableElement does have a navigable role to its parent, but InstanceSpecification, for example doesn’t.

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

    No Data Available

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

Section: 7

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

    The property isLeaf as inherited by Class from RedefinableElement deals with the concept of redefinition in the context of a classifier. The concept of "this class cannot be subclassed" is missing from UML 2.0 and the current version of UML 2.1. In UML 1.4, the isLeaf property is present in two contexts: Operation and GeneralizableElement. The former refers to the concept of redefinition while the later refers to the concept of subclassing. In UML 2.1, isLeaf from RedefinableElement corresponds to the former. There is nothing corressponding to the later. It is clear from the UML 2.1 specification that redefinition of Classes is related to nesting. In the association class->nestedClassifier between Class and Classifier in Figure 7.12, the source end subsets redefinitionContext. The current constraints for RedefinableElement, Classifier and Class give the following interpretation. Let A be a class with nested class A1, B a class with nested class B1, and B be a subclass of A. Then B1 can redefine A1 as long as A1 has isLeaf = false and A1's visibility is not private. B1 can subclass A1 regardless of the the value of isLeaf on A1. In short, subclassing and redefinition are two separate, orthogonal concepts. The concept of isLeaf for subclassing is not present in UML 2.1.

  • Reported: UML 2.1.1 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In UML 1.5, isLeaf is used in 3 contexts, not two:
    UML 1.5's Operation::isLeaf and Reception::isLeaf in UML 2 correspond to the concept of a redefinable element that cannot be further redefined.
    UML 1.5's GeneralizableElement::isLeaf in UML 2 corresponds to the concept of a classifier that cannot be further specialized in a generalization hierarchy. There are several options to add this capability in UML 2 and the two that are least disruptive to the UML 2 specification are:
    a) Rename RedefinableElement::isLeaf to RedefinableElement::isFinal
    Add Classifier::isLeaf
    b) Keep RedefinableElement::isLeaf
    Add Classifier::isFinal
    c) Keep RedefinableElement::isLeaf
    Add Classifier::isFinalSpecialization
    Option (a) would break compatibility with UML 2.2 in a really bad way because the original meaning of "isLeaf" is now "isFinal" and there is a completely different meaning assigned to "isLeaf".
    Option (b) preserves the UML 2 meaning of "isLeaf" but adds support for the UML 1.x notion of a classifier that cannot be specialized in a generalization hierarchy. However, option (b) creates possible confusion for end users in distinguishing the purpose of isLeaf vs. isFinal.
    Option (c) provides the same advantages as option (b) in addition to providing end users a clue about the role of isLeaf vs. isFinalSpecialization.
    Since option (b,c) represent an upwardly compatible change w.r.t. UML2.2, it is preferred to option (a) which would not only break compatibility with UML 2.2 but also create a lot of confusion in comparing UML 2.2 vs. UML 2.3 models. The rest of this resolution follows option (c).
    Add a property 'isFinalSpecialization' to a Classifier which is the basis for expressing taxonomic relationships among general and specific classifiers.
    Specify a package merge transformation for merging Classifier::isFinalSpecialization according to the principle that a resulting classifier is final if either matching classifier is final.

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

Section: 15

  • Key: UML22-286
  • Legacy Issue Number: 10512
  • Status: closed  
  • Source: fht-esslingen.de ( Dirk)
  • Summary:

    state machines: --------------- I can find a BNF for an behavioral transition but not for a protocol transition. Theres is no explanation why a protocol transition needs the "/" following the trigger. What for is the "/" ? The figure 15.15 on page 521 just shows a protocol trigger but there is no explanation. Wouldn't it be sufficient to write: [pre condition] trigger [post condition] Because of this everyone uses different notations...

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

    No Data Available

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

Section: 15

  • Key: UML22-285
  • Legacy Issue Number: 10498
  • Status: closed  
  • Source: Université de Mons-Hainaut ( Alessandro Folli)
  • Summary:

    The subject of my thesis is "UML MODEL REFACTORING USING GRAPH TRANSFORMATION" and I'm trying to represent UML models using graphs. I have read the "UML 2.0 Superstructure Specification" document and I can't exactly understand which is the region the transitions belong to. On page 553 it defines the container association as "Designates the region that owns this transition.". On page 529 it defines the transition association as "The set of transitions owned by the region. Note that internal transitions are owned by a region, but applies to the source state." I have taken a look to the previous UML specification version. Regions were not present and it defined the relationship between StateMachine and Transition as "Associates the StateMachine with its Transitions. Note that internal Transitions are owned by the State and not by the StateMachine. All other Transitions which are essentially relationships between States are owned by the StateMachine. Multiplicity is '0..*'. " Is it correct if I suppose that all the transitions, excluded internal transitions, are contained by the top-level region? Thank you.

  • Reported: UML 2.0 — Thu, 30 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The owner of a transition does not imply any semantics; therefore a specific owner will not be defined. It is suggested that the LCA of the source and target is used, but it can really be any region that is directly or indirectly owned by the state machine context.
    This resolution also affects the constraint on internal transitions sourcing a composite state. Because the internal transition can be owned by any region (and not necessarily a region that belongs to the source state) the restriction that a state must be composite to have internal transitions is unnecessary. Therefore this needs to be corrected as well.

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

UML 2.1 Spec, Interactions: 14.3.18

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

    I don’t understand why the type of the property ‘InteractionUse.argument’ is Action; I think that there at least needs to be some explanation.

    Also, looking at the syntax for ‘InteractionUse’ in the Notation section:

    “<name> ::=[<attribute-name> ‘=’ ] [<collaboration-use> ‘.’] <interaction-name> [‘(‘ <io-argument> [‘,’ <io-oargument>]* ‘)’] [‘:’ <return-value> <io-argument> ::= <in-argument> | ‘out’ <out-argument>]

    The <attribute-name> refers to an attribute of one of the lifelines in the Interaction.”

    How does the reference to the attribute get stored in the model?

    Finally in Fig 14.18, I don’t see how the notation for the described InteractionUse can be produced from the syntax above, particularly the first part: “:xx.xc=”

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Arguments of InteractionUse shall be ValueSpecifications, as arguments of Message.
    Furthermore introduce a couple of extra attributes/associations to cover the information not easily found today.
    Finally fix the BNF of the concrete textual syntax by a concluding „]?

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

UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse

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

    One of the constraints for this element is:

    [2] The InteractionUse must cover all Lifelines of the enclosing Interaction that appear within the referred Interaction.”

    This needs to be rephrased I think – I don’t see how Lifelines can “appear” in more than one Interaction.

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

A_outgoing_source and A_incoming_target should not be bidirectional

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

    The A_outgoing_source and A_incoming_target associations between Vertex and Transition should not be bidirectional - it's unreasonable to expect that a vertex be changed in order to create a transition to another vertex, considering that the vertices could be in a different model from the transition (especially in the context of state machine refinement). Note that since pseudostates are not redefinable, there is currently no way to redefine a transition that has a pseudostate as its source/target. There should perhaps be separate, derived Vertex::outgoing and Vertex::incoming properties instead.

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2 Superstructure/Components/overly stringent constraints

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

    The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declartion of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.

  • Reported: UML 2.1 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by 7248-7251.

    Revised Text:
    None
    Disposition: Duplicate of 7248 - 7251

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

AcceptCallAction has not operation

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

    In UML2, AcceptCallAction isA AcceptEventAction --> trigger: Trigger --> event: CallEvent --> operation: Operation. In the notation, there's the accept call action in an activity which has a name, and an operation provided by the performer. In the metamodel, this would mean that a Trigger and Event would have to be created to connect an operation to an AcceptCallAction. This is overkill resulting in a complex metamodel and extra work for modelers to create Trigger and Event model elements that are not needed.

    AcceptCallAction should have an operation: Operation property directly. Then a <<trigger>> keyword should be used to indicate the operation is implemented with an AcceptCallAction rather than a method Behavior

  • Reported: UML 2.1 — Mon, 11 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed change would, indeed, simplify the model, but it would be inconsistent with AcceptCallAction being, syntactically and semantically, a subclass of AcceptEventAction. AcceptCallAction is just a special case of triggering based on a call event, with some syntactic conveniences. Any complexity of the metamodel should be hidden by proper tool support.
    Revised Text:
    None.
    Disposition: Closed, no change.

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

Section: 14.3.10

  • Key: UML22-291
  • Legacy Issue Number: 10530
  • Status: closed  
  • Source: Hitachi INS Sosftware ( Toru Arakaki)
  • Summary:

    Old name, "ExecutionOccurences", of "ExecutionSpecification" is still used in the document. Line 14 of the page 465: "ExecutionOccurences are represented ..." Line 22 of the page 465: "Overlapping execution occurrences on the same lifeline ..." Description of Figure 14.15 of the page 465: "Overlapping execution occurrences" Line 18 of the page 463: "An ExecutionEvent models the start or finish of an execution occurrence."

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 14.3.14

  • Key: UML22-290
  • Legacy Issue Number: 10529
  • Status: closed  
  • Source: Hitachi INS Software ( Toru Arakaki)
  • Summary:

    The Notation of the InteractionConstraint is incorrect. A character after "Boolean-expression" should be > not ’. AS-IS: <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’] TO-BE: <interactionconstraint> ::= [‘[‘ (<Boolean-expression> | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9598 for disposition

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

UML2: notation issue

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

    In the spec, some elements have a notation which contain a keyword put in quote like for Abstraction or for Interface. But this keywork does not match the stereotype notation.

    So if I applied a stereotype on such elemen, what is the right notation (see both following examples):

    EX1:

    Ex2:

  • Reported: UML 2.1 — Mon, 29 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: e. g. 12.2. page 287

  • Key: UML22-296
  • Legacy Issue Number: 10594
  • Status: closed  
  • Source: Jens Kuttig - Computer und Medien ( Jens Kuttig)
  • Summary:

    Some elements are black outlined with a white background, some are red outlined with yellow background. Some edges are black, some are red, some are purple. What does the diffrent colors in the diagramms mean? I cannot find any explanation within the document.

  • Reported: UML 2.0 — Mon, 15 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

A_end_role should not be bidirectional

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

    The A_end_role association between ConnectableElement and ConnectorEnd should not be bidirectional - it's unreasonable to expect that a connectable element be changed in order to connect it to another connectable element, considering that the connectable element(s) could be in a different model from the connector. There should perhaps be a separate, derived ConnectableElement::end property instead

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

ReplyAction::replyValue type is incorrct

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

    Section 11.3.43 shows the replyValue attribute of ReplyAction is of type OutputPin. It is shown as InputPin in figure 11.12. The type should be InputPin in section 11.3.43

  • Reported: UML 2.1 — Tue, 30 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was editorially corrected in UML 2.1.
    Revised Text:
    None.
    Disposition: Closed, no change.

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

assembly connectors

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

    Chapter 8.3.2
    An assembly connector is a connector between two components that defines

    that one component provides the services that another component
    requires. An
    assembly connector is a connector that is defined from a required
    interface
    or port to a provided interface or port.

    All constraints are using terms "connector between Interface and Port"
    also.
    I suggest to change or remove this misleading text.

    Agreed. This text is highly misleading in a number of ways:

    (1) It suggests that connectors connect components. They actually connect
    parts typed by components.

    (2) It suggests that connectors connect interfaces – which they do not
    (because only connectable elements can be connected and interfaces are not
    connectable elements).

  • Reported: UML 2.0 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This complaint is handled by other resolutions, primarily 8900 and 9464.

    Revised Text:
    None.
    Disposition: Duplicate of 8900 and 9464.

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

New Issue on multiple guillemot pairs for same element

  • Key: UML22-200
  • Legacy Issue Number: 9577
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 18.3.8 has the following paragraph:

    Presentation Options If multiple stereotypes are applied to an element,
    it is possible to show this by enclosing each stereotype name within a
    pair of
    guillemets and listing them after each other. A tool can choose whether it
    will
    display stereotypes or not. In particular, some tools can choose not to
    display
    “required stereotypes,” but to display only their attributes (tagged
    values) if
    any.

    Annex B has the following paragraph:

    If multiple keywords and/or stereotype names apply to the same model element,
    they all appear between the same pair of guillemets, separated by commas:
    “«” <label> [“,” <label>]* “»”

    These two paragraphs seem to contradict each other, since the annex B does
    not
    allow multiple guillemet pairs for the same element, while 18.3.8 does.

    Proposed Solution:
    Add clarification that Both presentation options should be allowed.

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

    No Data Available

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

11.3.26 OpaqueAction

  • Key: UML22-210
  • Legacy Issue Number: 9710
  • Status: closed  
  • Source: IBM ( Brent Nicolle)
  • Summary:

    11.3.26 OpaqueAction states it has a Generalization: "Pin (from BasicActions) on page 256." This doesn't make sense; pins and actions are very different things. I think figure 11.2 shows the intended Generalization: "Action (from BasicActions) on page 230."

  • Reported: UML 2.0 — Fri, 12 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This was editorially resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed, no change.

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

Definition of stereotype placement requires a name

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

    Section 18.3.8, Notation states: "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element."
    This is too specific and does not state how to notate an element which is unnamed (which could be addressed by referring to where the name would be) or has no name property defined: for example Comment (here a more creative approach is needed).

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

the default for a Property should not be inconsistent with its type

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

    There should be a constraint on Property that the ValueSpecification used for its default should not conflict with its type.
    In some cases, for example if an OpaqueExpression is used, then the type of the value cannot be determined. However if it can then it should not be inconsistent.
    This would, for example require the default for a Integer-typed Property to be an instance of LiteralInteger and not LiteralString or any other LiteralX.

  • Reported: UML 2.0 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    resolved

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

Section: 7.3.10

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

    The description of Constraint mentions the xor-association that is predefined in UML. There's no place in the superstructure (and infrastructure) where that constraint is defined.

  • Reported: UML 2.1.1 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.34 shows an

    {xor}

    constraint attached to two associations, indicating an Account can be a property of Person or Corporation, but not at the same time. Section 7.3.10 Constraint references “xor” constraint as an example of a UML predefined constraint.
    The xor constraint is not explicitly defined in UML. Rather it is used as an example of a constraint between associations as in figure 7.34, and as an example of an expression in section 7.3.18. So the parenthetical remark about xor being an example of a UML predefined constraint in section 7.3.10 should be removed.

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

packagedElement

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

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

ptc/06-01-02:14.3.14, Notation

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

    The following notation expression isn’t well formed:

    <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML's support for null values and semantics is unclear

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

    UML's support for null values and semantics is unclear.
    For example if a Property is defined [1..1] then is a value of null (represented by LiteralNull) permitted? (LiteralNull is defined as "LiteralNull is intended to be used to explicitly model the lack of a value.")
    Can null values be used to create a sparse array? If not how is a fixed length sparse array to be modeled?
    Can a unique multivalued property contain multiple nulls?
    How do the StructuralFeatureActions react in the presence of null?
    [Note that the issue is NOT related to the "null token"]

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML 2/ Super / SendSignalEvent erratum

  • Key: UML22-211
  • Legacy Issue Number: 9718
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A minor issue I stumbled over in UML Superstructure ptc/06-04-02.

    SendSignalEvent [14.3.28] specialises MessageEvent [13.3.18], which
    "specifies the RECEIPT ..." Perhaps that should be reworded?

  • Reported: UML 2.0 — Sat, 13 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter

  • Key: UML22-199
  • Legacy Issue Number: 9556
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    In Infrastructures, since TypedElements::TypedElement is subclassed from Namespaces::NamedElement, is it necessary that BehavioralFeatures::Parameter be subclassed from both TypedElements::TypedElement and Namespaces::NamedElement?

  • Reported: UML 2.0 — Mon, 10 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

"Property::lowerValue" is not a good name

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

    It could easily be taken to mean a constraint on the value not the multiplicity, e.g. for an 'temperature' property, that its value is not allowed to be below -273. Would be better named "lowerBoundValue" or similar.

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Fig 7.14

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

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

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

    Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Datatypes in UML profiles

  • Key: UML22-369
  • Legacy Issue Number: 12224
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
    In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

    --------------------------------------------------------------------------------
    Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
    Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

    It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
    In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

    Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
    owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by
    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
    the other class/metaclass
    (a little side note - I am not sure if this passage is correct - ?metalevel mixing? but this is irrelevant for the issue I am describing)

    --------------------------------------------------------------------------------
    I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

    #1 Enumerations
    #2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
    e.g.

    #3 Completely new primitive types, e.g. Double
    #4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
    e.g.

    #1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
    #2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

    What I am worried about is #3 and #4.
    #3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
    serialized into the XMI.
    Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
    extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
    to be written into the XMI.

    #4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
    However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

    --------------------------------------------------------------------------------
    So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
    semantic variation points or compliance levels here?

  • Reported: UML 2.1.2 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

TemplateSignature / TemplateParameter / StructuredClassifier

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

    Version 2.1.1 2007-02-05 of the spec.

    TemplateSignature p. 625
    parameter : TemplateParameter[] Should mention that it is a derived union of TemplateSignature::ownedParameter ( or show ‘/’ )

    ownedParameter: TemplateParameter[] Should mention that it subsets TemplateSignature::parameter.

    TemplateParameter p. 623

    default : ParameterableElement should mention that it is a derived union of TemplateParameter::ownedDefault ( or show ‘/’ )

    parameteredElement::ParameterableElement[] should mention it is a derived union of TemplateParameter::ownedParameteredElement

    StructuredClassifier p. 186

    There seems to be some discrepency in the spec in regards to Role : ConnectableElement[]. The spec mentions that it is a derived union (it uses the term Abstract union which is inconsistent ) that subsets Classifier::feature. I believe we should have StructuredClassifier::ownedAttribute subsetting StructuredClassifier::role.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

inability to specify ordering of messages connected to gates is problematic

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

    In the 2.1.1 specification (070205):

    Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible.
    In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering.

    The inability to specify ordering of messages connected to gates is problematic.
    __________________________________

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add clarification that Gates are messageEnds which are ordered by the occurrences at the opposite ends of
    the two messages linked by the gate. UML 2.5 already added several clarification on semantics of Gates.

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

The semantics of an assembly connector remains unspecified

  • Key: UML22-372
  • Legacy Issue Number: 12241
  • Status: closed  
  • Source: AdaCore ( Matteo Bordin)
  • Summary:

    The semantics of an assembly connector remains unspecified: it is not possible to understand which port is the source and which port is the target of the data that are meant to "flow" at run-time on the assembly. The specification indeed refer to "required port" to express the semantics of a connector, but the concept of "required port" doesn't exist in UML. The real problem is the following: it is not possible to specify which interfaces provided/required by a port are involved in an assembly. A possible solution could be: - Have a port typed to an interface - Specify if the interface is provided or required using a tag (in a way similar for the direction of SysML FlowPort)

  • Reported: UML 2.1.2 — Wed, 20 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I am not sure that this is really a semantics question. If the semantics are in doubt, that is an issue about connectors in general. I believe this is actually the issue about the ball and socket notation, which is resolved by the changes specified in 8168 and 8900, by restricting the notation to parts with simple ports.

    Revised Text:
    None.

    Disposition: Duplicate of 8168 and 8900.

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

Table 8.2

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

    Table 8.2 should contain graphic paths for - delegate connector - component realization

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Table 8.2 shows the assembly connector which is an element of a composite structure diagram. But table 8.2 denotes elements of a structure diagram. A table for composite structure diagram elements that are specific for components is missing.
    The heading of table 8.2 is incorrect. The table doesn't show nodes, but paths.

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

UML2: Missing ActionOutputPin

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

    UML2 Activities support two different approaches for exchanging data between actions: "push semantics" of token passing over ObjectFlows and "pull semantics" of typical programming languages using ActionInputPins or ValuePin. The fromAction of an ActionInputPin could be a ValueExpression that references a Variable of the Activity or StructuralFeature of the context Classifier. However, support for pull semantics is incomplete. The first issues is 9247 where there is no ReadParameterAction or WriteParameterAction to support pull semantics for Activity Parameters. These Actions should be provided so that ActivityParameterNodes are only needed for ObjectFlows allowing the Activity Parameters to be directly referenced for pull semantics. This would also allow Parameters, Variables and StructuralFeatures to be all handled the same way.

  • Reported: UML 2.1.2 — Mon, 7 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Despite the misleading title, this issue appears to be essentially a duplicate of issues 9247 and 8470. It looks like the text in this issue was just introductory to that of issue 12162, and was incorrectly made an issue of its own.
    Revised Text:
    None.
    Disposition: Duplicate

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

The spec needs to clarify the isConsistentWith() method for transitions

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

    In the 2.1.1 specification (070203) states on page 583/732 (or pg.569), it states:
    [1] The query isConsistentWith() specifies that a redefining transition is consistent with a redefined transition provided that
    the redefining transition has the following relation to the redefined transition: A redefining transition redefines all
    properties of the corresponding redefined transition, except the source state and the trigger.

    This restriction seems a little harsh. Consider the use case:
    1) a user has a state machine, in a top level abstract class, and there exists a transition between two states with no triggers.
    2) the users expect to add triggers to the transition in the concrete sub class state machines. (i.e. redefine in the sub class context and add a trigger)

    The way the above constraint is written does not allow new triggers to be added to redefined transitions. I am requesting a clarification point that will state that new triggers can be added to the redefined transition.

  • Reported: UML 2.1.2 — Fri, 4 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 6395

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

paragraph on "deferred events" on page 552

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

    Towards the bottom of the page there is a paragraph on "deferred events". This appears to be a holdover from UML 1.x, as the current specification speaks of "deferred triggers" (see p.550). Adjust this paragraph to match the current abstract syntax. Similar changes must be made to the corresponding paragraph on p.554.

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

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

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

Section 14.3.19

  • Key: UML22-366
  • Legacy Issue Number: 12195
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the description of Lifeline the coveredBy association has a multiplicity of [0..1]. However, in Figure 14.4 the multiplicity is *, in the XMI it has also * as upper bound, and the text talks also about multiple InteractionFragments ("References the InteractionFragments in which this Lifeline takes part").

  • Reported: UML 2.1.2 — Thu, 24 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Figure 7.6

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

    Figure 7.6 should show properties body and language of OpaqueExpression as multivalued i.e. [0..*].

  • Reported: UML 2.1.2 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 12

  • Key: UML22-359
  • Legacy Issue Number: 11763
  • Status: closed  
  • Source: Student at Technische Universität Braunschweig ( Stefan Schulze)
  • Summary:

    The constraint [2] in section 12.3.5 on page 325 ("Activity edges may be owned only by activities or groups") of class ActivityEdge seems to be contrary to the fact that inGroup - the only reference between edge and group - is a simple association but no composition or aggregation. According to figures 12.5 and 12.6 I would think, that edges are always owned by activities (composition) and referenced by groups. There is no composition or aggregation that specifies, that edges can be owned by groups. (http://groups.google.de/group/UMLforum/browse_thread/thread/bdd07d113676a41f/20b33a18f90db3d9?#20b33a18f90db3d9

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

15.3.14: This paragraph refers to signal and change events

  • Key: UML22-368
  • Legacy Issue Number: 12218
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    This paragraph refers to signal and change events, but should refer to signal and call events: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and change events (see “ChangeEvent (from Communications)” on page 435), the <assignment-specification> ... Instead it should read: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and call events (see “CallEvent (from Communications)” on page 434), the <assignment-specification> ... ChangeEvents don't even have an assignment specification, but signal an call events do.

  • Reported: UML 2.1.2 — Fri, 8 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 8.3.2 Connector

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

    In fig. 8.12 on page 153 the delegate connector points directly to an interface or from an interface on the right side. According to the connector definition in 9.3.6 and 8.3.2 it is not allowed to do that. In addition such a notational variant is nowhere described.

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

UML 2.1.1 Issue: Invalid association end in Figure 7.20

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

    The non-navigable (as indicated by the X) association end typed by classifier ‘B’ in figure 7.20 of 07-02-05 is invalid, since the classifier – not the association – owns that end (as indicated by the dot notation as described on page 42)… recall that an association end owned by a classifier (and not the association) is implicitly navigable.

  • Reported: UML 2.1.2 — Tue, 22 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 17.5

  • Key: UML22-275
  • Legacy Issue Number: 10347
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Is it possible in UML 2.0 specification to define a formal template parameter, for which the actual parameter to be given during parameter substitution is not a classifier but an instance of a specific classifier (more precisely, an instance of a specific class). If this is possible, what should be the type of the parameterable element exposed by the formal template parameter?? Does it have to be of type InstanceSpecification (or even ValueSpecification) to indicate that we are expecting an Object as actual parameter?? Moreover, what should be the type of the parameterable element to be exposed as actual parameter to indicate that we are providing a specific instance or value?? Finally what should be the proper notation for such template parameter to make the distinction with classifier template parameter??

  • Reported: UML 2.0 — Fri, 15 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    InstanceSpecification is not a ParameterableElement, so it cannot be used as a TemplateParameter. Providing a specific instance to a part would be done by assignment, not template bindings. See WriteStructuralFeatureAction.
    Revised Text:
    Disposition: Closed, no Change

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

UML 2 state machines / entry point outgoing transitions

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

    In section 15.3.8 of the of the UML spec 06-04-02.pdf on page 563 it says:

    An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region.

    I believe that the intent was to say "at most a single transition", since it is possible that no transition exists as well as having multiple outgoing transitions (with guards) in each region.

  • Reported: UML 2.1 — Wed, 30 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is correct that entry points do not 'have' to have an outgoing transition. Updating the text is appropriate.

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

Page 60 of the pdf

  • Key: UML22-278
  • Legacy Issue Number: 10356
  • Status: closed  
  • Source: Queen's Unioversity ( Juergen Dingel)
  • Summary:

    Page 60 of the pdf (41 in the doc), right above Figure 7.19:

    • replace "also shows umambiguously that end B is owned by BinaryAssociationAB"
      by "also shows umambiguously that endB is owned by BinaryAssociationAB"
  • Reported: UML 2.1 — Wed, 20 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The is a space between end and B. end B should be endB.

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

UML2: Parameter::isException overlaps with Operation::raisedException

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

    Section 12.3.41 in CompleteActivites extends Parameter with an isException property. Operation also has property raisedException. The relationship between parameters with isException true and the operation's raisedExceptions is unclear. Is it the intention that Parameter::isException is a notation for indicating the exceptions raised by an operation. If so, then it should be in Basic where raisedException is introduced and constraints need to be added to ensure these parameters are not included in the operation's ownedParameters, and are include in the operation's raisedException. See also Issue 9406: UML2: No notation for indicating Operation::raisedException. Hopefully this is not the case because it mixes parameter and exceptions together and results in redundancy in the metamodel.

    It is possible isException was added so Activities could have an ActivityParameterNode to output exceptions. But this did not get completely integrated with the rest of UML2. I will raise an issue for this too. Perhaps there should be ActivityExceptionNodes that correspond to an operation's raisedExceptions instead of mixing parameters with exceptions.

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

    No Data Available

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

uml.xsd schema file in ptc/2006-04-05 is not correctly generated

  • Key: UML22-279
  • Legacy Issue Number: 10376
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    New ISSUE on UML 2.1 Schema File

    Source: Tom Rutt (Fujitsu)

    Criticality: URGENT

    Problem Description:

    The UML 2.1 RTF Final report cites the following supporting
    documents:

    ptc/2006-04-02 Unified Modeling Language: Superstructure
    ptc/2006-04-03 Unified Modeling Language: Infrastructure
    ptc/2006-04-04 Unified Modeling Language: XMI specifications
    ptc/2006-04-05 Unified Modeling Language: XSD specifications

    The uml.xsd schema file in ptc/2006-04-05 (which is an
    informative document) is not correctly generated.

    In particular, several of the enum values specified in this
    schema have prefixes attached, which are not specified in the
    Meta Model. For example, the visibilityKind enumeration has its
    values improperly prefixed by the string “vis_” ( vis_public, vis_private …).

    This has caused interoperability problems with existing tools,
    since some of them have used the incorrectly generated xsd file for
    uml There is a need to post a corrected uml 2.1 schema on the document server.

    Also, the OMG document references for the supporting xmi and
    schema files are not up to date in the superstructure specification.

    Proposed Solution:

    Post properly generated schemas in a new UML 2.1 XSD Specification
    file on the server.

    Post an updated version of the UML 2.1 RTF report which refers to
    the correctly generated UML XSD specification file.

    The Document references cited in Annex G of the UML 2.1
    superstructure spec should be corrected to point at the most up
    to date and correct specifications.

  • Reported: UML 2.1 — Thu, 28 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

UML2: ReadSelfAction with a context cannot access behavior owned attributes

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

    Section 11.3.36 ReadSelfAction, Semantics indicates ReadSelfAction returns the context classifier for a behavior if the behavior has a context, otherwise it returns the behavior itself. This special case should be removed. ReadSelfAction should always result in the behavior. Otherwise if a behavior has a context classifier, there is no action available to access the structural features of the behavior. Having ReadSelfAction always result in the Behavior provides access to both the Behavior's ownedAttributes as well as those of the context classifier. If ReadSelfAction is the context classifier, then only its properties can be accessed.

  • Reported: UML 2.1 — Sun, 5 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Duplicate of issue 8016.
    Revised Text:
    None.
    Disposition: Duplicate

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

Activity shape

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

    would like to shed some light on Activity notation (symbol) as such (Figure 12.33 in ptc/2006-04-02).
    Is it just alternative notation of Activity Diagram Frame or this symbol is intended to use in Activity diagrams as sub parts of other Activity?

  • Reported: UML 2.0 — Wed, 12 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

12.3.27 ExpansionRegion

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

    Typo in paragraph Presentation options on page 385: insert blank between "12.85" and "maps".

  • Reported: UML 2.1.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This seems to have already been corrected in UML 2.2 as an editorial change.
    Revised Text:
    None
    Disposition: Closed, no change

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

12.3.26 ExpansionNode

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

    Specify constraint that a expansion node can have a regionAsInput and a regionAsOutput, but not both at the same time.

  • Reported: UML 2.1.1 — Tue, 1 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Meaning of Constraint visibility

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

    Constraint inherits visibility from PackageableElement but there is no
    description of what it might mean for a Constraint to be more or less
    visible.
    One option would be to constrain Constraint::visibility to be a specific
    value

  • Reported: UML 2.1 — Thu, 5 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7.3.38

  • Key: UML22-280
  • Legacy Issue Number: 10379
  • Status: closed  
  • Source: St. Petersburg State University ( Iskander Absalyamov)
  • Summary:

    visibility default value cannot be false

  • Reported: UML 2.1.1 — Mon, 30 Oct 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10831 for disposition

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

Section: 12.3.2 Action

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

    Semantics, rule [2] "If multiple control tokens are available on a single edge, they are all consumed." How does this rule fit to the rule that the default weight of an edge is 1. If multiple control tokens are available only one of them can traverse the edge to the target node

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

    No Data Available

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

redefined properties

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

    I believe that Port should subset Property::redefinedProperty to include Ports since Ports are Properties

  • Reported: UML 2.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE-

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

    Change all references to UML 2.1 in the Infrastructure and Superstructure documents to UML 2.1.1

  • Reported: UML 2.1 — Thu, 12 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Activities - Pin ordering semantics

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

    Pin ordering semantics. In Activities, InputPin, OutputPin, the semantics of ordering inherited from ObjectNode should be related to multiplicity ordering inherited from MultiplicityElement. For example, if an output pin of ReadStructuralFeatureAction has an object node ordering of FIFO, and the structural feature is ordered (which means the multiplicity ordering of the pin is also), then perhaps the multiple values posted by a single execution of the action should be drawn from the pin in the same order as in the structural feature. Since the action will post the values to the output pin at the same time, currently FIFO ordering on the pin will be indeterminant

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

    Add text below.

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

Section Activities: Default weight

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

    Default weight. In Activities, ActivityEdge, Assocations, the default weight should be unlimited . For example, a ReadStructuralFeatureAction of a mult-valued attribute might produce multiple tokens, which flow to the input of an AddStructuralFeatureAction. Do not want the values to be input to separate executions of AddStructuralFeatureAction

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

    The spec says weight determines the minimum number of tokens that must traverse the edge (offers accepted by target) at the same time. And it requires any tokens offered above the minimum to be taken at the same time:
    When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once.
    So the default can remain 1 for the example.
    Revised Text:
    None.
    Disposition: Closed No Change

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

text of specs and corresponding XMI specs should be clarified

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

    The relationship between the text of the specs and the corresponding XMI specifications should be clarified to explicitly state that, in cases of disagreement between the text and the XMI, the latter takes precedence.

  • Reported: UML 2.0 — Thu, 22 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Put a paragraph into clause 2 to clarify this

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

UML 2: "isLeaf"

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

    The "isLeaf" attribute of Class implies that there cannot be any subclasses of a class, but there is no corresponding OCL constraint that enforces that.

    Also, "isLeaf" is only defined in the Superstructure and not in the Infrastructure – should it be defined in the Infrastructure as well?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The meaning of the 'isLeaf' attribute changed from UML 1.x to UML 2.x
    In UML 1.5 (formal/03-03-01), 'isLeaf' is a property defined in two contexts:

    • In GeneralizableElement (see 2.5.2.23) where it "specifies whether the GeneralizableElement is a GeneralizableElement with no descendents. True indicates that it may not have descendents, false indicates that it may have descendents (whether or not it actuallyhas any descendents at the moment)"
      The fact that the UML 1.5 concept of a leaf in a generalization hierarchy has no equivalent in UML 2.2 has been raised as a separate issue from this - see issue 10515.
    • In Operation (2.5.2.30) where "if true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden)."
      The UML 1.5 concept of a non-overridable operation corresponds to the UML 2.2 of RedefinableElement::isLeaf (see 7.3.46)
      The second part of this issue, i.e., whether the UML 2.2 infrastructure (formal/09-02-04) needs a capability for modeling a specialization leaf in a redefinition hierarchy is a strategic issue out of scope for the UML2 RTF.
      See resolution to issue 12532 for the OCL constraint enforcing the meaning of isLeaf in the context of redefinitions.
      Disposition: Closed No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14 Transition

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

    In section 15.3.14, Transition, subsection Constraints you will find the following constraint: [6] An initial transition at the topmost level (region of a statemachine) either has no trigger or it has a trigger with the stereotype “create”. ... OCL body for constraint ... The element to be stereotyped in this constraint is a Trigger. If you look in Appendix C: Standard Stereotypes you will not find this stereotype. It appears that this constraint is left over from UML1.4/1.5. In UML 1.4 the corresponding stereotyped element in this constraint was an Event. In particular it was a CallEvent. The corresponding <<create>> stereotype is listed in Appendix C as a retired stereotype. So, either the constraint should be deleted or the stereotype must be brought out of retirement.

  • Reported: UML 2.0 — Wed, 14 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 7

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

    In UML2, it is possible to describe user defined datatypes and propertis may typed by this typed. But, nothing has been defined in the UML2 specifcation to be abble to describe values (of slots for example) which has to be conform to a datatype. One could add a new metaclass (for example, DataTypeValueSpecification inheriting from ValueSpecification) in the Expression package to be abble to denote datatype values. And to define the underlying notation.

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

    Merged with 15248

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

Figure 7.4 invalid redefines

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

    This contains an unnamed property that

    {redefines _namespace}

    . There is
    no property _namespace and the redefining property should be should be
    named.
    In Infra there is no such redefinition in Figure 11.21- is it actually
    needed?

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

    No Data Available

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

EnumerationLiteral should constrain InstanceSpecification

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

    EnumerationLiteral currently inherits from InstanceSpecification.
    However it does not make sense for it to have all the capabilities of
    the latter, for example Slots.
    Therefore a constraint should be added to EnumerationLiteral as follows:
    slot.isEmpty
    Furthermore it does not make sense for EnumerationLiteral to have a
    separate classifier than its Enumeration. So the following redefinition
    should be added:
    enumeration

    {redefines classifier}

    (alternatively if this is felt too complex there should be a constraint
    {classifier.isEmpty)

    Another option would be for EnumerationLiteral to inherit from
    ValueSpecification - as suggested by the name of the class (other
    Literal classes are subtypes of ValueSpecification). However this would
    probably be too major a change to justify the benefit.

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

    No Data Available

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

Stereotype attributes inherited from Class

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

    What is the interpretation of the various atttributes that Stereotype inherits from Class, such as "isLeaf" and "isAbstract"? Do they mean the same thing, or are they inapplicable, or subtly different?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 12.3.8

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

    Section Associations of ActivityNode: /inGroup:Group[0..*] Groups containing the node. should be /inGroup:ActivityGroup[0..*] Activity groups containing the node.

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

    agreed

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

Section 11.4.1 "Classifier" (in Constructs)

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

    The description says: "Constructs::Classifier merges the definitions of Classifier from Basic and Abstractions."
    a) The "Abstractions"package is not supposed to be merged by Constructs.
    b) There is no Basic::Classifier, so this reference is probably in error. There is Basic::Class, though.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Notation (p 154, formal/05-07-04 )

  • Key: UML22-228
  • Legacy Issue Number: 9825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I observed some minor errors on Document formal/05-07-04 while reading it, but
    there is an aparent inconsistence that must be checked. I will explain it
    below.

    On page 154 we can read:
    "Notation
    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 on page 125 we can read:
    "A Realization dependency is shown as a dashed line with a triangular arrowhead
    at the end that corresponds to the realized element."

    It's clear that the error is on page 154 definition

  • Reported: UML 2.0 — Tue, 13 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section 11.4.1 "Classifier" (in Constructs)

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

    The association "feature" is not marked as a derived element, but probably should be.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section 10.2.1 "Class" (in Basic)

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

    "ownedAttribute", "ownedOperation" and "superClass" are listed as attributes, but they probably should be listed as associations

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: 15.3.12

  • Key: UML22-236
  • Legacy Issue Number: 9839
  • Status: closed  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    If there are multiple enabled internal transitions within the active state, should they all be fired? The standard suggests that they should all be fired, but is this done in practice? For example, consider the case of two internal transitions within the same state, triggered by the same event, with no guard condition. If that event occurs, will both transitions fire?

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

    Merged with 9840

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

Section: 7.3.7

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

    Incorrect specification of association Class::nestedClassifier. The specification of the association Class::nestedClassifier, section 7.3.7, page 46 states that it subsets Element::ownedMember. The Class Element does not have an association ownedMember. Element does have an association ownedElement, but that is not likely correct because a nested classifier is really a namedElement. Most likely, Class::nestedClassifier should subset Namespace::ownedMember.

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

    See issue 10829 for disposition

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

AssociationClass is severely underspecified

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

    It is not at all clear which Properties will result on both the AssociationClass and the end Classes. The Semantics section of 7.3.4 says nothing more specific than "The semantics of an association class is a combination of the semantics of an ordinary association and of a class." - without saying anything about how they are combined. neither is there any indication as to how to access the attributes of the AssociationClass.
    One specific issue is that the composition property is inherited twice: ownedEnd and ownedAttribute - with no redefinition or subsets relationship between them.
    Neither is anything said about the effect of navigability.

    Proposed resolution:

    AssociationClass should redefine ownedNavigableEnd

    In the example in 7.3.4 the following properties will result. C: indicates here that C owns P via the Class:ownedAttribute property. In this case both ends are owned by the class not the association (though the absence of dots at the line ends would imply otherwise - the example should be redrawn).
    Several extra properties are implied by the diagram and have to be implicitly created by the tool. These are marked !! below.

    Person::company: Company[1..*] association=Job
    !!Person::job: Job[1..*] // This then allows access to the properties of Job such as Salary. Note that Person::job.association isEmpty

    Company::person: Person[*] association=Job
    !!Company::job: Job[*]

    Job::salary: Integer[1]
    !!Job::person: Person[1]
    !!Job::company: Company[1]
    Job.memberEnd=(Person::company, Company::person)
    Job.ownedEnd->isEmpty=true

    There needs to be a discussion and clear rules for the invented names for the new properties and constraints to avoid clashes. Also need to address issues related to unions/subsets/redefines/navigability and their effect on the implicit properties.

    Also there is a complication if the Association class itself has further associations: how in the metamodel are these Properties on t he AssociationClass distinguished from the 'main' Ends representing the line to which the AC is attached.

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

    For explanations, see "Changes from previous UML" below. The OCL in this resolution is written according to OCL 2.1 ptc-09-05-02. Where the changes in the revised text pertain to metaclasses in the superstructure merged from InfrastructureLibrary::Core::Constructs which is the resulting package of merging several package increments from InfrastructureLibrary::Core::Abstractions as specified in clause 11.2 of the UML 2.2 Infrastructure, then the revisions described below have to be similarly reflected in InfrastructureLibrary::Core::Constructs (i.e. the resulting metaclass) and in the metaclass increments merged from the sub-packages of InfrastructureLibrary::Core::Abstractions.
    The revised text clarifies that owned ends of an association class, as an association, are disjoint from owned attributes of that same association class.. Navigability for association classes is the same as associations. Navigation from instances of association classes to their end objects, and any other unaddressed aspects of the issue, will be refiled as a separate issue.
    This resolution includes an OCL constraint which depends on the OCL 2.1 revision:
    context AssociationClass
    self.A_general_classifier::classifier
    ->forAll(oclIsKindOf(AssociationClass))
    The meaning of this constraint is as follows:
    self.A_general_classifier::classifier
    This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*].
    That is, it provides the set of classifiers that specialize 'self'.
    See 7.5.3 (Properties: AssociationEnds and Navigability), p. 18-19 in OCL 2.1 http://www.omg.org/cgi-bin/doc?ptc/09-05-02

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

Show an example of correct notation for the metamodel

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

    Though section 6.5.2 explains and justifies the convention (in the UML2 spec only) for use of navigability arrows to represent property ownership, it would be worth showing a non-normative example of one of the metamodel diagrams with the correct 'dot at line end' notation used. This depends on the resolution to issue A) above.

    C) Use the new 'dot' notation in examples
    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.2
  • Disposition Summary:

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

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

Page: 338, 339

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

    The fork node does not provide tokens to outgoing edges with a guard that evaluates to false. Actions with more than one outgoing edge have a implicit fork semantic. It is unclear if a token is provided to edges with false-guards. The specification defines on page 339: "The guard must evaluate to true for every token that is offered to pass along the edge." Does the token exist if the guard evaluates to false? Does the token wait until it evaluates to true? The evaluation is done at runtime. At which time exactly? While offering tokens or all the time during activity runtime?

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

    Discussion
    In the UML 2.5 beta specification, in Subclause 15.2.3, under “Activity Edges”, it states: “An ActivityEdge may have
    a guard, which is a ValueSpecification that is evaluated for each token offered to the edge.” In 15.3.3, under “Fork
    Nodes”, it further states: “Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node.” Thus,
    the guards on outgoing edges are evaluated when the tokens offered to the ForkNode are offered to them. Finally, the
    specification notes: “Any outgoing ActivityEdges that fail to accept an offer due to the failure of their guard, rather
    than their target, shall not receive copies of those tokens.” So, outgoing edgeswith guards that evaluate to false do not
    receive tokens and therefore do not offer them downstream.
    Disposition: Closed - No Change

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

Optional name attribute in NamedElement is misleading and insufficient

  • Key: UML22-184
  • Legacy Issue Number: 9256
  • Status: closed  
  • Source: Borland Software Corporation ( Stephen Palmer)
  • Summary:

    find it very unintuitive that the name attribute of a NamedElement is optional and If specified may be any valid string, including the empty string. A more accurate name for an element that has the capacity to have a name but does not necessarily have one would be, NameableElement instead of the misleading NamedElement.
    However, elements that do not have a name (or that have a name comprising solely of the empty string or white space characters) have no means through which a human can precisely reference them other than through their physical location on a diagram. This leaves open an opportunity for ambiguity in referencing elements and possible mis-communication. For this reason, the name attribute of NamedElement should be required, should not be allowed to contain just the empty string or just white space characters and should be unique within the element's package. In practise, even an artificially generated name for an element is preferable to no name at all.

    The question of whether the name of an element should be displayed on a particular diagram is a completely different subject and should, in general, be a decision made on a case-by-case basis by the modeller. However, even when the name is not displayed on a diagram, requiring elements to have a readable name provides tool-makers with opportunities to show the name of the element in tool tips, status bars, model navigation panes, etc so that the element can still be readily identified and precisely distinguished from others by human users of the model.

    It is very common in many organizations to have both a short name for an element and a longer more descriptive name for an element. For example, a use case may have the short name UC-OP0001 and a longer name 'Place Order'. The current NamedElement has no provision for such a scheme. In practise, it would be frequently very useful NamedElements had an optional longer name as well as a required short name attribute. Whether the short or long name (when provided) are used on a particular diagram or in any other context is again a matter for the modeller and tool-makers.

  • Reported: UML 2.0 — Fri, 20 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The use of NamedElements with no names is well established in a number of cases in UML. Tools can provide all the
    advantages described by the issue author if the modeler gives a NamedElement a name, but it is more convenient to
    allow the modeler the choice of whether to do that.
    Disposition: Closed - No Change

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

UML 2 Super / Components / connectors to interfaces

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

    In chapter 8 there are several references that indicate that a connector can be drawn between two or more interfaces. This is not possible, since an interface is not a connectable element.

  • Reported: UML 2.0 — Tue, 21 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed so. The revised text below corrects this.

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

reference to Figure 12.87 missing

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

    Last para on p385 starts: "Figure 12.86 shows a fragment of a Fast Fourier Transform (FFT) computation containing an expansion region. Outside the region, there are operations" - the reference should be to Figure 12.87

  • Reported: UML 2.0 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Section: 14.4

  • Key: UML22-186
  • Legacy Issue Number: 9340
  • Status: closed  
  • Source: Digital River ( Mark Mendel)
  • Summary:

    The comment in figure 14.2 in the top right cell identifies the last message as a reply, but it is in fact a creation message. See 14.3.20 Message, Notation, pg. 478: Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line. Object creation Message has a dashed line with an open arrow.

  • Reported: UML 2.0 — Tue, 31 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The only indication of the notation for reply messages in 2.4.1 was table 14.2 and some examples, all of
    which showed a dashed line with open arrowhead. So we assume this was normative even though it was not
    very explicit.

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

No ObjectEvent corresponding to SendObjectAction

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

    SendObjectAction sends the object on its request InputPin the object at its target InputPin.

    AcceptEventAction can have a trigger that is a SignalEvent or CallEvent, but there is no Event type for ObjectEvent to represent the receipt of an object from a SendObjectAction. SignalEvent cannot be the trigger because it is not a Class and is not general enough.

  • Reported: UML 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 specification, in subclause 16.3.3, under “Send Actions”, now includes the
    following text in the description of the semantics of SendObjectAction: “If the object [sent by the action] is a Signal
    instance, then it may be handled by the target object in the same way as an instance sent from a SendSignalAction
    or BroadcastSignalAction. Otherwise, the reception of the object can only be handled using an AnyReceiveEvent (as
    described under Message Events in sub clause 13.3.3).”
    Disposition: Closed - No Change

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

Fig 12.10

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

    Fig 12.10 shows Activity.partition with multiplicity 1 but the text on page 329 shows [0..*].I suspect that the former is correct.

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

    This was resolved in the final resolution of issue 8208 in UML 2.1. (It was actually 0..* that was correct.)
    Revised Text:
    None
    Disposition: Closed, no change

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

Page: 625

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

    Extend (with condition) entry in diagram table: The comment anchor line has a small circle at the end. That's not UML notation, but Pavel Hruby notation

  • Reported: UML 2.1 — Wed, 15 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

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

UML 2.1/Superstructure/ call triggers vs signal triggers

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

    P. 603 makes reference to "CallTriggers" and "SignalTriggers". I believe the wording on that whole paragraph under "Example" should be changed slightly.
    P. 246 makes reference to "SignalTrigger"
    P. 453 makes reference to "call trigger" ( I believe the wording should be modified slightly. )

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

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

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

Section: 12.3.48

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

    I've found a implicit constraint: Imagine - for example - a LoopNode. It's part of an activity partition called component1. Within the body of the loop node an action should be called that's part of another activity partition called component2 (It's a common scenario: a component calls another component from within a loop). However that's not allowed: the loop node is in partition component1 while a contained action is in partition component2. Is that right? If yes, I believe it should be allowed.

  • Reported: UML 2.1 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is not clear what the submitter means by a loop node "calling" an action. As a structured activity node, a loop node owns the actions within it. However, an activity partition references contained nodes and edges, but it does not own them. Therefore, it is allowable for the actions contained in a loop node to be in different partitions, if this is what is desired.
    Revised Text:
    None
    Disposition: Closed, no change

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

UML 2.2 RTF issue - line styles for profiles

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

    UML stereotypes can have an associated icon. For shapes there are 2 options for applying the icon: display the icon in the top right of the standard UML shape, or completely replace the standard shape with the icon.
    However for lines there is only the option of displaying the icon 'near' the standard UML representation of the line. This is somewhat clunky at best and limits the flexibility of profiles.

    The equivalent of using the icon to replace the original UML shape would be to allow the specification of a new line style: the icon could be used to represent both ends and the middle - and the tool would repeat the middle section in order to create an actual line.

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

    No Data Available

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

UML 2 Super / Composite Structure / ambiguous constraint

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

    There is a constraint on page 159.:

    [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.

    The wording is quite unclear. Interfaces are not by themselves required or provided but relative to a port or a classifier. Also, it implies that it should be possible to draw a connector from an Interface to a Port. This constraint needs to be clarified and made more precise.

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

    Resolution:
    This is a duplicate of 7251

    Revised Text:
    None.

    Disposition: Duplicate of 7251

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

Section: 15.3.12

  • Key: UML22-132
  • Legacy Issue Number: 8890
  • Status: closed  
  • Source: IBM ( Jaroslav Gergic)
  • Summary:

    The UML 2.0 Specification states at 15.1 that "The state machine formalism described in this section is an object-based variant of Harel statecharts." However, there is a big semantical discrepancy between the Harel statecharts as described in D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, (with M. Politi), McGraw-Hill, 1998 and the UML 2.0 specification. The major difference is in the priority of transitions when multiple transitions are enabled in case of a nested (hierarchical) state machine. Harel states (6.3.1 (pages 99-100)): "The criterion for priority of transitions prefers the transition whose source and target have a higher common ancestor state, if possible. If the common ancestors of both transitions are identical, then non-determinism indeed occurs." (i.e. it prefers global, higher-level transitions over local ones) UML 2.0 (15.3.12 page 618) imposes almost a reveres-ed order on the priority of the transitions, by looking up from the current nested leaf state and taking the first enabled transition. The impact of the UML definition is that the author can not only "refine" a high-level state in its descendants, he/she can override the global transitions thus violating the global (high-level) contract of the state machine. This becomes even more dangerous when using submachine state, i.e. the nested state is actually drawn in a separate diagram. Example: imagine an electrical device, which can be in one of 2 top-level states: ON, OFF and having two transitions power_on, power_off. The ON state can have multiple sub-states describing a particular state of the operation. Using the UML 2.0 semantics, one can effectively override the global power_off transition locally in on of the ON's children, forcing the electrical device to keep working, even if the power has been shut down - ignoring the signal using e.g. a self-transition.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    To avoid confusion, add a clarification

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

Section: 11.5.1 DataType (as specialized)

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

    In section 11.5.1 DataType (as specialized) you write "• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember." The type "Attribute" does not exist. You mean Property, which is also shown correctly in the diagramm at page 133

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

event parameters

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

    Event was able to own set of parameters in UML 1.4 .

    "Any parameter values associated with the current event are available to all actions directly caused by that event
    (transition actions, entry actions, etc.)."

    In UML 2.0 Parameters are removed from Event metaclass, but in chapter "Changes from UML 1.x" there is no comment about that ("None").

    Could you please comment how Parameters from UML 1.4 Event should be mapped into UML 2.0 model?

    I see a big problem, because some MDA tools (like AndroMDA) are based on information stored in Event parameters, hundreds of users have lot of projects, they can't be lost on migration.

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

    Discussion
    This issue is obsolete. Tools have long since adapted to this change in UML 2.0 and the UML 2.5 specification no
    longer lists “changes from UML 1.x”.
    Disposition: Closed - No Change

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

Meaning of navigability

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

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

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

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

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

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

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

Section: 11.3.13 TypedElement (as specialized)

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

    In section 11.3.13 TypedElement (as specialized) you write: Attributes • type: Classifier[1] Redefines the corresponding attributes in both Basic and Abstractions. Neither has InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement such a property, nor does InfrastructureLibrary::Core::Basic::Type::TypedElement, even through inheritance.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 11.3.6 Classifiers diagram

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

    Issue for: UML 2.0 Infrastructure Specification Section: 11.3.6 Classifiers diagram Document: ptc/03-09-15 URL: http://www.omg.org/cgi-bin/doc?ptc/2003-09-15 Pages: 90,91,95,96,127,130 With this submission I report an serious error in your specification. On Page 127, Section 11.3.6 Classifiers diagram, you show that the type InfrastructureLibrary::Core::Constructs::TypedElement is a generalization of both, InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement (section 9.19.2, page 91) and InfrastructureLibrary::Core::Basic::TypedElement (section 10.1.3, page 96). This leads to a collission of properties, since both of these defined a property called "type", where the one is of the sort InfrastructureLibrary::Core::Abstractions::TypedElements::Type (section 9.19.1, page 90) and the other is of the sort InfrastructureLibrary::Core::Basic::Type (section 10.1.1, page 95). Both Type-types are incompatible, since none is a generalization of the other. Please help and clarify, because I want to implement your standard for a project and cannot proceed correctly. Thanks, Thomas Weise. tweise@gmx.de University of Kassel Germany

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Page: 62

  • Key: UML22-139
  • Legacy Issue Number: 8920
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Description

    Figure 36 was not changed to conform to example description. Here, the example indicates that “the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class. However, Fig. 36 illustrates that Car class is an instance of the CarFactory class

    The page indicates issue 6159 addressed this same problem, but apparently it went unchanged.

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

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

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

page 134, Chapter 11.4.1

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

    on page 134, Chapter 11.4.1, you write:

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

    In Basic there is no definition for "Classifier".

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

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

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

page 97, Chapter 10.2.2. MultiplicityElement

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

    On page 97, Chapter 10.2.2. MultiplicityElement, you write

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

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

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

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

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

Page: 129

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

    BNF for property notation states that the name of the property is mandatory. There is no appropriate constraint for that. If it is mandatory there are some wrong diagrams in the specification, e.g. Fig 334.

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

    Not exactly. The BNF states that the <name> terminal is mandatory. Clarify in the text that where there is
    no property, <name> is empty.

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

Page: 369/370

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

    The notation for activity partition allows to notate the specification of the dimension next to the appropriate dimension set. Dimension is a boolean property of an ActivityPartition. It is not clear where the specification of a dimension is stored in the model.

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

    An ActivityPartition with isDimension = true is the specification of the dimension, and the partions contained within it are the partitions in that dimension. The dimension name in the notation is the name of an ActivityPartition with isDimension = true. This can be clarified in the text.

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

Page: 157,162,163

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

    Fig. 87, fig. 92, and fig.93 show composite structure diagrams with interfaces. For example fig 87; delegation connector from port to interface OrderEntry. How can a connector be linked to an interface?

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

    Figure 87 is now 8.12. Figure 92 is now 8.17. Figure 93 is now 8.18. I include figure 8.15 in this resolution to get a consistent overall picture.
    The solution is to allow connector lines to connect lollipops and sockets, and ball and socket notation, only when the interfaces are on a simple port. Then the connectors become a notational shorthand for actually connecting to the ports.

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

ObjectNode

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

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

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

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

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

9.1 BehavioralFeature package

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

    The element "Parameter" is shown to generalize both, TypedElement and NamedElement. However, TypedElement is already a generalization of NamedElement (see chapter 9.19). Thus, the second generalization is redundant and can be removed.

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

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

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

Page: 532

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

    Associations section: Type of argument is InputPin. In fig. 333 the type is Action

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

    This seems to refer to the argument association of InteractionUse, as of the UML 2.0 Draft Adopted Specification (ptc-04-10-02). It was corrected as an editorial change in UML 2.1.
    Revised Text:
    None
    Disposition: Closed, no change

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

UseCase and Actors

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

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

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

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

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

Page: 423

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

    Second constraint of ObjectNode refers to property isUnique. ObjectNode has no such property. It's not a specialized MultiplicityElement

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    this is correct

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

Section: 10.1 Types Diagram

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

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

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

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

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

Figure 179 (Control nodes)

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

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

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

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

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

Section: D.4

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

    In Description for CCMService, either add the ending or remove the opening quotation mark for the last word. The stereotype name for CCMProcess is not the same as that within the guillemets. Complete the Tag cell in CCMHome. Complete the Tag cell in CCMManages. Capitalize and correct spelling of "Always in the Constraints cell of CCMManages. The Description for CCMFactory really doesn't make a lot of sense to me but I'm not at all familiar with CCM Components. However the stereotype name doesn't relate to a create function for me.

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 15.3.8 (second issue)

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

    "Entry actions of states entered on the path to the state represented by a deep history are performed." It's open which path is taken if there are more than one paths to the state.

  • Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Section: 18.3.6

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

    ypos - Opening "(" dont agree with ")" for either constraint. Clarify the illustration of the first approach (examples in Fig. 450 and 451). It is still confusing. Typo - Under "Using XMI to exchange Profiles" last sentence of first para on pg 724, change "purpose" to "purposes." Last sentence on pg 726, change "and need to be...." to "and these constraints need to be..."

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

    It is unclear what approaches are being referred to in the second sentence. There are no figures 450 and 451.

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

Section: 17

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

    Add OCL notation to constraints or a note that OCL notation is not available for this constraint. In the figures show all sub-package names or ellipses associated with the direct generalizations. Use of the words subclass and subclasses is often confusing and inappropriate as these are not shown in associated figures or mentioned in text. Whenever subclasses are mentioned, please clarify by giving examples as was done on page 690. Orgainzation of this Part is confusing after becomming accustomed to the organization used in parts I and II. Placement of all abstract syntax figures in one place helps clarify relationships of figures to each other and makes it easier to see/verify consistency. Names of classifiers and packages in the text often don't agree with the names shown on associated figure.

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

    No Data Available

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

Section: 8.3.1

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

    Notation section of component states that the relationship between realizing classifiers and the component is displayed by general dependencies. The specialized Realization states that it's notation is similar to the realization dependency. Change fig. 85: Replace dependency arrows by realization arrows (with triangular arrowhead).

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

    see page 50 of ptc/2009-09-07 for details

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

Section: Actions

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

    Add OCL to constraints in Actions chapter

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

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

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

CombinedFragment Loop notation

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

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

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

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

    No Data Available

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

Section: 7.3.36

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

    According to fig. 13 an operation is associated with a Datatype. That's not shown in the association section of the class description.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

editorial in section 12

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

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

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

    No Data Available

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

UML 2 Different constraints for Property in Super and Infra

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

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

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

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

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

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

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

Activities

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

    In LoopNode, SetupPart/bodyPart should be setup/body to be consistent with Clause

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

    Revised Text:
    This is covered in the resolution to Issue 8686.
    Disposition: Merged

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

Clarify multiple inputs to expansion regions

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

    Clarify multiple inputs to expansion regions. Clarify whether expansion regions with multiple input expansion nodes require all values to be present to start execution. If not, how is it indicated which are optional? ExpansionNodes do not have multiplicity.

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

    Discussion
    This issue is obsolete. The requested semantics for ExpansionRegions are now covered in UML 2.5 in Subclause
    16.12.3.
    Disposition: Closed - No Change

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

DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

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

    DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

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

    An ObjectNode is not a MultiplicityElement, and, therefore, it can have no uniqueness constraint to reverse. (There actually is such a constraint given for ObjectNode, but this is an error that should be corrected. See Issue 8891.)
    Revised Text:
    None
    Disposition: Close, no change

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

Add constraints on conditional, loop, sequence to rule out node contents

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

    Add constraints on conditional, loop, sequence to rule out node contents that are not in the sequence, or clause, setup/body part

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

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

Section: Activities, LoopNode

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

    In LoopNode, setup, test, and body parts should be owned by the loop node (they were owned by clauses of loop node, which were owned by the loop node).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The setup, test and body parts of a loop node should all identify nodes that are contained within the loop node. Such nodes are already owned by the loop node via the node association inherited from StructuredActivityNode. However, a constraint needs to be added to ensure this containment, and to ensure that any all executable nodes contained in the loop node are, indeed, in the setup, test or body parts.

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

rewording isuse?

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

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

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

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

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

reword sentence

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

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

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

    agreed

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

A test cannot be empty

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

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

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

    agreed

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

Misleading statement about multiplicity in AssociationClass

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

    Misleading statement about multiplicity in AssociationClass. In the semantics of AssociationClass, the following is misleading: " Note: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e. from the instance point of view, the multiplicity of the associations ends are 1." The part after "i,e." is confusing, since it refers to multiplicity of association ends, which has a different meaning that intended above. I'd say just delete it.

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

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

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

Client/supplier on dependencies

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

    Client/supplier on dependencies should specialize source/target inherited from directed relationship

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

    Resolution:
    Duplicate of 6405.
    Revised Text:
    None.
    Disposition: Duplicate

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

Constrain conditional node to have body pins if there is a result pin.

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

    Constrain conditional node to have body pins if there is a result pin. Constrain to be of the same number and compatible types

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

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

Starting state machine

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

    [Steve Mellor] The action semantics has an action that starts a state
    machine. The state machine starts in some known initial (pseudo-)state.

    There are many cases where one wants to initialize a state
    machine so that starts in a specified (non-initial) state.

    Therefore the StartStateMachineAction needs to accept a state
    (possibly multi-leveled) as an input. The state machine will
    not execute any procedures or actions until after the state
    machine is in the target state and then detects an event.

  • Reported: UML 1.4 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

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

Starting a state machine

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

    Description:
    The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

    Syntactically, we have the following:

    o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts.

    o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

    o The definition of the stereotype <<create>> is (p. 2-149):

    "Create is a stereotyped call event denoting that the instance receiving
    that event has just been created. For state machines, it triggers the
    initial transition at the topmost level of the state machine (and is the
    only kind of trigger that may be applied to an initial transition)."

    Thus, a "creation event" MUST be a call event.

    o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

    Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

    Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

    This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

    Recommendation:

    1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

    2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

    3. Change well-formedness rule [5] to exclude the top initial pseudo-state.

    4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature.

    5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.

  • Reported: UML 1.4 — Thu, 4 Apr 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

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

saying {nonunique} on one end of a binary association is meaningless

  • Key: UML22-5
  • Legacy Issue Number: 5977
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is
    meaningless by the current rules, because the other end remains

    {unique}

    by
    default, so no duplicate links would be allowed

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is meaningless by the current rules, because the other
    end remains

    {unique}

    by default, so no duplicate links would be allowed
    Disposition: Merged with 6464

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

behaviour of the shallow history state and deep history state

  • Key: UML22-4
  • Legacy Issue Number: 5886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state.

    Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

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

    Disposition: Deferred to UML 2.4 RTF

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

On page 26, Figure 7.9

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

    On page 26, Figure 7.9 there an association between 'Property' and 'Classifier'. The end 'classifier' is non-navigable. 'classifier' subsets 'redefinitionContext'. This means the following constraint of 'Property' is violated: subsettedProperty->exists(sp | sp.isNavigable()) implies isNavigable())

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

    The noted Property constraint is no longer present in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

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

choice of terminolgy for TransitionKind is non-intuitive

  • Key: UML22-172
  • Legacy Issue Number: 9230
  • Status: closed  
  • Source: Parata Systems ( Mark Uebel)
  • Summary:

    The choice of terminolgy for TransitionKind is non-intuitive for many of us, and therefore leads to misuse. Specifically, one would expect the antonym pair "Internal" and "External" be applied to a conceptual pair such as "Exits the composite state" and "Does not exit the composite state". Instead the terms "External" and "Local" refer to these behaviors, respectively. Further, the term "Internal" is then used to describe a concept that has nothing to do with state transitions, but rather, is a reaction to a trigger. It appears to us that the transition and reaction concepts were generalized based on their members (trigger, guard, effect) and not on their behavior. We have found this approach to be a bad practice. Behavioral generalization is more intuitive, and therefore more appropriate. We suggest the following changes: "Internal implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered." "External implies that the transition, if triggered, will exit the composite (source) state." Move what is currently described as an "Internal Transition" to a separate concept named "Reaction".

  • Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Although terminology is almost always contentious and a matter of taste, the submitter has a solid point that this
    particular case can be particularly confusing. However, it has been around since UML 2.0, and changing it at this
    point would likely lead to more confusion and have an impact existing implementations and texts. It seems better to
    leave it unchanged at this point.
    Disposition: Closed - No Change

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

Section: 15.3.15

  • Key: UML22-171
  • Legacy Issue Number: 9172
  • Status: closed  
  • Source: Paranor AG ( Knut Wannheden)
  • Summary:

    Given the current wording in the Constraints, Semantics, and Notation sections the "external" and "local" transition kind only applies to transitions with composite states as the source. This does then not leave any transition kind, except "internal", over for transitions with simple states or pseudostates as the source. As I understand it the "external" transition kind should also be available for transitions with simple states and pseudostates as the source. Thus, I think the constraint [2] should be removed and the wording in the Semantics and Notation sections should be changed to make it clear that the "external" transition kind is not reserved for transitions with composite states as the source.

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

    External transitions should be available for all vertices except entry points. Local transitions should be allowed for either composite states or entry points. Internal transitions must source/target a composite state, where source=target.

    The semantics and notation will need to be updated to slightly to reflect this change.

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

Section 8.3.2 sub-section "Notation" starting on page 149

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

    Issue:
    The use of the keyword <<component>> on all diagrams in this section is inconsistent with standards used elsewhere in the spec (for example the notation shown in the Interfaces package). When a shape has the small component icon showing, the keyword is not required and arguably should not be shown.

    Rationale:
    The diagrams imply that both the icon and the keyword should always be shown. This is of course not the case. As it is, some tools vendors not only accept this incorrect implication but some have also mistaken the keyword for a stereotype. It would be much clearer if the keyword were only shown on component boxes that did NOT have the plug icon in them.

    Note that the notation shown on Page 152 (first page of section 8.4) is "correct" - i.e. much more appropriate, and less likely to mislead. On the other hand that shown on page 153 is "incorrect".

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

    The classifier notation of a component is defined showing the keyword "component" and optionally the component icon in the upper right corner. All examples in the component chapter of the UML 2.2. (ptc/2008-05-05) show the component with keyword and icon. However table 8.1 shows a component with an icon and without the keyword. This presentation option must be added to the component definition.

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

inconsistency wrt UML2 classifier behavior

  • Key: UML22-169
  • Legacy Issue Number: 9138
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Figure 13.6 - Common Behavior (page 412 of formal/05-07-04) shows BehavioredClassifier's ownedBehavior as a composition (black diamond) and it shows classifierBehavior as a directed association (no diamond).

    no problem so far.

    But then the figure also shows classifierBehavior subsets ownedBehavior, and the text says (page 420, section 13.3.4 BehavioredClassifer|Associations) that classifierBehavior specializes BehavioredClassifier.ownedBehavior).

    If classifierBehavior is a specialization and the set of its instances is a subset, then the metaassociation denoting classifierBehavior should have the same association type as the superset, in other words for conssitency, both or neither should be black diamond.

    My assumption here is a form of the covariance thesis, a subset and specialization of a composition must also be a composition.

  • Reported: UML 2.0 — Wed, 2 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 Specification, Behaviored::classifierBehavior is no longer specified in the text as "specializes BehavioredClassifier.ownedBehavior". Instead, it simply notes "subsets BehavioredClassifier::ownedBehavior", which is consistent with the diagram.
    The subset classifierBehavior association doesn't need to be composite, because it implies the superset ownedBehavior one (for the same behavior instance), which is composite, so composite semantics will apply anyway. Deleting an M1 classifier instance will delete the M1 behavior instance linked by the subset association, because that M1 classifier is also linked by the superset composite association.
    Revised Text:
    None.
    Disposition: Closed No Change

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

keyword, "buildcomponent", and a stereotype, "buildComponent"

  • Key: UML22-168
  • Legacy Issue Number: 9125
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    A keyword, "buildcomponent", and a stereotype, "buildComponent", are
    listed in Annex B, "UML Keywords" and Annex C, "Standard Stereotypes",
    but not consistent. The letters, 'c' of the "buildcomponent" keyword and
    'C' of the "buildComponent."

    Also, there are stereotypes mentioned throughout the document such as:

    o decisionInput
    o multireceive
    o parallel
    o iterative
    o stream

    but not listed in the Annex C, Standard Stereotypes. The stereotypes
    mentioned above may not reflect the entire document.

  • Reported: UML 2.0 — Mon, 31 Oct 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18454

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

Element and Comment in Basic

  • Key: UML22-182
  • Legacy Issue Number: 9246
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The definition of the classes Element and Comment in the Basic package is ambiguous. The Basic package
    imports Abstractions::Elements::Element and Abstractions::Comments::Comment. An inheritance
    relationship and an Association called ownedComment is introduced between Element and Comment in the
    package Basic. However, these relationships were already defined for these classes in the package
    Abstractions (see the top two diagrams in Figure 4). Therefore, the complete model of Element and
    Comment in the Basic package is the model shown in Figure 4, clearly showing a redundant association
    called ownedComment, and a redundant inheritance relationship between Abstractions::Elements::Element
    and Comment.
    Abstractions
    Element
    (from Elements)
    Element
    (from Comments)
    Comment
    (from Comments)
    Element
    (from Ownerships)
    +owningElement
    0..1

    {subsets owner}
    ownedComment
    * {subsets ownedElement}
    annotatedElement
    *
    Basic (after import abstractions)
    Element
    (from Comments)
    Element
    (from Ownerships)
    Element
    (from Elements)
    Comment
    (from Comments)
    +owningElement
    0..1{subsets owner}

    annotatedElement
    *
    0..1
    ownedComment
    *

    {subsets ownedElement}

    +ownedComment
    0..n
    Basic
    Comment
    (from Comments)
    Element
    (from Elements)
    +ownedComment
    0..n
    0..1
    <<import>>
    <<import>>
    Figure 4

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Description of Element

  • Key: UML22-181
  • Legacy Issue Number: 9245
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The infrastructure specification [1] described the metaclass Element as followes:
    “Element is an abstract metaclass with no superclass. It is used as the common superclass for all
    metaclasses in the infrastructure library.” [1, page 45 and page 93]
    Both packages, Abstraction and Basic, are using the same definition for Element. Therefore, it is logical to
    assume that both packages will contain their own class Element, as shown in Figure 2.
    InfrastructureLibrary
    Abstractions Basic
    Element Element
    Figure 2
    The Rose Model [2] specifies one single class Element, a metaclass that is part of Abstractions. The exact
    name is Abstractions::Elements::Element. The Basic package imports this metaclass. (see Figure 3). We
    assume this is the correct interpretation, therefore the text on page 93 should be changed accordingly.
    InfrastructureLibrary
    Basic
    Abstractions
    Element
    (from Elements)
    <<import>>
    Figure 3

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

Unclear relationship between the Basic and Abstractions packages

  • Key: UML22-180
  • Legacy Issue Number: 9244
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    1) According to the infrastructure specification [1] the Basic package is using metaclasses from the
    Abstractions package, as indicated by the following text.
    “Basic also contains metaclasses derived from shared metaclasses defined in packages contained in
    Abstractions. These shared metaclasses are included in Basic by copy.”[1 page 91]
    First, the mentioned copy construction is not defined in the infrastructure. Second, in contrary to the copy
    definition, the Rose Model [2] of the infrastructure defines the deriving of metaclasses as import on the
    package Abstractions::Elements and Abstractions::Multiplicity. (see Figure 1)
    2) Furthermore, the infrastructure specification described the reuse of the package Abstractions::Comments
    as followes.
    “Basic::Comment reuses the definition of Comment from Abstractions::Comments.” [1 page 92]
    The Rose Model [2] does not contain this import.
    Abstractions
    Elements
    Comments
    Ownerships
    <<import>>
    <<import>>
    Multiplicities
    <<import>>
    Basic
    <<import>>
    <<import>>
    Figure 1
    3) The infrastructure specification described the Basic::MultiplicityElement as the reuse of
    Abstractions::MultiplicityElement:
    “Basic::MultiplicityElement reuses the definition from Abstractions::MultiplicityElement”[1 page 97]
    The Abstractions package does not contain an Abstractions::MultiplicityElement. Instead of, the
    Abstractions package does contain an Abstractions::Multiplicities::MultiplicityElement and an
    Abstractions::MultiplicityExpressions::MultiplicityElement. Owing to the import of
    Abstractions::Multiplicities the Abstractions::MultiplicityElement

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

XMI file: Core::Constructs::Operation::bodyCondition should have upper boun

  • Key: UML22-179
  • Legacy Issue Number: 9243
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the XMI file sent out with Ballot 12, the bodyCondition attribute
    of Core::Constructs::Operation has upper="*" when it should be
    upper="1".

    See line 3009 of Infrastructure.cmof:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Core- Constructs-Operation-bodyCondition" name="bodyCondition" lower="0"
    upper="*" type="Core-Constructs-Constraint" association="Core- Constructs-A_bodyCondition_bodyContext" subsettedProperty="Core- Constructs-Namespace-ownedRule" isComposite="true"/>

    In Superstructure, Classes::Kernel::Operation seems to correctly have
    an upper bound of 1 for bodyCondition.

    Again, apologies for the late notice on this issues. If there is a
    better way to report these, please let me know. I'm sending them to
    the list because I assume some can be made as editorial changes by
    Bran, while others should be opened as new issues for UML 2.2.

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

    Infra::Core::Constructs::Operation::bodyCondition : Constraint[0..1] in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

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

/qualifiedName attribute missing on Core::Constructs::NamedElement

  • Key: UML22-178
  • Legacy Issue Number: 9242
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the Infrastructure.cmof file distributed as part of ballot 12, the
    Core::Constructs::NamedElement class is missing the qualifiedName
    derived property. The operation qualifiedName() exists, but the
    corresponding derived attribute is missing.

    Core::Abstractions::Namespaces::NamedElement does correctly include
    the qualifiedName derived property and all of the OCL constraints in
    Constructs correctly references a qualifiedName attribute (rather
    than the operation).

    Presumably this is an error in the metamodel.

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

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

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

Operation::ownedParameter should be ordered in XMI?

  • Key: UML22-177
  • Legacy Issue Number: 9241
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the latest XMI file (included as part of Ballot 12) the
    ownedParameter attribute of Core::Constructs::Operation redefines
    Core::Constructs::BehavioralFeature::ownedParameter – I'm assuming
    that this redefinition is a result of the merge of Basic.

    However, in Operation, the ownedParameter attribute is not ordered.

    Since both BehavioralFeature::ownedParameter and
    Core::Basic::Operation::ownedParameter are ordered, it seems strange
    for Core::Constructs::Operation's not to be ordered. A check of the
    drafts and ballots does not seem to address this issue or explain why
    it would be the case. Is it a mistake?

  • Reported: UML 2.0 — Sun, 15 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Infra::Core::

    {Basic,Constructs}

    ::Operation::ownedParameter

    {isOrdered=true}

    in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

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

Section: Classes

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

    Can an instance specification for a classifier specify instances of subtypes of the classifier? For example, if Fido is an instance specification for Class Dog, can the runtime object it specifies be an instance of Terrier?

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

    An InstanceSpecification can be partial. The spec is quite clear about this. It is also clear that every slot
    must correspond to a feature of one of the classifiers. If the InstanceSpecification is classified as a Dog, it
    might be a Terrier at runtime but you have no way to know that. Insert some text to make this clear.

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

constraints owned by these properties have no context

  • Key: UML22-175
  • Legacy Issue Number: 9236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A similar issue exists with ParameterSet::condition, State::stateInvariant, Extend::condition, Action::localPrecondition, Action::localPostcondition, StateInvariant::invariant, i.e. constraints owned by these properties have no context. This raises the question of whether a constraint must always have a context (note that some of these owners are not namespaces)...

  • Reported: UML 2.0 — Thu, 22 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    As shown in Figure 7.13 in the UML 2.5 specification, the context of a Constraint is optional. Constraints that are
    required to be owned in some way other than using the context/ownedRule association do not have a context.
    Disposition: Closed - No Change

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

Operation should be a specialization of TypedElement and MultiplicityElemen

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

    Operation should be a specialization of TypedElement and MultiplicityElement. Currently it is in InfrastructureLibrary::Core::Basic (L0), but isn't in other packages (LM - L3).

  • Reported: UML 2.0 — Wed, 14 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

section, 12.3.27 ExpansionRegion(from ExtarStructureActivities

  • Key: UML22-167
  • Legacy Issue Number: 9120
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    Under the section, "12.3.27 ExpansionRegion(from ExtarStructureActivities)", it states as

    Attributes

    • mode : ExpansionKind - The way in which the executions interact:

    parallel - all interactions are independent.

    iterative - the interactions occur in order of the elements.

    stream - a stream of values flows into a single execution.

    Notation

    An expansion region is shown as a dashed rounded box with one of the keywords parallel, iterative, or streaming in the

    upper left corner.

    However, in "Figure 12.87 Expansion region" the keyword used is <<concurrent>>. Could you
    please verify this and let me know. Thank you.

  • Reported: UML 2.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

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

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

(merged) compliance levels L2 and L3

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

    In (merged) compliance levels L2 and L3, derived union property ActivityGroup::subgroup has no subsets.

    -> Rename ActivityPartition::subgroup to subpartition, replace

    {redefines subgroup}

    with

    {subsets subgroup}

    . Also add properties to StructuredActivityNode and InterruptibleActivityRegion that subset ActivityGroup::subgroup?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure. Further,
    the suggested change to ActivityPartition::subgroup has already been made. StructuredActivityNodes and InterruptibleAtivityRegions
    do not have subgroups.
    Disposition: Closed - No Change

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

(merged) compliance level L1

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

    In (merged) compliance level L1, derived union properties ActivityNode::inGroup, ActivityEdge::inGroup, ActivityGroup::subgroup, ActivityGroup::superGroup and have no subsets. Note that ActivityGroup, an abstract metaclass, has no concrete subclasses.

    -> Should ActivityGroup not be originally defined in BasicActivities (nor in Fundamental Activities), but perhaps in IntermediateActivities?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure.
    Disposition: Closed - No Change

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

Section: 14.3.20 Message (from BasicInteractions)

  • Key: UML22-164
  • Legacy Issue Number: 9081
  • Status: closed  
  • Source: Edin Pezerovic ( Edin Pezerovic)
  • Summary:

    in 14.3.20 Message (from BasicInteractions) is described: "Object creation Message has a dashed line with an open arrow." the referenced example 14.11 on page 458 shows an object creation Message with a solid line and an open arrow.

  • Reported: UML 2.0 — Mon, 17 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    The figure is all right, but dashed lines are sometimes printed as solid lines. The illustrations use Visio and sometimes the dashed lines are not easily distinguished.
    Disposition: ClosedNoChange

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

Section: Activities

  • Key: UML22-163
  • Legacy Issue Number: 9078
  • Status: closed  
  • Source: juno.com ( Pae Choi)
  • Summary:

    In Activities, ExpansionRegion, Notation, first sentence, replace "stream" with "streaming".

  • Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The sentence already has "streaming" (and has since UML 2.0). However, the literal in ExpansionKind is "stream", so perhaps the submitter intended to suggest replacing "streaming" by "stream". This would be consistent with using the literals from EnumerationKind for "parallel" and "iterative".

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

UML 2 Issue: Qualified pathnames

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

    PROBLEM STATEMENT
    The notation for qualified names is double-colon ('::'). However, the Spec
    always and everywhere uses a different notation: instead of
    "Kernel::Comment", "Comment (from Kernel)".

    PROPOSED SOLUTION
    Use the standard notation for qualified names.

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

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

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

show object flow or interactions

  • Key: UML22-35
  • Legacy Issue Number: 7166
  • Status: closed  
  • Source: Boeing ( David Hickerson)
  • Summary:

    There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

  • Reported: UML 1.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been discussed in previous F/RTFs and considered out of scope:
    FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address.
    RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them.
    Revised Text:
    None
    Disposition: Closed Out of Scope

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

UML 2 Super/Interactions/Need constraints that cover multiple Lifelines

  • Key: UML22-34
  • Legacy Issue Number: 7161
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
    None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.

    Or when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.

    In order to achieve this, it would be desirable to use:
    1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
    2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
    3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

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

    Discussion:
    Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects".
    Disposition: Closed Out Of Scope

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

ptc-03-09-15/Separate classification and generalization in Core::Basic

  • Key: UML22-24
  • Legacy Issue Number: 6495
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: One of the main requirements for a core that can be reused by CWM
    hinges on whether it is possible to reuse the abstract syntax that supports
    classification and supports having properties (or features), without pulling
    in generalization constructs. U2P’s Core::Basic package, upon which EMOF is
    based, does not appear to adequately separate these concerns.

    The most abstract level of Core::Basic's inheritance hierarchy at which the
    ability to have properties appears is in the Class metaclass. But Class
    also carries the “baggage” of a definition of superclass.

    The Core::Abstractions package does appear to adequately separate these
    concerns. It does so by defining a simple Classifier in the
    Core::Abstractions::Classifiers package that supports features but not
    generalization. The Core::Abstractions::Super package defines another
    Classifier metaclass that subclasses
    Core::Abstractions::Classifiers::Classifier and adds support for
    generalization.

    Presumably, then, the intent is that CWM metamodels that support
    classification and properties but not generalization can reuse
    Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not
    reuse either of these basic definitions of Classifier from
    Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM
    metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
    share a common definition of Classifier with EMOF. That could mean that a
    metamodel expressed solely via EMOF will not be able to be the source or
    target in a unified approach to transformations. This is not a problem for
    CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
    are based on Core::Abstractions.

    Recommendation: Solving the problem for EMOF would require some refactoring
    of Core::Basic to separate concerns between classification and
    generalization.

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

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

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

Ports in Protocol State Machines

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

    Protocol machines should not have ports in them. It should be an
    extension in the ports package. Otherwise there is a backwards
    dependency onto composite structure.

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

    Discussion
    Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency.
    Furthermore, creating a dependency from composite structures to statemachines would create a more serious
    layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done
    by an RTF at this point.
    UML 2.5 has a different modular structure than UML 2.4 and earlier versions, with a single-level “flat”
    structure in which inter-module dependency concerns, which are at the core of this issue, are no longer
    relevant.
    Disposition: Closed - No Change

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

StateMachine - Constraints

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

    "[1] The classifier context of a state machine cannot be an interface"

    should be:

    [1] The context classifier of a state machine cannot be an interface. not redefinitionContext.oclIsKindOf(Interface)

    "[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioral feature."

    should be:

    [2] The context classifier of the method state machine of a behavioral feature must be one of the classifier that features the behavioral feature

    – note that a behavorial feature can be associated with 1..* – classifiers if self.specification->notEmpty() then self.specification.featuringClassifier->includes(redefinitionContext) endif

    "[3] The connection points of a state machine are pseudostates of kind entry point or exit point."

    should be:

    [3] The connection points of a state machine are pseudostates of kind entry point or exit point. connectionPoint->forAll(cp | cp.kind = #entryPoint or cp.kind = #exitPoint )

    "[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points."

    should be:

    [4] A state machine as the method for a behavioral feature cannot have entry/exit connection points. self.specification->notEmpty() implies ( self.connectionPoint->forAll(cp | not (cp.kind = #entryPoint or cp.kind = #exitPoint) ) )

  • Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In UML 2.5, all of the above have been rewritten and corresponding OCL inserted.
    Disposition: Closed - No Change

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

transtion

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

    Issue 2: In the same spirit, we would like also to specifiy that a transtion is fired

    only if an event is not available at a given instant. We need the concepts of instant

    and event absence. Note that the absence combined with "and" and "or" can express kinds of

    priorities (e.g., "a and not b").

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Triggering a transition with the absence of an event seems to make sense only under a synchronous semantics which defines slices of time where that event might occur or not. It require a major modification or enhancement to the current, asynchronous Run-To-Completion semantics, where events are handled one by one in a timeless sequence. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

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

UML2 Super/Kernel Classes

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

    section 7.11 Does Property.aggregation have meaning for properties typed by
    value types, (Data Type and subtypes)?

  • Reported: UML 1.5 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The spec now says under the semantics of Property “The semantics of composite aggregation when the
    container or part is typed by a DataType are intentionally not specified.”
    Disposition: Closed - No Change

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

UML Superstructure FTF : isRoot property disappeared

  • Key: UML22-26
  • Legacy Issue Number: 6616
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.

    On page 399 FAS: section 13.3.4

    The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

    On page 86 FAS section 7.8.3 RedefinableElement:

    isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is
    true, then it is not possible to further specialize the RedefinableElement. Default value is
    false.

    But no mention of isRoot....

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

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

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

Inheritance of 'Enumerations' is not detailed

  • Key: UML22-30
  • Legacy Issue Number: 6921
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Inheritance of 'Enumerations' is not detailed with repsect to their (ordered) owned 'EnumerationLiteral's.

    Proposed resolution: Add a constraint to restrict Enumerations to be unable to inherit from each other (at least favored in MOF) or specify how Literals are ordered.

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The spec defines what generalization means for Enumerations.
    Disposition: Closed - No Change

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

Part subtype

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

    Would be useful to be able to assign a subtype for objects that fill a
    part, to add additional characteristics. For example, a person fills
    the Employee part of a company, and is reclassified under a subtype of
    person that has an office. It is not sufficient to use the subtype as
    the type of the part, because the model wouldn't record what objects are
    allowed to fill the parts. The object is reclassified under the subtype
    after filling the part.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF.

    Revised Text:
    None.

    Disposition: Closed, out of scope

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

manage simultaneity of events

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

    Issue 1: to have the possibility to manage simultaneity of events, and be able to

    trigger a transition by a condition on several events. By this way, the triggering

    condition of a transition may be specified through an event formula such as: (e1 and e2) or e3

    This point we then involve to relax a constraint on the semantics of RTC and to introduce then

    the possiblity to dequeue several events of the queue at the same time. May it be just an

    additional open variation semantics point?

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Simultaneous events and transitions triggered by a logical combination of events require a major modification or enhancement to the current Run-To-Completion semantics, where events are handled one at a time. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

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

Federated models - UML2 issue

  • Key: UML22-25
  • Legacy Issue Number: 6500
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When creating a complete environment for agreements and BCF we need
    to
    work with ModelElements, classes, package, models etc created and
    managed by many unrelated person and organisations. This means that
    we
    need to support loosely coupled models (federated models) where an
    association starts in one model (stored in doc A) and ends in another
    model (stored in document B).

    This may mean that we need to add references to an external
    modelelement
    so the assoication that references "out" to external ME need to be
    annotated with for example UUID of remote modelelement, name of model
    where the remote/external model , physicial location of remote model
    (URL) etc.
    We may also want to attach constraints to the remote modelement that
    restricts "incomming" associations.

    The question is how are loosely coupled model handled in UML 2 ?

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

    closed no change

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

UML 2.0 Kernel Operations Diagram and Features Diagram and mdl

  • Key: UML22-28
  • Legacy Issue Number: 6700
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The operations diagram redefines the formalParameter Property and removes the

    {ordered subsets parameter subsets ownedMember}

    .

    The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn’t defined in the spec.

    I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

    This would require the ownerformalParam be made navigable. But I feel that this change is already required to sync the OCL and Superstructure specs.

    An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No longer applicable closed no chnage

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

External exceptions.

  • Key: UML22-112
  • Legacy Issue Number: 8750
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    External exceptions. We need an interrupt message that asynchonously causes an exception for some other process/object. In examining real-world examples at IBM, I find we need that concept. And we need interrupts that allow the target process to clean itself up, not just die. This occurs in lots of real problems

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

    This can already be handled, at least for an asynchronously executing activity or state machine, by sending a signal to the behavior. A concurrent part of the activity or state machine can then receive the signal and interrupt the ongoing behavior, transitioning, if necessary, to some clean up behavior before terminating. In an activity this can be done using an interruptible region. In a state machine it can be used with a orthogonal region.
    Revised Text:
    None.
    Disposition: Closed No Change

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

Clarify which classifier or operation this is referring to

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

    CollaborationUse, Constraint 2: Clarify which classifier or operation this is referring to.

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

    There are several places in chapter 9 where the text refers to the possibility of a CollaborationUse being associated with an Operation. But there is nothing in the metamodel to support this. This issue is resolved by removing these statements from the text, and by clarifying the offending constraint.
    In 9.3.3, there is a paragraph that reads as follows:
    "A collaboration may be attached to an operation or a classifier through a CollaborationUse. A collaboration used in this way describes how this operation or this classifier is realized by a set of cooperating instances. The connectors defined within the collaboration specify links between the instances when they perform the behavior specified in the classifier. The collaboration specifies the context in which behavior is performed. Such a collaboration may constrain the set of valid interactions that may occur between the instances that are connected by a link."
    The placement of this paragraph is peculiar, because it appears under Collaboration, not CollaborationUse. The first two sentences of this paragraph are false, because they talk about attaching a CollaborationUse to an operation. The remainder of the paragraph appears to add no value to what has been already stated in the semantics of Collaboration. I propose to delete this paragraph.

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

represents and occurrence keywords are switched

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

    CollaborationUse, Presentation Options, first paragraph, the represents and occurrence keywords are switched

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

    This does not appear in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

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

Events in Sequence diagram

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

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

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

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

    You should check with Oystein.

    > Events are owned by package, it's very uncomfortable (at least two
    > nesting levels from Interaction), it think they should be owned by
    > Interaction.

    No, because the whole idea of events is that they have to be shared by the sender's and reciever's behaviors. It makes little sense to define them in an Interaction.

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1. Deployment

  • Key: UML22-113
  • Legacy Issue Number: 8757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    1. Deployment
    > What is client and what is supplier for this relationship?
    > Why DeploymentTARGET has word "target" in name but subsets "source"
    > for Dependency?

    The meaning of "client" and "supplier" in Dependency is pretty arbitrary and depends on one's point of view. I don't recall the reasoning behind this particular choice, but it may have to do with the direction of the arrow more than anything else. Guus probably wanted the arrow to go from the artifact to the node because it looked more natural to him. Perhaps Guus can explain – I've copied him on this reply.

    However, there is definitely a bug here since "client" and "supplier" are not derived unions, hence, they cannot be subset as shown in figure 126. This may have already been raised as an issue. I'll have to check. I suggest that you raise a formal issue in any case.

    > And why notation examples are from Artifact to Node (arrow near
    > Node, but Node is "client" in model).

    Ostensibly, this is explained by what I wrote above. However, there seems to be a deeper problem here: note that Dependency::supplier and Dependency::client are not specializations of DirectedRelationship::target and DirectedRelationship::source respectively, as I would have expected (otherwise it does not seem to make sense to subclass DirectedRelationship at all). I do not understand why this is so, it does not seem to make sense. It may have to do with the constraints that Dependency did not want to impose on supplier and client, but I am not sure. This needs further study and, likely, an issue to be raised.

    > "Location" attribute of Deployment should be DeploymentTarget, not Node.

    You are correct. Please raise an official issue on this through issues@omg.org

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Questions about the appropriateness of the use of Dependency and the directionality of theway its ends are connected
    are covered by other issues, such as 10781. In any case, such changes require modifications to the metamodel and are
    thereby out of scope for the UML 2.5 FTF.
    There no requirement that client and supplier must be, or must subset, derived unions. In Clause 19.5, the location
    attribute of Deployment is clearly identified as type DeploymentTarget.
    Disposition: Merged with 10781

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Action/Activity

  • Key: UML22-116
  • Legacy Issue Number: 8771
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the actions and activities chapters default values for attributes that are typed by ValueSpecifications use primitives for the default value. For example: 12.3.5 ActivityEdge, p. 352 Attribute weight has default value "1". Is that correct? What if the ValueSpecification is not computable or the value isn't typed by an Integer?

  • Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ValueSpecifications are used in these cases, because it is often desirable for the given value to be specified in the model as computed.
    The default values are to be interpreted as the corresponding LiteralValue for the given value (e.g., a LiteralUnlimitedNatural, in the case of weight). The type of value to which such a ValueSpecification must evaluate (e.g., UnlimitedNatural for weight) is given in the semantics for the construct. If the ValueSpecification is not computable or evaluates to a value of the incorrect type, then the model is ill-formed and has no meaning.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nested Nodes

  • Key: UML22-115
  • Legacy Issue Number: 8763
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Node has nestedNodes collection that redefines "nestedClassifier",
    > but Node have Generalizations to Class from StructuredClasses that
    > has no Generalization to Class from Core package, so Nodes don't
    > inherits "nestedClassifier".

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Input tokens to LoopNodes should be destroyed when the loop is done

  • Key: UML22-119
  • Legacy Issue Number: 8780
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Input tokens to LoopNodes should be destroyed when the loop is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. This is covered by the current semantics for loopVariableInputs, which are the only InputPins a
    LoopNode may have.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-118
  • Legacy Issue Number: 8777
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a notational conflict in the white box view of a component. If a part is typed by a component the component symbol is shown in the upper right corner of the part rectangle. The same position is used to show the multiplicity of the part.

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The upper right corner of a connectable element could be used to denote the multiplicity. The same position is used to show the component symbol if the connectable element is typed by a component. It is also used by stereotype symbols. The presentation option for the multiplicity is in conflict with other standard UML notations. However it is only an option and not a mandatory presentation.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-123
  • Legacy Issue Number: 8866
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 28 (Examples of attributes) has a read-only, derived attribute. Read only attributes can't be changed after initialization, whereas the example implies this particular one can be changed due to derivation.

  • Reported: UML 2.0 — Fri, 10 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2 Action

  • Key: UML22-122
  • Legacy Issue Number: 8861
  • Status: closed  
  • Source: Sapiens Deutschland GmbH ( Helmut Barthel)
  • Summary:

    Object token flow semantics with input pins seems to be incompletely defined. In section Semantics on page 337 you write: "... an action can only begin execution when all incoming control edges have tokens, and all input pins have object tokens." You didn't explain how and when the object tokens come to the input pins. Further, for step [2], you write: "An action consumes the input control and object tokens and removes them from the sources of control edges and from input pins." Again, you didn't explain how and when the object tokens came to the input pins, from source object nodes.

  • Reported: UML 2.0 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec

  • Key: UML22-109
  • Legacy Issue Number: 8741
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirectional. What happens when these are merged in Figure 98?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 21 - 22 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode, Semantics, third paragraph, first sentence,

  • Key: UML22-108
  • Legacy Issue Number: 8738
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    StructuredActivityNode, Semantics, third paragraph, first sentence, clarify that "attached" means input pin, output, or expansion nodes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    The wording of this sentence has already been changed by the resolution to Issue 9855 to refer specifically to pins on a structured activity node. Expansion nodes only apply to expansion regions and are covered in that section.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-117
  • Legacy Issue Number: 8776
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Second constraint: "If a connector end references both a role and a partWithPort, then the role must be a port that is defined by the type of the partWithPort." Since role has multiplicity 1..1 and partWithPort 0..1 the if condition is always true if a connector has a partWithPort. It'S sufficient to say "If a connector references a partWithPort,..."

  • Reported: UML 2.0 — Wed, 11 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed, this will make it easier to read.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Return message

  • Key: UML22-120
  • Legacy Issue Number: 8785
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    How return message should be mapped into model? What kind of events are on message ends, how return values should be mapped? Should return values be arguments of message? How return message can be recognized in the model?
    How variable assignment should be mapped and related with message?

  • Reported: UML 1.4.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There has never been anything called a "return message", but the issue is probably about "reply message" which we had forgotten to give a messageSort, but that has been fixed. The other issues are related, but are also asking for clarification of metamodel encoding. This should eventually be picked up again if necessary during a major revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity should not be used/shown in an communicates association

  • Key: UML22-121
  • Legacy Issue Number: 8854
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 404 - Example of the use cases and actors for an ATM system
    (The ATM example is repeated in Figure 410.)

    If you think multiplicity gives value to this diagram, please add additional text and explain the usage of multiplicity (1, 0..1, 0..*) in this diagram.

  • Reported: UML 1.4.2 — Fri, 3 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18072

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-76
  • Legacy Issue Number: 8353
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add Ocl notation to constraints where possible or note that OCL notation is not possible. Page numbers of odd numbered pages are not in the same place as the are for other chapters. Move them to the lower right corner. Delete sub-section headings where the sub-section contains no information or state "None." If a concept is not "(as specialized)" and there are no atttributes, associations, etc. write "None" instead of "No additional xxx." Not all of the figures contain package names for the generalized parents. Add as many of these as possible or use the ellipses as appropriate.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.18

  • Key: UML22-75
  • Legacy Issue Number: 8342
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Second sentence in sub-section Description is missing a word. "...the contents of the referred Interaction xxx [from?? to??] where the InteractionUse is." Change the class name of the association argument:InputPin[*] either on fig 333 to InputPin or to Action in the text. Class name in fig. 333 is Action. This association is also shown in the figure as ordered. Association actualGate:Gate[*] subsets ownedElement. Mention specialization in definition of the association. I'm confused between the BNF use of io-argument and your use of argument. If the name of the association is "io-argument" as indicated by BNF and Issue 1751, should the name on the diagram and in the sub-section Associations be changed to io-argument? Also, para 2 on og 534 italizes argument instead of io-argument. Typo - Second sent. on pg. 534 needs a space between "explained" and "in."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RemoveStructuralFeatureValueAction specification

  • Key: UML22-74
  • Legacy Issue Number: 8336
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    According to the RemoveStructuralFeatureValueAction specification we always have to specify the value to remove. It is not possible to remove an element from a multi-valued structural feature just by specifying its number in the set and without specifying its value. It would be interesting to have this option.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved by the resolution to Issue 9870.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistent description

  • Key: UML22-73
  • Legacy Issue Number: 8332
  • Status: closed  
  • Source: none ( Rui Xu)
  • Summary:

    There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    An internal transition IS a self-transition. It does not exit or enter the state to which it is attached. Internal transitions
    belong to states and not to regions, as seemed to be implied by the issue summary. This is explicitly stated in the
    specification. From the point of view of firing rules, they are no different than for any other transition. If there are
    conflicts (and, there CAN be conflicts between two internal transitions), they are resolved the same way as all other
    conflicts based on the firing rules for such cases. Hence, the ambiguity discussed in the summary of the issue does not
    exist.
    (However, after reading the text, it seems that there is no explicit statement on how the issue of conflicting transitions
    of the same priority is resolved. Presumably, this is one of those “intentionally left unspecified” cases; i.e., it is an
    implementation choice. But, this is a different and more general issue that needs to be dealt with separately.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Decision node

  • Key: UML22-82
  • Legacy Issue Number: 8471
  • Status: closed  
  • Source: sabetta.com ( Antonino Sabetta)
  • Summary:

    Decision node should be able to take decision based on input separate from the flow being routed

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This issue is already resolved in UML 2.2 (see Issue 10815).
    Revised Text:
    None
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-81
  • Legacy Issue Number: 8470
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Add actions for reading and writing parameter values, so flows are not required in structured activities

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of issue 9247.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel / invalid restriction in isConsistentWith()

  • Key: UML22-80
  • Legacy Issue Number: 8460
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A derived union association end represents a union of all of its subsets. The leaf subsets clearly have to be non-derived. However, in operation Property::isConsistentWith(), defined on page 127 of ptc/-04-10-02, it is stated that a derived property cannot be redefined by a non-derived property. This means that all such subsets of derived unions will be incorrect. Clearly, this restriction should be removed.

    Recommendation:

    Remove the constraint:

    (prop.isDerived implies isDerived)

    from the operation Property::isConsistentWith() (on pg. 127)

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

namespace

  • Key: UML22-67
  • Legacy Issue Number: 8246
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

  • Reported: UML 1.4.2 — Sat, 5 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 89 on page 158 is incorrect

  • Key: UML22-66
  • Legacy Issue Number: 8168
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way.

    More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7.

    Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes"

  • Reported: UML 1.4.2 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text.
    Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2.
    The third aspect of this issue is a duplicate of 12236, already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.17

  • Key: UML22-72
  • Legacy Issue Number: 8310
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 318 shows the association specification:Interfal[1] that redefines specification. Add this to sub-section Associations in the concept since the concept is not as specialized

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This has already been resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.11

  • Key: UML22-71
  • Legacy Issue Number: 8306
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Describe more fully that DurationInterval defines the range between the minimum and maximum duration times allowed. To be consistent with other mutliplicities, show the multiplicities of the associations on fir. 318. Add comment that the associations redefine minimum and maximum as indicated by fig. 318. Sub-section Notation mentions DurationExpression but this concept is not defined. Add this as a concept.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 specification, the diagram is now Figure 13.13. Multiplicities for min and max are shown on both the diagram and in the text. The redefinitions should be shown in the text. In the Notation section, DurationExpression should be Duration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2/Infra section 11.6.2/ Enumerations should not have attributes

  • Key: UML22-70
  • Legacy Issue Number: 8274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
    below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
    The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).

    Proposed resolution:
    Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

  • Reported: UML 1.4.2 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Enumeration literals are immutable, so writeable attributes do not make sense. But read-only attributes do
    make sense: they don’t need to be derived. The current description of equality of EnumerationLiterals needs
    improvement. Operations on enumerations are allowed.
    This also resolves 17933

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default values for ValueSpecification are not specified properly

  • Key: UML22-79
  • Legacy Issue Number: 8450
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are a few cases when the default is documented as a ValueExpression, as follows:

    • JoinNode.joinSpec = {default value is" and"}
    • ActivityEdge.guard= {default value is "true"}

    These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification.

    They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be:

    +guard = LiteralBoolean(true)

    The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true.

    Recommendation:

    Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 15

  • Key: UML22-78
  • Legacy Issue Number: 8447
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments - Delete sub-sections tat are empty or state "None." If class is not "as specialized' do not say "No additional xxxx" but rather "None" or delete the sub-section. Add OCL notation or a note that OCL notation is not available for constraints and/or additional operations and/or derived attributes where appropriate.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-77
  • Legacy Issue Number: 8414
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    How to show class operation calls in interaction diagrams? A discussion in the umlforum list came to the conclusion that the name in the lifeline header should be the class name. In that case it is not possible to differentiate between "ClassName" only and "RoleName" only. Besides the notational problem I can't see how a class operation call could fit into the interaction meta-model. However it is necessary to show such a call. It's a typical part of an interaction.

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18697

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.40

  • Key: UML22-69
  • Legacy Issue Number: 8260
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it - and, since it merges it, cannot reference elements from it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

  • Key: UML22-68
  • Legacy Issue Number: 8249
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-84
  • Legacy Issue Number: 8474
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Enumeration should have a constraint that the classifier of its literals is the enumeration

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-83
  • Legacy Issue Number: 8472
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Object node should be a multiplicity element, and use multiplicity upper for upperbound

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Though seemingly small, this would actually be a significant change to the metamodel for activities and it would fundamentally change the current semantics for multiplicity of pins, which now only effect the execution of actions. If object node in general were made a multiplicity element, one would not only have to reconcile the current semantics of object node upper bound with the semantics of the multiplicity upper bound of a pin, one would also need to consider what the general semantics are for the multiplicity lower bound of an object node.
    This issue is thus considered strategic and out of scope for an RTF.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

  • Key: UML22-65
  • Legacy Issue Number: 8142
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need to write the info for the Changes from previous UML section or remove it

  • Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Interactions

  • Key: UML22-85
  • Legacy Issue Number: 8475
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Interactions: What object receives SendEvent, etc? Affects how AcceptEventAction is used

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Not a problem in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-155
  • Legacy Issue Number: 9005
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Second paragraph of Semantics section of Trigger in Common Behavior is inconsistent with the first paragraph of p 605 in semantics of State. The semantics of Trigger does not accomodate deferred events.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The noted paragraph in Trigger is not actually in conflict with deferred events. The semantics of Trigger states that once "an event is dispatched" it is "considered consumed" and is then "no longer available for processing". However, the semantics for deferred event under State says that "an event that does not trigger any transitions in the current state, will not be dispatched" if it is deferred. Therefore, there is no conflict with it being consumed only if it is actually dispatched.
    However, it would probably be helpful to clarify this under Trigger. Also, the semantic variation point on discarding an event if there is no appropriate trigger is not correct, since, for a transition even, at least, if the event is deferred it is not discarded, and if it is not deferred it is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes (02)

  • Key: UML22-154
  • Legacy Issue Number: 9004
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    raisedException in Figure 10, reused without specialization by Operation in Figure 11 (the entry for it in Operation says it is redefined), but redefined in Figure 315. Should it be a derived union in Figure 10?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The specialization from A_raisedException_operation to A_raisedException_behavioralFeature comes as a result of L3 package merge. Derived union would make sense if raisedException had a subsetting relationship instead of a specialization refinement.
    (Note also that the redefinition of raisedException is now noted on the diagram for Operation. Also, the resolution of Issue 12558 removed the later BasicBehaviors::BehavioralFeature::raisedException.)
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior (02)

  • Key: UML22-153
  • Legacy Issue Number: 9002
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of TimeEvent uses undefined term "active". State machines uses the term for states, not triggers. Need definition independent of state machines in any case.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The UML 2.5 beta specification still uses the phrase “time at which the Trigger becomes active” in 13.3.3
    under “Time Events”. The intended idea seems to be what is now discussed earlier in 13.3.3 under “Even
    Dispatching”: a Behavior may come to a “wait point” at which it has a number of “outstanding Triggers”.
    For any such Triggers with a relative TimeEvent, the starting point should be the time at which the Behavior
    comes to the wait point.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-152
  • Legacy Issue Number: 9001
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics of AnyReceiveEvent. The semantics of AnyReceiveEvent is in terms of state machines even though it is in Common Behavior. Should be defined independently of the kind of behavior using it.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property ownership must be consistent across association redefinitions

  • Key: UML22-151
  • Legacy Issue Number: 8977
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    When an association generalizes another association and redefines its ends, the redefined end must be accessible through the generalization. This means redefining and redefined properties must be ownedEnds of the association or ownedAttributes of the participating classes. Redefining ownership (either directly or indirectly by changing navigability with default ownership) resulting in the redefined property no longer being a member of the general class should not be allowed. UML2 needs to include a constraint capturing this rule

  • Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is already covered by RedefinableElement::isRedefinitionContextValid() and
    RedefinableElement::redefinition_consistent.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing notation for association classes

  • Key: UML22-150
  • Legacy Issue Number: 8974
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notation for Associations allows them to be depicted as a diamond (even binary associations).
    However the Notation for AssociationClasses assumes the Association is depicted as a line only, and does not describe an option for attaching an AssociationClass to an Association shown as a diamond. This should be fairly obvious - just have the dotted line attached to the diamond instead of the Association's line.

  • Reported: UML 2.0 — Tue, 23 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is an omission in the text.
    This also resolves issue 12406

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 346-347

  • Key: UML22-149
  • Legacy Issue Number: 8973
  • Status: closed  
  • Source: Systemvaruhuset ( Andreas Hägglund)
  • Summary:

    Figure 207 on page 346 depicts the symbol for an activity as a number of rectangle with rounded corners surrounding a number of action nodes which also are depticed as rectangles with rounded corner. The example (figure 209 on page 347) however, depicts the action nodes not as rectangles with rounded corners but more lika ovals (or rectangles with noticabely more rounded corners than previously). Which symbol is the correct one?

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced figure is 12.33 in Section 12.3.4 of the UML 2.2 specification (ptc/08-05-05). The graphical variation in the action shape in subsequent diagrams does not seem unreasonable and the notation of an action within an activity is clearly given in Section 12.3.2.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 255

  • Key: UML22-148
  • Legacy Issue Number: 8972
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification says: "If isReplaceAll is false and the variable is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the variable is unordered and UNIQUE, then adding an existing value has no effect."

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior

  • Key: UML22-147
  • Legacy Issue Number: 8970
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    1) As a specialization of Class, Behavior (and its subclasses) may have properties (+ownedAttribute) and operations (+ownedOperation). Especially for operations, I can't see any use for it.
    I propose to change the Superclass of Behavior from 'Class' to 'Classifier' and to add an explicit ownership of Properties, as already done for Signals.
    2) The description and semantics of Behavior immediately refer to a context classifier. As a consequence, the composite relation to 'BehavioredClassifier' should be of multiplicity 1 instead of 0..1 so that a Behavior must always be owned by a BehavioredClassifier.

  • Reported: UML 2.0 — Fri, 19 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    1) The rationale for allowing attributes and operations on behaviors is actually provided in Subclause 12.3.4 for activities. In part: "An activity execution, as a reflective object, can support operations for managing execution, such as starting, stopping, aborting, and so on; attributes, such as how long the process has been executing or how much it costs; and links to objects, such as the performer of the execution, who to report completion to, or resources being used, and states of execution such as started, suspended, and so on." The submitter may not agree with the need for this capability, or desire to use it, but it was specifically included in UML because there are some who do wish to use it.
    2) A behavior may standalone without being owned by any other behaviored classifier. In this case the behavior is implicitly considered to be its own context when executed. Per the Semantics in Subclause 13.3.2: "When a behavior is instantiated as an object, it is its own context."
    Revised Text:
    None
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 - Invalid subsetting of composition ends

  • Key: UML22-144
  • Legacy Issue Number: 8952
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association:

    " • An association with neither end marked by navigability arrows means that:
    • the association is navigable in both directions
    • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)"

    Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2:

    " • An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is owned by the association"

    this means that such non-navigable association ends are owned by the association and not by the class.

    Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute.

    Recommendation:

    (1) Define Element::owner such that it is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid.

    (2) Do this for all other cases of invalid subsets of this type in the spec, if they exist.

    (3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2

  • Reported: UML 2.0 — Mon, 8 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Actions / Compliance Levels of Actions

  • Key: UML22-143
  • Legacy Issue Number: 8951
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Actions for sending events and for calling operations and behavior are part of the "BasicActions" package which is part of Compliance Level 1. Their 'partner' actions for accepting a call or an event, however, are part of the "CompleteActions" package which is part of Compliance Level 3.
    Since there is not much sense in creating events without ever accepting them later, I recommend one of the following:
    a) Accept the first item of Issue 8459 from Mr. Amsden and move "AcceptEventAction" and "AcceptCallAction", too, to a package of L1, preferrably "BasicActions"
    b) Otherwise (if "Communications" remains an L2 package) move these two Actions together with all "InvocationAction" specializations, too, to a package of L2. In this case, maybe a new L2 package like "CommunicationActions" could be created.

  • Reported: UML 2.0 — Thu, 4 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 53-55

  • Key: UML22-162
  • Legacy Issue Number: 9076
  • Status: closed  
  • Source: ZeT ( Jose A. Rodrigues Nt.)
  • Summary:

    In UML v. 2.0, formal/05-07-04: IF 7.3.9 Comment -> Semantics -> "A Comment adds no semantics to the annotated elements,..." AND 7.3.10 Constraint -> "A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element." AND 7.3.10 Constraint -> Semantics -> "A Constraint represents additional semantic information attached to the constrained elements." AND 7.3.10 Constraint -> Presentation Options -> "The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements by a dashed line." THEN Either the constrained element is the "note symbol", the "note symbol" represents a Comment and so a Comment adds semantics to another element or I missed something.

  • Reported: UML 2.0 — Thu, 6 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Just because both a Comment and a Constraint can both be notated using a similar “note symbol” does not mean
    they are the same thing. A Constraint notated using a note symbol in the concrete syntax of a model still maps to a
    Constraint in the abstract syntax representation, not a Comment.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"ownedType" is not a valid element

  • Key: UML22-161
  • Legacy Issue Number: 9024
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Having implemented a UML 2 L0 addin for Rational Rose, I exported a sample model to XMI. When this XMI file was imported into another UML2 tool, the tool failed, indicating that "ownedType" is not a valid element. Examination of the Infrastructure Library reveals why this is so. In the InfrastructureLibrary's Basic package (the basis for UML2 L0), the sole means by which a Package owns items is the "ownedType" reference. However, in The Constructs package (the basis for UML 2 L1 and beyond), this reference is now indicated as derived, meaning that it will not be handled by most UML 2 tools. It has been replaced by the "ownedMember" reference, which is unknown to UML 2 L0.

    This is a showstopper issue with respect to UML2 XMI interoperability, since it means that a UML2 tool operating at Level 0 cannot interchange models with UML2 tools operating at any other level.

  • Reported: UML 2.0 — Tue, 4 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-158
  • Legacy Issue Number: 9012
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Associations can have static ends, but this violates the semantics of static (that they are properties of the class or subclasses, not instances). If we are following programming languages, the semantics of isStatic should be that it is properties of instances, but is the same on all instances. The current semantics would be the right one if isStatic identifies "metaproperties".

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is now covered by the text that says “Where semantics are not explicitly specified for static Features, those
    semantics are undefined” in clause 9.4.3, and also “The semantics are undefined for Associations that have an end
    with isStatic = true” in 16.6.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-157
  • Legacy Issue Number: 9011
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 13, what is the classifier of EnumerationLiteral (inherited from InstanceSpecification)? Presumably it should be the enumeration, with the enumeration end of the association to Enumeration redefining the classifier end from InstanceSpecification in Figure 8. Programs accessing classifiers in the repository should find the enumeration literals as instances of their enumerations.

  • Reported: UML 2.0 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-156
  • Legacy Issue Number: 9009
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, the frontend, backend node description is redundant with the semantics of StructuredActivityNode

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 description of structured node semantics no longer uses the “frontend, backend
    node” terminology, and is no longer redundant.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML SuperStructure - Inconsistency re State Machine terms

  • Key: UML22-146
  • Legacy Issue Number: 8967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    think there is some inconsistency in your usage of terms
    in chapter 15 State Machines.

    It isn't really clear (I think) what you mean sometimes when
    you use the terms "state machine" "behavioral state machines"
    and "protocol state machines".

    In my (humble) opinion you should never use only the term
    "state machine" when you do not mean both "behavioral state
    machine" and "protocol state machine".

    15.3.12 is a perfect example where I think there is confusion,
    or at least lack of clarity, since you talk about "state machines" executing "activities". Clearly, not all state machines do--
    more precisely--protocol state machines don't.

  • Reported: UML 2.0 — Tue, 16 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue was resolved by the UML 2.5 convention of using explicit meta-class names (e.g., StateMachine and ProtocolStateMachine)
    and by isloating the two types of state machines into distinct sections of the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

  • Key: UML22-145
  • Legacy Issue Number: 8965
  • Status: closed  
  • Source: ACTL Systems ltd. ( Dani Mannes)
  • Summary:

    In the UML 1.5 you could specifiy on messages in the collaboration diagram the predesessor. This was very convenient for modeling threads. this has been removed from the UML 2.0. It should be added to the communication diagram message specification.

  • Reported: UML 2.0 — Mon, 15 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In sequence diagram messages are not totally ordered.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

  • Key: UML22-160
  • Legacy Issue Number: 9017
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig 16.3. uses note symbol notation of the Hruby Vision template. That's not conform to UML 2.0 at this point. The end of the note anchor line doesn't have a circle in UML 2.0.

  • Reported: UML 2.0 — Mon, 26 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-159
  • Legacy Issue Number: 9014
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that incoming edges to input pins on structured activities must have sources outside the structured node. Add constraint that incoming edges to output pins on structured activities must have sources inside the structured node.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 420

  • Key: UML22-142
  • Legacy Issue Number: 8945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In addition to the elided pins presentation add presentation option that pins can be omitted without a little box above the line.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Without the little box, the object flow would look identical to a control flow between actions, which would be confusing.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - "provided Port" and "required Port" not defined Constraint 1

  • Key: UML22-36
  • Legacy Issue Number: 7247
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts."

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isComposite inconsistency in UML 2.0 and MOF 2.0

  • Key: UML22-46
  • Legacy Issue Number: 7910
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: – isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. – However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()>isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()>isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

  • Reported: UML 1.4.2 — Mon, 15 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.14.1

  • Key: UML22-48
  • Legacy Issue Number: 7969
  • Status: closed  
  • Source: N/A ( Paul Berry)
  • Summary:

    The allOwnedElements query (defined in Core::Abstractions::Ownerships) operates by recursing downward through the ownership hierarchy. Its OCL implementation looks like this: Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) In the absence of sophisticated optimization, this query is only guaranteed to terminate if the ownership hierarchy is non-circular. The ownership hierarchy is guaranteed to be circular by constraint [1] (An element may not directly or indirectly own itself). But the OCL description of constraint [1] is written in terms of the allOwnedElements() query: not self.allOwnedElements()>includes(self) If a modeling tool were to be written based on these rules in a straightforward way, it would never be able to detect a violation of constraint [1]. Instead it would go into infinite recursion while trying to check the constraint. Proposed solution: Add the following operation to 9.14.1: [3] The query isCircularlyOwned walks the chain of direct and indirect owners of an element, checking whether the chain contains any circularities, or any of the elements in the set prohibitedElements. Element::isCircularlyOwned(prohibitedElements: Set(Element)): Boolean; isCircularlyOwned = if owner>isEmpty() then false else if prohibitedElements->including(self)>includes(owner) then true else owner.isCircularlyOwned(prohibitedElements>including(self)) And change constraint [1] to: [1] An element may not be directly or indirectly owned by itself. not self.isCircularlyOwned(Set{})

  • Reported: UML 2.0 — Sun, 5 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    It is not necessary for the OCL in the specification to be implementable in some “straightforward way”. It is only
    necessary that the OCL have the proper meaning according to OCL semantics, which the identified expressions do.
    An implementation is free to implement them in the manner that the issue author suggests. It is not necessary to
    complicate the specification by adopting a specific implementation approach.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

should retain Comment and its associations to Element

  • Key: UML22-47
  • Legacy Issue Number: 7958
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation sections for TimeObservation and DurationObservation

  • Key: UML22-42
  • Legacy Issue Number: 7304
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The Notation sections for TimeObservation and DurationObservation seem inadequate: 1. The syntax for TimeObservation only allows "now" as a TimeExpression, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for DurationObservation includes the unexplained non-terminal symbol "duration". 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been considered by prior RTFs and deemed out of scope, per the following discussion previously recorded for this issue:
    A proper resolution of this issue depends on changes in progress with respect to the action and activity model. In addition, a more encompassing improvement of the "simple time model" and related concepts is required.
    Thus, the resolution of this issue is best considered to be strategic.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

completion transitions

  • Key: UML22-41
  • Legacy Issue Number: 7254
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors.

  • Reported: UML 1.5 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add a clarification for this case based on the above discussion

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[3]

  • Key: UML22-38
  • Legacy Issue Number: 7249
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[3] Constraint [3] says: "[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port." There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a ConnectableElement. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a ConnectableElement) - what is the "target Interface"? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does "signature compatible" mean for Interfaces?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint [2]

  • Key: UML22-37
  • Legacy Issue Number: 7248
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint [2] Constraint [2] says: "[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an “implements” relationship to the Interface type of that Port." There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a ConnectableElement. 2. What is "the Interface type of that Port" ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This constraint and the following two are currently incomprehensible (see 7249 and 7250). According to Internal Structures, "What makes connectable elements compatible is a semantic variation point." I see no particular reason to change this for components, and given that connectors are n-ary, it would be hard to do so. So I propose simply to delete the constraints. Profiles are free to restrict connectors to binary and to impose signature compatibility, based on type or contract compatibility, if they wish to.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[5]

  • Key: UML22-40
  • Legacy Issue Number: 7251
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[5] Constraint [5] says: "[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port." There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a ConnectableElement. 2. It is not clear what a "required Port" or a "provided Port" is.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[4]

  • Key: UML22-39
  • Legacy Issue Number: 7250
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[4] Constraint [4] says: "[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port." There are two problems with this constraint: 1. What is "the union of the Interfaces of these target Ports"? First, it is not clear, what a "union of interfaces" is. A "union of a set of interfaces" could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because "union of interfaces" is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does "signature compatible" mean?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Presentation Options

  • Key: UML22-50
  • Legacy Issue Number: 7994
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    Presentation Options: Add after first sentence: "State symbols may optionally be used to describe a Constraint" "The regions represent the orthogonal regions of states" - delete this. The identifier need -> The name of the state need

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The text referred in this issue does no longer exist.
    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use case extension inconsistencies

  • Key: UML22-49
  • Legacy Issue Number: 7993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
    Therefore it seems that the Extend.extendedCase property is redundant and should be derived.

    Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the

    {subset}

    .

    Proposed resolution
    -----------------------------

    1) Update Figure 401 to replace +extendedCase by +/extendedCase

    2) Update Figure 401 to replace +useCase by +useCase

    {subsets owner}

    .

    3) Section 16.3.3 Extend: update the Associations section to replace:
    extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

    by

    /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

    4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
    No additional associations

    by

    useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)

  • Reported: UML 1.4.2 — Mon, 20 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationClass

  • Key: UML22-45
  • Legacy Issue Number: 7400
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing.

  • Reported: UML 1.5 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The text in 11.5.3 clearly states that the ownedEnds of an AssociationClass are not
    attributes.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

useless example on p.330, Figure 247

  • Key: UML22-44
  • Legacy Issue Number: 7375
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.330, Figure 247. This example is useless, as it canot be understood without much detail on the FFT computation. It would be better to use examples that readers can readily understand.

  • Reported: UML 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is subjective. Some readers might find the example helpful. The example is useful as a depiction of a realistic computation.
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property defines an association "datatype" which is redundant

  • Key: UML22-43
  • Legacy Issue Number: 7339
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Property defines an association "datatype". This association is redundant for the following reasons: A DataType is a kind of classifier, so saying that a property can be owned by a DataType adds nothing new. (ii) as feature, one can navigate from the property to the featuringClassifier, and so the navigability to an owning data type is already given. Moreover, an association to a data type would be incorrect if the property would otherwise be owned by a different Classifier. Moreover, if this property is owned by a classifier, there is no guarantee that the datatype association references the same DataType. There are no consistency constraints. Anyway, this association is redundant, can possibly lead to inconsistent models, and should be deleted. The last sentence on p.92 "A property may be owned by and in the namespace of a datatype." is correct even if the association is deleted. However, this sentence adds no new information either and is best deleted also.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 14 - 17 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple typos in ptc/04-10-02

  • Key: UML22-57
  • Legacy Issue Number: 8102
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiple typos (If you don't want them submitted this way, I'll complete an issue for each.) section 6.34 page 11 Delete word “to” in “The read/write actions can also be used to by one…” section 7.3.3 page 38 Delete word “If’ in the Note “If the lower multiplicity for an end of…” Section 7.3.5 page 46 Correct typo “pr” to “or” in ownedParameter:Parameter[*] Section 7.3.11 page 60 Change “has” to “have” in 2nd para 2nd sentence “Instances of a data type that “has”…” Instances is the subject of the sentence Section 7.3.11 page 61 Add word “to” to Notation sentence 6 “In this case, cone or more arrows with their tails on the clients are connected “to” the tails…” Section 7.3.20 page 71 Change “is” to are in generalizationSet “Designates a set in which instances of Generalization “are” considered members.” The verb refers to the subject of the which clause (instances). Section 7.3.21 page 83 Change “is” to “if” in last sentence of section “Or, “if” a new subclass…” Section 7.3.32 page 97 Change “These constraint” to “These constraints” Section 7.3.32 page 98 Delete word “is” in 2nd sentence of Notation “In general, the notation will include a multiplicity specification shown as…” Section 7.3.37 page 111 Change “is” to “are” in 4th paragraph of Semantics “The public contents of a package are…” Subject of the sentence is contents not package. Section 7.3.49 page 135 and page 136 (Description) Change verb “specify” to “specifies” in “A structureal feature is a typed feature of a classifier that specifies the structure…” Section 7.3.49 page 137 Change verb from “signifies” to signifying” in 1st sentence of Decsription Section 7.3.53 page 139 Delete word “of” in 1st sentence of Semantics

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the differences between redefining element and redefined element.

  • Key: UML22-56
  • Legacy Issue Number: 8101
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Clarify the differences between redefining element and redefined element.

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All sections

  • Key: UML22-55
  • Legacy Issue Number: 8087
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    With the new format of putting all of the diagrams at the beginning of the chapters, I am finding it very difficult to determine which diagram goes with what sub-section. Add references in the text to the diagram most applicable to the descriptions/definitions

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ClassifierInState not supported in UML2.0 ?

  • Key: UML22-54
  • Legacy Issue Number: 8071
  • Status: closed  
  • Source: GOO Tech ( Birol Berkem)
  • Summary:

    In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.

    Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

  • Reported: UML 1.4.2 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

  • Key: UML22-64
  • Legacy Issue Number: 8126
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-63
  • Legacy Issue Number: 8119
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    "In a system context where there are multople components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors." Combines what? Client keyword missing from fig. 93.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such text in section 8.3.2, or indeed anywhere in the current specification.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constrainedElement direction

  • Key: UML22-51
  • Legacy Issue Number: 8020
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    constrainedElement direction The association between Constraint and Element named "constrainedElement" is unidirectional from Constraint to Element. This means implementations are not required to provide efficient navigation from an element to the constraints on it. Since the constraints of a model element are part of the definition of that element, the required navigation should at least be from the element to the constraint.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    A Constraint can constrain multiple constrainedElements and, thus, is not necessarily owned by any one of them. In
    this sense, the Constraint is not, in general, part of the formal “definition” of the constrainedElements. Rather, if
    the Constraint has a context (which may or may not be a constrainedElement), then it is more proper to think of the
    constraint as part of the definition of that context, and the context association end is navigable.
    Further, one wants to be able to add constraints to elements of the model without having tomodify an owned property
    of the elements being constrained, but making the association from Element to Constraint would imply (by the usual
    UML abstract syntax metamodel conventions) that the “constraint” association end would become owned by Element.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association specialization semantics

  • Key: UML22-53
  • Legacy Issue Number: 8023
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean?

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived union notation

  • Key: UML22-52
  • Legacy Issue Number: 8022
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Derived union notation Why is the semantics and notation for subsetting/redefinition in Association, while derived union is in Property?

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-61
  • Legacy Issue Number: 8114
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.6

  • Key: UML22-60
  • Legacy Issue Number: 8113
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need OCL notation for Constraints. Correct page reference number for StructuredClassifier

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-62
  • Legacy Issue Number: 8118
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Reword/rewrite the last two paragraphs of Semantics. Many grammatical mistakes between sentence subject and verb plurality (because of intervening phrases), hard to understand sentences, and an incomplete sentence (last one).

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such problem in section 8.3.2. However I do find the following, which has duplicated text:
    "A component's behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Component Realization Dependencies to these Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Realization Dependencies to these Classifiers"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-58
  • Legacy Issue Number: 8106
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraints have no OCL syntax or mention that constraints are not definable in OCL. Type in constraint [5] - delete "s" from first "Ports".

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This actually refers to 8.3.3. The constraints have been fixed or deleted by other resolutions (7247-7251).

    Revised Text:
    None.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.4

  • Key: UML22-59
  • Legacy Issue Number: 8111
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reentrancy 1

  • Key: UML22-7
  • Legacy Issue Number: 6111
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How is the effect if isReentrant achieved for actions other than call
    actions? isReentrant is only on behaviors. Perhaps it should also be
    available on actions and operations

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default.
    In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suspension Region

  • Key: UML22-6
  • Legacy Issue Number: 6082
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    “Supspension region” is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call.

    This has been flagged as a potential FTF issue before.

  • Reported: UML 1.5 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Missing OCL constraints

  • Key: UML22-18
  • Legacy Issue Number: 6452
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

03-04-01 Chap 2 p. 112/Components: Different ways to wire components

  • Key: UML22-17
  • Legacy Issue Number: 6433
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
    paragraph says: “A component has a number of provided and required
    Interfaces, that form the basis for wiring components together, either using
    Dependencies, or by using Connectors.” Is this really an either or choice?
    What is the real semantic distinction? And what is the semantic distinction
    between wiring via connectors without ports vs. wiring via connectors with
    ports?

    Recommendation: Clearly specify the semantic distinctions among the three
    ways of wiring components together:

    1) Via Dependencies
    2) Via Connectors without Ports
    3) Via Connectors with Ports.

    If there are no semantic distinctions--that is, if the distinctions are
    purely mechanical--then the specification should probably changed such that
    there is one way to wire components together.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired.
    We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: AssociationEnd

  • Key: UML22-20
  • Legacy Issue Number: 6462
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    In UML 1 the navigability of an association end was specified by the
    meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
    meta-attribute dissapears, and AssociationEnd is substituted by Property. We
    know whether an association end is navigable by the following rule: if the
    property is owned by a class, it represents a navigable end; if the property
    is owned by an association, it represents a non-navigable end (see
    Superstructure, p. 89). However, references to old metaclass AssociationEnd
    and old meta-attribute isNavigable still appear in the Spec in several
    places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
    33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
    245).

    PROPOSED SOLUTION
    Add derived meta-attribute /isNavigable to metaclass Property.
    Eliminate references to AssociationEnd.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

instantiations of Classifiers

  • Key: UML22-19
  • Legacy Issue Number: 6455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    7 and 14: "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] There are no objects in a UML 2 model, but only models of objects, that is, instance specifications. The instantiation of a UML class is not in the model, but in the modeled system. At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution: Abandon the idea that there are no objects in a model. Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model. Likewise for an association and its links, and so on.

    This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.

    It is consistent with the existence of power types in the language.

    It is consistent with the MOF specification of meta-layers.

    It removes the conflation of the type conformance and instatiation relationships with the representation relationship. It reduces the meanings conflated into 'instance of' by one.

    Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The change proposed in the issue is fundamentally different than the basic interpretation of models in UML.
    Further, the assertion that UML “places instantiations of Behaviors in the UML model (not in the modeled
    system)” is not correct. An instance of a Behavior is an execution (in the modeled system), while an
    ExecutionOccurrence is a model of such an instance. This is quite similar to the difference between an
    instance and an InstanceSpecification. The UML 2.5 specification is now clearer on this.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.3

  • Key: UML22-15
  • Legacy Issue Number: 6422
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration. I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section. In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Original discussion:
    The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4.
    New comments (March 2009):
    This issue dates back to 2003. I propose we close it on the grounds of cost/benefit.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/missing OCL constraints

  • Key: UML22-14
  • Legacy Issue Number: 6409
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Not all the constraints in the Interactions section (14.3). They should be added

  • Reported: UML 1.5 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/redefinition and substitutability

  • Key: UML22-10
  • Legacy Issue Number: 6200
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The specific issue with state machines no longer applies, having been resolved in an earlier RTF. The general
    issue about redefinition is a complaint about a fundamental characteristic of UML semantics which are by
    now quite well understood. Changing these semantics would be very fundamental and disruptive.
    This also resolves issue 14929.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Target pin notation

  • Key: UML22-9
  • Legacy Issue Number: 6126
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On CallOperationAction, etc, how do you tell graphically which pin is
    the target?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notes versus curly braces

  • Key: UML22-12
  • Legacy Issue Number: 6372
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why do decision input behaviors use the note notation and join
    specification use curly braces?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and").
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity OCL

  • Key: UML22-11
  • Legacy Issue Number: 6346
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Not all the constraints in the Activities section have corresponding OCL
    specifications. These should be added

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints related to Activities that can be given OCL now have OCL in UML
    2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/ad-03-04-01/Derived attributes and associations

  • Key: UML22-16
  • Legacy Issue Number: 6430
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: There are many places where the specification indicates that an
    attribute or association is derived, but does not state how it is derived;
    that is, the specification does not state, in English or in OCL, how to
    compute the derivation.

    Recommendation: Specify, in English and OCL, how to compute the derivations
    of all derived attributes and associations.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Dependencies / improper subsetting?

  • Key: UML22-13
  • Legacy Issue Number: 6405
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty...

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State extension

  • Key: UML22-8
  • Legacy Issue Number: 6114
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    State should be an extension of type rather than object node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of firing compound transitions still appears to be circular

  • Key: UML22-1
  • Legacy Issue Number: 4110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

    As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

    On page 2-173 of 2.12:

        • The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

    If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

    [...]

    Once a transition is enabled and is selected to fire, the following steps are carried out in order:

    • The main source state is properly exited.

    • Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

    • If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

    • The main target state is properly entered. ***

    This is certainly much better than 1.3. But I still find it difficult to follow:

    Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

    The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

    If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

    With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

  • Reported: UML 1.3 — Thu, 7 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Remove the paragraph explaining the LCA from the “Transition execution sequence” section and add an
    explanation of LCA to the “Transition ownership” section

  • Updated: Fri, 6 Mar 2015 20:58 GMT