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"