Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 421
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML2-4 section 8.3.2, a "Connector" UML 1.5 UML 2.0 Resolved closed
UML2-3 Property.association UML 1.5 UML 2.0 Resolved closed
UML2-2 Activity Diagrams: Relax Traverse-to-Completion semantics UML 1.5 UML 2.0 Resolved closed
UML22-531 In 2.13.3, the first sub-section about ActivityGraph is not numbered UML 1.5 UML 2.1 Resolved closed
UML22-530 At the bottom of the page, the characters "antics." should be removed UML 1.5 UML 2.1 Resolved closed
UML22-529 missing closing parenthesis UML 1.5 UML 2.1 Resolved closed
UML22-528 The Composition section does not follow the usual conventions UML 1.5 UML 2.1 Resolved closed
UML22-527 The section about Procedure does not contain any well-formedness rules UML 1.5 UML 2.1 Resolved closed
UML22-526 In "2.9.3.5 Instance", numbering of different well-formedness rules wrong UML 1.5 UML 2.1 Resolved closed
UML22-525 The numbering of the sub-sections in 2.7.2 is wrong UML 1.5 UML 2.1 Resolved closed
UML22-524 UML 2.0 infra and super Constraints Diagram of the Kernel UML 1.5 UML 2.1 Resolved closed
UML22-523 Associations section of element JumpHandler UML 1.5 UML 2.1 Resolved closed
UML22-522 Remove one of the dots between protectedAction and availableOutput UML 1.5 UML 2.1 Resolved closed
UML22-521 Operations and derived attributes UML 1.5 UML 2.1 Resolved closed
UML22-519 In the last paragraph, the period after the word "collections" on the secon UML 1.5 UML 2.1 Resolved closed
UML22-518 In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11 UML 1.5 UML 2.1 Resolved closed
UML22-517 The multiplicity of association named subaction of type Action ill formed UML 1.5 UML 2.1 Resolved closed
UML22-516 multiplicity of the association named "type" of type DataType UML 1.5 UML 2.1 Resolved closed
UML22-515 well-formedness rules are not numbered correctly UML 1.5 UML 2.1 Resolved closed
UML22-514 number of the figure is wrong UML 1.5 UML 2.1 Resolved closed
UML22-513 remove paragraph UML 1.5 UML 2.1 Resolved closed
UML22-512 UML 2 Infra/Metamodel/missing derivation indicators UML 1.5 UML 2.1.2 Resolved closed
UML22-511 UML 2 Super / Classes / dependencies should be unidirectional UML 1.5 UML 2.1 Resolved closed
UML22-510 two classes "NamedElement UML 1.5 UML 2.1 Resolved closed
UML22-509 class "InfrastructureLibrary.core.constructs.Association", UML 1.5 UML 2.1 Resolved closed
UML22-508 Why not using the UML1 activity symbol for UML2 actions? UML 1.5 UML 2.1 Resolved closed
UML22-507 Multiplicity seems to be broken - UML2 Infra & Super UML 1.5 UML 2.1 Resolved closed
UML22-506 Rose Model of UML 2.0 spec UML 1.5 UML 2.1 Resolved closed
UML22-505 ptc-03-09-15/Relationships among Core packages UML 1.5 UML 2.1 Resolved closed
UML22-504 ptc-03-09-15/Constructs::Class superClass property UML 1.5 UML 2.1 Resolved closed
UML22-503 ptc-03-09-15/Non-navigable ends with no role names nor multiplicities UML 1.5 UML 2.1 Resolved closed
UML22-502 UML 2 Issue: Message notation UML 1.5 UML 2.1 Resolved closed
UML22-501 UML 2 Issue: definition of navigability UML 1.5 UML 2.1.2 Resolved closed
UML22-500 Use 'represent' for the relationship of a model UML 1.5 UML 2.1 Resolved closed
UML22-499 UML 2 Super / Dependency / ownership of dependencies UML 1.5 UML 2.1 Resolved closed
UML22-498 Clarification of Information Flow semantics UML 1.5 UML 2.1 Resolved closed
UML22-497 Activity diagram problems UML 1.5 UML 2.1 Resolved closed
UML22-496 Section 9.3.4 page 161, Presentation Option UML 1.5 UML 2.1 Resolved closed
UML22-495 UML 2 Super / Kernel features / cannot exclude superclass properties UML 1.5 UML 2.1 Resolved closed
UML22-494 Syntax of names UML 1.5 UML 2.1 Resolved closed
UML22-493 raisedException UML 1.5 UML 2.1 Resolved closed
UML22-492 UML 2 Super / Templates / TemplateParameter not named UML 1.5 UML 2.1 Resolved closed
UML22-491 UML 2 Super/pg.75/kinds of changeability UML 1.5 UML 2.1 Resolved closed
UML22-490 UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" UML 1.5 UML 2.1 Resolved closed
UML22-489 UML 2 Super/Metamodel::Kernel/missing merges UML 1.5 UML 2.1 Resolved closed
UML22-488 UML 2 Super/Package merge/redefinitions issue - lost association ends UML 1.5 UML 2.1 Resolved closed
UML22-487 UML 2 Super/Metamodel::Super/missing merge UML 1.5 UML 2.1 Resolved closed
UML22-486 UML 2 Super/Metamodel::Constructs/owningComment UML 1.5 UML 2.1 Resolved closed
UML22-481 relationship should just be a cross-reference UML 1.5 UML 2.1 Resolved closed
UML22-480 formal/03-03-01 : Omission of definition of Class "Action" UML 1.5 UML 2.1 Resolved closed
UML22-479 logic upperbound is the same as the lower bound. UML 1.5 UML 2.1 Resolved closed
UML22-45 AssociationClass UML 1.5 UML 2.2 Resolved closed
UML22-41 completion transitions 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-29 Part subtype 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-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-25 Federated models - UML2 issue 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-22 UML 2 Issue: Qualified pathnames UML 1.5 UML 2.2 Resolved closed
UML22-21 UML 2 Issue: isUnique 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-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-16 UML2 super/ad-03-04-01/Derived attributes and associations 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-13 UML 2 super / Dependencies / improper subsetting? 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-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-8 State extension UML 1.5 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-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
UML14-557 Feature;ModelElement UML 1.5 UML 1.4.2 Resolved closed
UML14-469 UML 2 Super / use cases / invalid subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-468 UML 2 Super / state machines / non-existent return type UML 1.5 UML 1.4.2 Resolved closed
UML14-467 UML 2 Super / state machines / misplaced operation definition UML 1.5 UML 1.4.2 Resolved closed
UML14-466 UML 2 Super / state machines / incorrect property redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-465 UML 2 Super / state machines / non-existent property reference UML 1.5 UML 1.4.2 Resolved closed
UML14-464 UML 2 Super / state machines / oclIsKindOf arguments error UML 1.5 UML 1.4.2 Resolved closed
UML14-463 UML 2 Super/State machines/pseudostate name consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-462 Ambuiguity in value pin evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-461 page 136, "BasicComponents", UML 1.5 UML 1.4.2 Resolved closed
UML14-460 Consistent Naming UML 1.5 UML 1.4.2 Resolved closed
UML14-459 UML2 Super/Signal UML 1.5 UML 1.4.2 Resolved closed
UML14-458 UML 2 Super / Activities / subsetting two properties UML 1.5 UML 1.4.2 Resolved closed
UML14-457 UML 2 Super / Activities / association end naming UML 1.5 UML 1.4.2 Resolved closed
UML14-456 UML 2 Super / Activities / inconsistency in representing subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-455 UML 2 Super/Activities/invalid multiplicity 0 UML 1.5 UML 1.4.2 Resolved closed
UML14-454 UML 2 Super/Activities/assocition end specialization consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-453 UML 2 Super/Activities/end naming consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-452 subsettedProperty->forAll(sp | isDerivedUnion) ? UML 1.5 UML 1.4.2 Resolved closed
UML14-451 UML2 Super/Connector End UML 1.5 UML 1.4.2 Resolved closed
UML14-450 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-449 UML2 Super/Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-448 Page 164 - there are two constraints sections for Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-447 UML2 Super/Structured Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-446 UML2 Super/parts UML 1.5 UML 1.4.2 Resolved closed
UML14-445 UML2 Super/Composite Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-444 UML 2.0 Superstructure Derived Union vs. derivationExpression? UML 1.5 UML 1.4.2 Resolved closed
UML14-442 UML 2 Super / use cases / incorrect comments in notation section UML 1.5 UML 1.4.2 Resolved closed
UML14-441 Error in definition of PackageMergeKind UML 1.5 UML 1.4.2 Resolved closed
UML14-440 UML 2.0 Superstructure 3rd revision - Owner of triggers? UML 1.5 UML 1.4.2 Resolved closed
UML14-439 UML 2 Super/Action/featuringClassifier misinterpreted UML 1.5 UML 1.4.2 Resolved closed
UML14-438 UML 2 Super/Actions/non-existent feature "multiplicity" UML 1.5 UML 1.4.2 Resolved closed
UML14-437 section 9 (State Machines) of 3rd revision UML 1.5 UML 1.4.2 Resolved closed
UML14-436 UML 2 Super/Actions/PrimitiveFunction missing properties UML 1.5 UML 1.4.2 Resolved closed
UML14-435 Notation when guards are used in conjunction with triggers in transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-434 Time trigger notation in state machines UML 1.5 UML 1.4.2 Resolved closed
UML14-433 No way to represent "uninterpreted" actions UML 1.5 UML 1.4.2 Resolved closed
UML14-432 Missing actual arguments in submachines states UML 1.5 UML 1.4.2 Resolved closed
UML14-431 Incorrect usage/definition of "emergence" in Common Behavior Chapter UML 1.5 UML 1.4.2 Resolved closed
UML14-430 /pages 485,487,495/mixed names for state machine diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-429 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-428 Order cancel request UML 1.5 UML 1.4.2 Resolved closed
UML14-427 The node "Order cancel request" that appears in figure 6-86 UML 1.5 UML 1.4.2 Resolved closed
UML14-426 GeneralizationSet Description clarification - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-425 Activity nodes and Stereotypes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-424 does "is not instantiable" imply "isAbstract"? - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-423 Package Extensibility <> - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-422 Dependency notation for interfaces - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-421 Inconsistency concerning VisibilityKind - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-420 Operation without - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-419 Components and artifacts: Dependency problem - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-418 Guard conditions at fork nodes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-417 Token flow semantics: Implicit fork and join - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-416 AcitivityEdge: weight=all vs weight=null - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-415 Large diamond for binary associations legal? - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-414 Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-413 Binary associations decorated with large diamonds legal? UML 1.5 UML 1.4.2 Resolved closed
UML14-412 concurrent vs. parallel ExpansionRegions UML 1.5 UML 1.4.2 Resolved closed
UML14-411 Use Case Metamodel - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-410 ActivityFinalNode and running actions - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-409 Multiobject in UML2 UML 1.5 UML 1.4.2 Resolved closed
UML14-408 Outputting constants UML 1.5 UML 1.4.2 Resolved closed
UML14-407 Protocol machines do not subset state invariant UML 1.5 UML 1.4.2 Resolved closed
UML14-406 Conditions for parameter sets (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-405 Clarify termination of asynchronous invocations UML 1.5 UML 1.4.2 Resolved closed
UML14-404 Appendix A Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-403 Section 17 UML 1.5 UML 1.4.2 Resolved closed
UML14-402 Section 14.4 Diagrams (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-401 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-400 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-399 Section 14.3.14 Message UML 1.5 UML 1.4.2 Resolved closed
UML14-398 Section 10 Deployments UML 1.5 UML 1.4.2 Resolved closed
UML14-397 Section 9.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-396 Section 8.3.3 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-395 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-394 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-393 Section 8.1 Overview UML 1.5 UML 1.4.2 Resolved closed
UML14-392 Section 7.18 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-391 Section 7.15.3 Interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-390 Section 7.13.2 Package Merge UML 1.5 UML 1.4.2 Resolved closed
UML14-389 Section 7.3.5 PackageImport UML 1.5 UML 1.4.2 Resolved closed
UML14-388 Section 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-387 UML 2 Issue: Include(s) and Extend(s) UML 1.5 UML 1.4.2 Resolved closed
UML14-386 UML 2 Issue: Connector types UML 1.5 UML 1.4.2 Resolved closed
UML14-385 glossary UML 1.5 UML 1.4.2 Resolved closed
UML14-384 Change 'Part' to 'Role. UML 1.5 UML 1.4.2 Resolved closed
UML14-383 Abandon the OMGS4LMMA UML 1.5 UML 1.4.2 Resolved closed
UML14-382 14.3: StateInvariant and ExecutionOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-381 UML 2.0 Superstructure FTF issue - Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-380 Removal of gratuitous restrictions to software applications UML 1.5 UML 1.4.2 Resolved closed
UML14-379 Diagram Taxonomy corrections UML 1.5 UML 1.4.2 Resolved closed
UML14-378 Inconsistent use of terms "implement" and "realize" UML 1.5 UML 1.4.2 Resolved closed
UML14-377 Corrections and improvements to glossary definitions UML 1.5 UML 1.4.2 Resolved closed
UML14-376 The name "required interface" is misleading UML 1.5 UML 1.4.2 Resolved closed
UML14-375 Specification of parametric models UML 1.5 UML 1.4.2 Resolved closed
UML14-374 Excessive syntactic and semantic overlap between structured Classifiers UML 1.5 UML 1.4.2 Resolved closed
UML14-373 UML 2.0 significant typo - collaboration diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-372 targetScope on StructuralFeature and AssociationEnd UML 1.5 UML 1.4.2 Resolved closed
UML14-371 UML Superstructure: 03-08-02 / <> UML 1.5 UML 1.4.2 Resolved closed
UML14-370 ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort UML 1.5 UML 1.4.2 Resolved closed
UML14-369 ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint UML 1.5 UML 1.4.2 Resolved closed
UML14-368 Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-367 ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-366 ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2 UML 1.5 UML 1.4.2 Resolved closed
UML14-365 ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation UML 1.5 UML 1.4.2 Resolved closed
UML14-364 UML 2 Infras./Interactions/ execution occurrence should not be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-363 UML 2 super / Templates / parameters cannot have names UML 1.5 UML 1.4.2 Resolved closed
UML14-362 UML 2 Super / Deployments / node composition UML 1.5 UML 1.4.2 Resolved closed
UML14-361 UML 2 Super / Package Templates / StringExpression inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-360 UML 2 Super / Activities / inconsistent naming UML 1.5 UML 1.4.2 Resolved closed
UML14-359 UML 2 Super / Simple Time / incorrect multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-358 UML 2 Super / Interface / missing owner of operation UML 1.5 UML 1.4.2 Resolved closed
UML14-357 UML 2 super / Activities / structured activity node contradiction UML 1.5 UML 1.4.2 Resolved closed
UML14-356 UML 2 Super / Interfaces / Cannot nest classes in interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-355 UML 2 Super / state machines / restriction on redefining transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-354 UML 2 super / state machines / entry and exit actions cannot be redefined UML 1.5 UML 1.4.2 Resolved closed
UML14-353 Figure 395 requires a lot more explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-352 Typo on Notation for CombinedFragment? UML 1.5 UML 1.4.2 Resolved closed
UML14-351 Visibility of a Package UML 1.5 UML 1.4.2 Resolved closed
UML14-350 Questions about CentralBufferNode semantic UML 1.5 UML 1.4.2 Resolved closed
UML14-349 AcceptCallAction in SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-348 Terminating a SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-347 Flows across SAN boundaries UML 1.5 UML 1.4.2 Resolved closed
UML14-346 Initial nodes in structured actions UML 1.5 UML 1.4.2 Resolved closed
UML14-345 Parameters in Features and Common Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-344 Join example UML 1.5 UML 1.4.2 Resolved closed
UML14-343 Clarify join rules UML 1.5 UML 1.4.2 Resolved closed
UML14-342 Clarify join specs referencing control flow edges UML 1.5 UML 1.4.2 Resolved closed
UML14-341 Combining joined tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-340 Clarify ReadSelfAction in activity behaviors UML 1.5 UML 1.4.2 Resolved closed
UML14-339 ReadSelfAction with no host UML 1.5 UML 1.4.2 Resolved closed
UML14-338 Decision behaviors on control tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-337 Guard evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-336 Side effects of value specifications UML 1.5 UML 1.4.2 Resolved closed
UML14-335 Activity final clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-334 Caption typo UML 1.5 UML 1.4.2 Resolved closed
UML14-333 Guards on initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-332 Outgoing edges of initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-331 Port is a Property in XMI UML 1.5 UML 1.4.2 Resolved closed
UML14-330 Ports as properties UML 1.5 UML 1.4.2 Resolved closed
UML14-329 partWithPort without ports UML 1.5 UML 1.4.2 Resolved closed
UML14-328 Association end names and part types UML 1.5 UML 1.4.2 Resolved closed
UML14-327 Deployment location UML 1.5 UML 1.4.2 Resolved closed
UML14-326 InformationFlow realization UML 1.5 UML 1.4.2 Resolved closed
UML14-325 Dependency multiplicity to CollaborationOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-324 Control at joins UML 1.5 UML 1.4.2 Resolved closed
UML14-323 Control pins UML 1.5 UML 1.4.2 Resolved closed
UML14-322 Profiles in fixed repositories UML 1.5 UML 1.4.2 Resolved closed
UML14-321 description of Component on page 137 UML 1.5 UML 1.4.2 Resolved closed
UML14-320 Figure 61 UML 1.5 UML 1.4.2 Resolved closed
UML14-319 UML2 Super/Instances UML 1.5 UML 1.4.2 Resolved closed
UML14-318 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-317 UML 2 Super/Components & Deployment chapters missing OCL constraints UML 1.5 UML 1.4.2 Resolved closed
UML14-316 UML2 Super/Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-315 UML2 Super/Kernel::Classifier UML 1.5 UML 1.4.2 Resolved closed
UML14-314 UML2 Super/Composite Structures UML 1.5 UML 1.4.2 Resolved closed
UML14-313 UML2.super (or infra)/Profiles-Stereotype (18.3.7) UML 1.5 UML 1.4.2 Resolved closed
UML14-312 PackageMerge (from Kernel) UML 1.5 UML 1.4.2 Resolved closed
UML14-311 Sequence diagram conditions on Message arrows UML 1.5 UML 1.4.2 Resolved closed
UML14-310 Recommendation for InteractionOccurrences UML 1.5 UML 1.4.2 Resolved closed
UML14-309 UML 2 Super / Interactions / No way to model reply messages UML 1.5 UML 1.4.2 Resolved closed
UML14-308 UML Superstructur 03-08-02: Notation for ConditionalNode is missing UML 1.5 UML 1.4.2 Resolved closed
UML14-307 UML 2 Super / Interactions / no create message UML 1.5 UML 1.4.2 Resolved closed
UML14-306 UML2 Super / Primitive Types / implementation issue UML 1.5 UML 1.4.2 Resolved closed
UML14-305 UML 2 Super / State machines-CommonBehavior / undefined owner of triggers UML 1.5 UML 1.4.2 Resolved closed
UML14-304 UML2 Super / SimpleTime package / missing multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-303 UML2 Super / association end naming convention UML 1.5 UML 1.4.2 Resolved closed
UML14-302 UML2 Super / Classes/ Incorrect reference to "access" UML 1.5 UML 1.4.2 Resolved closed
UML14-301 What does redefines mean in package extensibility? UML 1.5 UML 1.4.2 Resolved closed
UML14-300 Defenition of redefines????? UML 1.5 UML 1.4.2 Resolved closed
UML14-299 UML 2 super/Composite Classes/Connecting parts of parts UML 1.5 UML 1.4.2 Resolved closed
UML14-298 fig236 Datastore example/Datastore should not directly linked with actions UML 1.5 UML 1.4.2 Resolved closed
UML14-297 UML 2 Super/p125 and p126/typos UML 1.5 UML 1.4.2 Resolved closed
UML14-296 UML super/Section 2/Compliance points UML 1.5 UML 1.4.2 Resolved closed
UML14-295 Question about InterruptibleActivityRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-294 fig 141 p205 and 7.13.2 p101 / just what sort of relationship is < UML 1.5 UML 1.4.2 Resolved closed
UML14-293 Metamodel for applying a stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-292 Association not affecting ends UML 1.5 UML 1.4.2 Resolved closed
UML14-291 Confusion regarding XMI for use of stereotypes UML 1.5 UML 1.4.2 Resolved closed
UML14-290 Actors that are outside and inside the system UML 1.5 UML 1.4.2 Resolved closed
UML14-289 UML2 super/pgs.17 + 598/"topLevel" UML 1.5 UML 1.4.2 Resolved closed
UML14-288 Actor UML 1.5 UML 1.4.2 Resolved closed
UML14-287 Multiplicity of Regions owning Transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-286 State list UML 1.5 UML 1.4.2 Resolved closed
UML14-285 UML 2.0 serious layout problems with activity diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-284 Stereotypes for Actions UML 1.5 UML 1.4.2 Resolved closed
UML14-283 UML Superstructure: 03-08-02 / Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-282 UML 2 Super/Compliance points/confusing and redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-281 UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-280 UML 2 Super/pg.379/anyTrigger clarifications UML 1.5 UML 1.4.2 Resolved closed
UML14-279 UML 2 Super/pg. 556/notation for template binding inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-278 UML 2 Super/pg. 471/choice pseudostate notation UML 1.5 UML 1.4.2 Resolved closed
UML14-277 UML 2 Super/pg.471/unclear terminate state semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-276 UML 2 Super/pg.519/multiplicity semantics of use case associations UML 1.5 UML 1.4.2 Resolved closed
UML14-275 UML 2 Super/pg.427/missing notation description for lifelines UML 1.5 UML 1.4.2 Resolved closed
UML14-274 UML 2 Super/pg.429/incorrect constraint for Message UML 1.5 UML 1.4.2 Resolved closed
UML14-273 UML 2 Super/pg.416/incorrect multiplicities for event occurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-272 UML 2 Super/pg.395/multiple meaning of exception UML 1.5 UML 1.4.2 Resolved closed
UML14-271 UML 2 Super/pg.235/missing semantics of destroy action UML 1.5 UML 1.4.2 Resolved closed
UML14-270 UML 2 Super/pg.130/incorrect stereotype name UML 1.5 UML 1.4.2 Resolved closed
UML14-269 UML 2 Super/pg.130/missing notation explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-268 UML 2 Super/pg.99/misnamed "packageMerge" attribute UML 1.5 UML 1.4.2 Resolved closed
UML14-267 UML 2 Super/pg.109/Permission redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-266 UML 2 Super/pg.95/attributes in data types clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-265 UML 2 Super/pg.64/Classifier redefinition notation UML 1.5 UML 1.4.2 Resolved closed
UML14-264 UML 2 Super/pg.79/underlined operation syntax missing UML 1.5 UML 1.4.2 Resolved closed
UML14-263 UML 2 Super/pg.78/missing return types syntax UML 1.5 UML 1.4.2 Resolved closed
UML14-262 UML 2 Super/pg.78/operation redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-261 UML 2 Super/Spec/completing mandatory sections UML 1.5 UML 1.4.2 Resolved closed
UML14-260 UML 2 Super/Metamodel/missing source and target for InformationFlow UML 1.5 UML 1.4.2 Resolved closed
UML14-259 ProtocolStateMachines/ProtocolStateMachine not a type of Feature UML 1.5 UML 1.4.2 Resolved closed
UML14-258 UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements UML 1.5 UML 1.4.2 Resolved closed
UML14-257 UML 2 Super/Metamodel/missing namespaces for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-256 UML 2 Super/Metamodel/missing owners for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-255 UML 2 Super/Metamodel/mis-spelled implementingClassifier" UML 1.5 UML 1.4.2 Resolved closed
UML14-254 UML 2 Super/Metamodel/Mis-named Manifestation class UML 1.5 UML 1.4.2 Resolved closed
UML14-253 UML 2 Super/Metamodel::Templates/missing return type UML 1.5 UML 1.4.2 Resolved closed
UML14-252 UML 2 Super/Metamodel::CommonBehaviors/redundant class? UML 1.5 UML 1.4.2 Resolved closed
UML14-251 Profile/inability to attach a stereotype to an element UML 1.5 UML 1.4.2 Resolved closed
UML14-250 UML 2 Super/Package Merge/missing rule for operations UML 1.5 UML 1.4.2 Resolved closed
UML14-249 UML 2 Super/Metamodel::Compliance::L3/Missing merges UML 1.5 UML 1.4.2 Resolved closed
UML14-248 UML 2 Super/Metamodel::StructuredActivities/double redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-247 UML 2 Super/Metamodel::BasicActivities/inGroup problem UML 1.5 UML 1.4.2 Resolved closed
UML14-246 UML 2 Super/Metamodel::StructuredClasses/erroneous association UML 1.5 UML 1.4.2 Resolved closed
UML14-245 UML 2 Super/Package Merge/redefinition rules and standard OO languages UML 1.5 UML 1.4.2 Resolved closed
UML14-244 UML 2 Infra/Section 5.9/missing merge rules UML 1.5 UML 1.4.2 Resolved closed
UML14-243 UML 2 Super/Metamodel/package merge and visibility UML 1.5 UML 1.4.2 Resolved closed
UML14-242 UML 2 Super/Metamodel/merging of non-redefinable model elements UML 1.5 UML 1.4.2 Resolved closed
UML14-241 UML 2 Super/Metamodel::Constructs/inconsistency with Kernel UML 1.5 UML 1.4.2 Resolved closed
UML14-240 UML 2 Super/Metamodel::BasicBehaviors/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-239 UML 2 Super/Metamodel::Kernel::Packages/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-238 UML 2 Super/Metamodel::Kernel::DataTypes/missing renames UML 1.5 UML 1.4.2 Resolved closed
UML14-237 AuxiliaryConstructs::Templates::Operation/extra space UML 1.5 UML 1.4.2 Resolved closed
UML14-236 UML 2 Super/Metamodel::Nodes/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-235 UML 2 Super/Metamodel::Communications/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-234 UML 2 Super/Metamodel::IntermediateActivities/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-233 BehaviorStateMachines/missing owningState end name UML 1.5 UML 1.4.2 Resolved closed
UML14-232 UML 2 Super/Metamodel::BasicBehaviors/package merge issue UML 1.5 UML 1.4.2 Resolved closed
UML14-231 7.15.3 Interface UML 1.5 UML 1.4.2 Resolved closed
UML14-230 7.14.6 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-229 7.14.1 Abstraction UML 1.5 UML 1.4.2 Resolved closed
UML14-228 7.11.2 Association UML 1.5 UML 1.4.2 Resolved closed
UML14-227 7.10.1 Operation UML 1.5 UML 1.4.2 Resolved closed
UML14-226 InstanceSpecification UML 1.5 UML 1.4.2 Resolved closed
UML14-225 7.4.1 Multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-224 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-223 No notation defined for suppressing attributes or operations UML 1.5 UML 1.4.2 Resolved closed
UML14-222 Notation mismatch for the realization dependency UML 1.5 UML 1.4.2 Resolved closed
UML14-221 UML Superstructure 03-08-02: Loop node notation missing UML 1.5 UML 1.4.2 Resolved closed
UML14-220 UML Superstructure: 03-08-02 -- typos UML 1.5 UML 1.4.2 Resolved closed
UML14-219 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-218 Clarify that profiles can contain model libraries UML 1.5 UML 1.4.2 Resolved closed
UML14-217 Notation for anonymous instance UML 1.5 UML 1.4.2 Resolved closed
UML14-216 Instantiates stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-215 Notation for attributes UML 1.5 UML 1.4.2 Resolved closed
UML14-214 Property string undefined UML 1.5 UML 1.4.2 Resolved closed
UML14-213 Kernel::Classifier missing "attribute" UML 1.5 UML 1.4.2 Resolved closed
UML14-212 Replace "initial value" with "default value". UML 1.5 UML 1.4.2 Resolved closed
UML14-211 TimeObservationAction can't return values UML 1.5 UML 1.4.2 Resolved closed
UML14-210 Interactions view of state machines/activities UML 1.5 UML 1.4.2 Resolved closed
UML14-209 Protocol state machines are not pre/postconditions UML 1.5 UML 1.4.2 Resolved closed
UML14-208 Diamond notation for merge junctions UML 1.5 UML 1.4.2 Resolved closed
UML14-207 Activity attributes on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-206 Concrete Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-205 Complex port UML 1.5 UML 1.4.2 Resolved closed
UML14-204 Composite structure dependent on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-203 Action packaging UML 1.5 UML 1.4.2 Resolved closed
UML14-202 BroadcastSignalAction UML 1.5 UML 1.4.2 Resolved closed
UML14-201 actions on properties that are association ends UML 1.5 UML 1.4.2 Resolved closed
UML14-200 Update actions for isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-199 Activity frame and parameter nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-198 Activity frame and parameter nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-197 Partition semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-196 Time spec text UML 1.5 UML 1.4.2 Resolved closed
UML14-195 Pins on structured nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-194 Pins on structured nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-193 ExpansionRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-192 ExceptionHandler 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-191 SendObjectAction UML 1.5 UML 1.4.2 Resolved closed
UML14-190 Clarification of insert UML 1.5 UML 1.4.2 Resolved closed
UML14-189 No-token activity termination clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-188 Notation for isSynchronous UML 1.5 UML 1.4.2 Resolved closed
UML14-187 Notation for for global pre/postconditions actions UML 1.5 UML 1.4.2 Resolved closed
UML14-186 Value Pin notation UML 1.5 UML 1.4.2 Resolved closed
UML14-185 Colon notation for pins UML 1.5 UML 1.4.2 Resolved closed
UML14-184 Local pre/postcondition example UML 1.5 UML 1.4.2 Resolved closed
UML14-183 Behavior execution instances UML 1.5 UML 1.4.2 Resolved closed
UML14-182 Parameter semantics clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-181 Streaming UML 1.5 UML 1.4.2 Resolved closed
UML14-180 Parameter set corrections 6 UML 1.5 UML 1.4.2 Resolved closed
UML14-179 Parameter set corrections 5 UML 1.5 UML 1.4.2 Resolved closed
UML14-178 Parameter set corrections 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-177 Parameter set corrections 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-176 Parameter set corrections 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-175 Parameter set corrections 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-174 ObjectNode.isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-173 Reentrancy 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-172 ExecutableNode, ControlNode should be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-171 ObjectFlowEffect UML 1.5 UML 1.4.2 Resolved closed
UML14-170 Optional parameters UML 1.5 UML 1.4.2 Resolved closed
UML14-169 Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-168 Pin/parameter matching 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-167 Pin/parameter matching 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-166 Pin/parameter matching 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-165 Pin/parameter matching 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-164 Pins owned twice UML 1.5 UML 1.4.2 Resolved closed
UML14-163 Multiple outputs of object flow transformations UML 1.5 UML 1.4.2 Resolved closed
UML14-162 Keywords or properties UML 1.5 UML 1.4.2 Resolved closed
UML14-161 ExpansionRegions keywords UML 1.5 UML 1.4.2 Resolved closed
UML14-160 ActivityFinalNode UML 1.5 UML 1.4.2 Resolved closed
UML14-159 Tokens at fork UML 1.5 UML 1.4.2 Resolved closed
UML14-158 Weight=all UML 1.5 UML 1.4.2 Resolved closed
UML14-157 Provide notations for Loop and Conditional UML 1.5 UML 1.4.2 Resolved closed
UML14-156 Action should be concrete UML 1.5 UML 1.4.2 Resolved closed
UML14-155 Edge constraint for control nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-154 Clarify wording on executable activity nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-153 Outgoing edges from input pins UML 1.5 UML 1.4.2 Resolved closed
UML14-152 Variable and Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-151 running a “Check Model” in Rose you get the following errors UML 1.5 UML 1.4.2 Resolved closed
UML14-150 UML2 super/pg. 580/Stereotype typo UML 1.5 UML 1.4.2 Resolved closed
UML14-149 UML2 super/pg.470/entry and exit points for composite states UML 1.5 UML 1.4.2 Resolved closed
UML14-148 Multiplicities diagram in section 7.4 UML 1.5 UML 1.4.2 Resolved closed
UML14-147 No Glossary in 03-08-02 UML 1.5 UML 1.4.2 Resolved closed
UML14-146 Strange notation in Figure UML 1.5 UML 1.4.2 Resolved closed
UML14-145 Figure 63 missing notation UML 1.5 UML 1.4.2 Resolved closed
UML14-144 Interface Figure 62 uses wrong notation UML 1.5 UML 1.4.2 Resolved closed
UML14-143 Obsolete notation used in state machine - transition examples UML 1.5 UML 1.4.2 Resolved closed
UML14-142 Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01 UML 1.5 UML 1.4.2 Resolved closed
UML14-141 An error in Figure 464 UML 1.5 UML 1.4.2 Resolved closed
UML14-140 PackageableElement UML 1.5 UML 1.4.2 Resolved closed
UML14-139 Question on Connectors - fig 2-17 UML 1.5 UML 1.4.2 Resolved closed
UML14-138 There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState UML 1.5 UML 1.4.2 Resolved closed
UML14-137 Well-Formedness Rules for Procedure on Common Behavior Package UML 1.5 UML 1.4.2 Resolved closed
UML14-136 Description of GeneralizationSet UML 1.5 UML 1.4.2 Resolved closed
UML14-135 The description of DataType is plainly wrong in the specification UML 1.5 UML 1.4.2 Resolved closed
UML14-134 notation for shared aggregation UML 1.5 UML 1.4.2 Resolved closed
UML14-133 UML's use of the word "unique" for multiplicity is ambiguous UML 1.5 UML 1.4.2 Resolved closed
UML14-132 UML 2.0 Superstructure: Operation vs. Attribute notation UML 1.5 UML 1.4.2 Resolved closed
UML14-131 representation of arrays of values in an action language UML 1.5 UML 1.4.2 Resolved closed
UML2-1 super AND infra / Section 11.8.3 of Infra, 7.13.2 of Super / PackageMerge UML 1.5 UML 2.0 Resolved closed

Issues Descriptions

section 8.3.2, a "Connector"

  • Key: UML2-4
  • Legacy Issue Number: 7851
  • Status: closed  
  • Source: MargullSoft ( Dr. Ulrich Margull)
  • Summary:

    In section 8.3.2, a "Connector" is defined as either a "delegate" or an "assembly" connector. The definition is based on "required port" resp. "provided port". However, these terms are not defined in the document; furthermore, they do not make sense at all. In section 9.3.11, a port is defined to have "provided" and/or "required" interfaces, which are well-defined. However, in the whole document is no definition for a "provided port" or "required port". From my understanding, such a thing does not make sense at all. A port is a point of interaction, and the terms "provided/required port" are non-sense. Please, provide a definition of "provided port" and "required port", or remove the corresponding sections. I hope I could help You with Your great work, Yours, Dr. Uli Margull PS: I came across this topic when working for the AutoSAR standard (car manufacturer and OEMs). They have the same unclear usage of "provided port" and "required port", and looking into the UML standard 2.0 did not help me to resolve this issue.

  • Reported: UML 1.5 — Wed, 13 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

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

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

Property.association

  • Key: UML2-3
  • Legacy Issue Number: 7642
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figure 12 of the 040814 rev has the association from Property to
    Association as derived:

    memberEnd /association
    Property ----------------------------------> Association

    and it wasn't derived in the FAS. The issues cited are: 6243 and 7365,
    but neither mentions the change. The derivation is not explained in the
    association entry on Property. Is this a metamodel typo?

  • Reported: UML 1.5 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

    No Data Available

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

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML2-2
  • Legacy Issue Number: 7222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In my interpretation of the current semantics description of UML
    activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
    have identified some rather unpleasant properties of the current
    traverse-to-completion semantics. The full discussion together with
    examples can be found in the attached .pdf, the short of it is:

    *) the current semantics does not prevent deadlocks (as it is
    supposed to do)

    *) it rather induces deadlocks even in simple examples (e.g. examples
    in the UML spec are wrong)

    *) it makes for a very complex evaluation and introduces unnecessary
    synchronization in the (basically asynchronous) notation of Activiy
    Diagrams.

    I therefore propose to relax the semantics of token flow by dropping
    the constraint that every Action has to accept all tokens for all its
    input pins at once. MergeNodes should als be able to buffer tokens
    until their conditions are satisfied. This is a more natural way of
    interpreting ADs.

  • Reported: UML 1.5 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

    This is a duplicate of issue 7221

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

In 2.13.3, the first sub-section about ActivityGraph is not numbered

  • Key: UML22-531
  • Legacy Issue Number: 6727
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

At the bottom of the page, the characters "antics." should be removed

  • Key: UML22-530
  • Legacy Issue Number: 6726
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    At the bottom of the page, the characters "antics." should be removed

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

missing closing parenthesis

  • Key: UML22-529
  • Legacy Issue Number: 6725
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed so.

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

The Composition section does not follow the usual conventions

  • Key: UML22-528
  • Legacy Issue Number: 6724
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The section about Procedure does not contain any well-formedness rules

  • Key: UML22-527
  • Legacy Issue Number: 6704
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

In "2.9.3.5 Instance", numbering of different well-formedness rules wrong

  • Key: UML22-526
  • Legacy Issue Number: 6703
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The numbering of the sub-sections in 2.7.2 is wrong

  • Key: UML22-525
  • Legacy Issue Number: 6702
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2.0 infra and super Constraints Diagram of the Kernel

  • Key: UML22-524
  • Legacy Issue Number: 6699
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Associations section of element JumpHandler

  • Key: UML22-523
  • Legacy Issue Number: 6697
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information.

    The line should read:

    protectedAction: Action [0..*]

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Remove one of the dots between protectedAction and availableOutput

  • Key: UML22-522
  • Legacy Issue Number: 6696
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type"

    Remove one of the dots between protectedAction and availableOutput

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Operations and derived attributes

  • Key: UML22-521
  • Legacy Issue Number: 6692
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

In the last paragraph, the period after the word "collections" on the secon

  • Key: UML22-519
  • Legacy Issue Number: 6662
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the last paragraph, the period after the word "collections" on the second line should be removed

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11

  • Key: UML22-518
  • Legacy Issue Number: 6661
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

The multiplicity of association named subaction of type Action ill formed

  • Key: UML22-517
  • Legacy Issue Number: 6660
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

multiplicity of the association named "type" of type DataType

  • Key: UML22-516
  • Legacy Issue Number: 6659
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

well-formedness rules are not numbered correctly

  • Key: UML22-515
  • Legacy Issue Number: 6641
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

number of the figure is wrong

  • Key: UML22-514
  • Legacy Issue Number: 6640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

remove paragraph

  • Key: UML22-513
  • Legacy Issue Number: 6639
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Infra/Metamodel/missing derivation indicators

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

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

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

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

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

UML 2 Super / Classes / dependencies should be unidirectional

  • Key: UML22-511
  • Legacy Issue Number: 6630
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

two classes "NamedElement

  • Key: UML22-510
  • Legacy Issue Number: 6525
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Secondly, there are two classes "NamedElement" holding un-redefined
    attribute "name", one is in the
    package "InfrastructureLibrary.Core.Basic", and the other is in the
    package "InfrastructureLibrary.Core.Abstractions.Namespaces". The
    problem is that there are a lot of classes directly or indirectly
    inheriting both of them e.g. class "InstanceSpecification" in package
    uml.classes.kernel, and it causes problem of duplicated parameters in
    class creation in the generated JMI interfaces. e.g.
    "
    public InstanceSpecification createInstanceSpecification
    (java.lang.String name,
    infrastructurelibrary.core.abstractions.visibilities.VisibilityKind
    visibility, java.lang.String name, java.util.Collection classifier);
    "
    Similiar cases happen to attribute "type", "isAbstract" etc.

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

    No Data Available

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

class "InfrastructureLibrary.core.constructs.Association",

  • Key: UML22-509
  • Legacy Issue Number: 6524
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    found something strange in the specification of UML 2.0.
    First of all, in the
    class "InfrastructureLibrary.core.constructs.Association", there is
    an attribute "ownedEnd" with return type
    of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it
    its direct subclass "infrastructurelibrary.profiles.Extension", there
    is an attribute "ownedEnd" which redefines ownedEnd in
    class "Association", but with return
    type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity
    of 1. It causes conflicts of generated JMI interface.

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

    No Data Available

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

Why not using the UML1 activity symbol for UML2 actions?

  • Key: UML22-508
  • Legacy Issue Number: 6503
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I didn't recognize it before, but now I am surprised that the action
    symbol
    is not the same as the UML1 activity symbol ("shape with straight top
    and bottom
    and with convex arcs on the two sides").
    Actions are no activities, but the semantic is similar for
    the "normal" UML user.
    In UML1 the user has to distinguish between the activity symbol and
    the state symbol ("round-cornered rectangle"), especially if states
    and activities
    are shown within the same diagram.
    Now you has to use the UML1 state symbol for actions. I think that
    this is confusing
    for the normal UML user.
    Another point is that the action symbol is the same as the state
    symbol. There will
    be no chance for a misunderstanding, because both symbols are not
    allowed within the same
    diagram. But it would be much clearer if the action symbol has a
    different notation and
    looks like the UML1 activity symbol.

    So, why not using the UML1 activity symbol for UML2 actions?

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

    No Data Available

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

Multiplicity seems to be broken - UML2 Infra & Super

  • Key: UML22-507
  • Legacy Issue Number: 6502
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Infastructure document defines it at page 54 as (line
    numbers have been added by me):
    (1) multiplicity ::= multiplicity_range
    (2) multiplicity_range ::= [lower '..'] upper
    (3) lower ::= integer
    (4) upper ::= unlimited_natural | '*'

    But at page 56 (also page 20 of the Superstructure document which
    copies
    the definition) it says:

    (5) multiplicity ::= multiplicty_range [

    {order_designator}

    ]
    (6) multiplicity_range ::= [lower '..'] upper
    (7) lower ::= integer | value_specification
    (8) upper ::= unlimited_natural | '*' | value_specification
    (9) order_designator ::= ordered | unordered
    (10) uniqueness_designator ::= unique | nonunique

    There are several problems arising from this definition:

    (P1) (9) and (10) are never used
    (P2) Defining the lower bound as "integer" (according to page 142 of
    the
    Infrastructure document) allows it to specify multiplicities with
    lower bounds below 0 (e.g. [-5..7], [-42..0])
    (P3) (4) and (8) include the asterisk symbol to denote an
    infinite
    upper bound. Though, this is redundant since the symbol is already
    there
    as part of the lexical representation of unlimited_natural (according
    to
    page 144 of the Infrastructure document)
    (P3) (4) and (8) define the upper bound using the datatype
    "unlimited_natural" which comprimises all integer numbers starting
    from
    zero. Thus multiplicities like [0..0] would be legal.
    (P4) It should be mentioned that the lower part is lower or equal to
    the
    value given for the upper part (where '*' is geater than any other
    element of the set named integer). Otherwise multiplicities like
    [8..2]
    would be considered legal.
    (P5) What is the role of the value_specification mentioned at (8) and
    (9) isn't it redundant there?

    Or am I just misreading the spec?

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

    No Data Available

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

Rose Model of UML 2.0 spec

  • Key: UML22-506
  • Legacy Issue Number: 6501
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Class Diagram:Constructs/Packages in the Rose file shows the
    nestedPackage/package association the spec shows
    nestedPackage/nestingpackage

    I believe the spec to be in error...

    I am not sure where to report this and or who keeps this model up to
    date. Any recommendations would be appreciated

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

    No Data Available

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

ptc-03-09-15/Relationships among Core packages

  • Key: UML22-505
  • Legacy Issue Number: 6496
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The superficial impression that Core::Abstractions is the lowest
    layer in the U2P Core does not stand up under close examination.
    Core::Basic is closer to being the fundamental layer because it uses none of
    the new association modeling constructs (such as derived unions and subsets)
    to define itself; but is not entirely so because it imports two packages
    from Abstractions.

    Recommendation: It would be worth considering whether the two packages that
    Basic imports from Abstractions can be placed in Basic, so that Basic is
    unambiguously the lowest layer in Core. This would also make EMOF
    unambiguously the lowest-—i.e. the most fundamental—-layer of MOF, since
    EMOF is based on Core::Basic while CMOF is based on Core::Constructs.

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

    No Data Available

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

ptc-03-09-15/Constructs::Class superClass property

  • Key: UML22-504
  • Legacy Issue Number: 6493
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Constructs::Class has a superClass property that redefines general,
    which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
    Constructs::Class also inherits from Basic::Class, which has superClass as a
    property (section 10.2, 66, p. 97). What does this mean? Is this a bug?
    Is it something correct having to do with package merge?

    Recommendation: Determine whether this is intended or an oversight. If it
    is an oversight, correct it. If not, explain the meaning of having these
    both of these properties.

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

    No Data Available

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

ptc-03-09-15/Non-navigable ends with no role names nor multiplicities

  • Key: UML22-503
  • Legacy Issue Number: 6492
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: It appears that associations with neither end names nor
    multiplicities on non-navigable ends are used in parts of the UML Core that
    are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for
    example. I understand that for elements defined via EMOF, this signifies a
    simple property. But is it appropriate for elements defined with CMOF.

    Recommendation: Either correct this by adding multiplicities and end names
    or explain in the specification why it is alright to omit them in these
    cases

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

    The meaning of this convention should be explained in the document.

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

UML 2 Issue: Message notation

  • Key: UML22-502
  • Legacy Issue Number: 6463
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    According to Superstructure, p. 430, the notation for messages in
    interaction diagrams is as follows (we put assumptions between parenthesis):

    asynchronous message - (solid line) open arrowhead
    synchronous message - (solid line) filled arrowhead
    reply message - dashed line (filled or open arrowhead?)
    object creation - dashed line open arrowhead

    However, the example given in Figure 333, p. 414, shows a different
    notation:

    asynchronous message - solid line open arrowhead (not shown in this diagram,
    but in others)
    synchronous message - solid line filled arrowhead
    reply message - dashed line OPEN arrowhead
    object creation - SOLID line open arrowhead

    Another confusing aspect of the notation is that in a reply message, which
    is not a true message, the message name is the name of the operation invoked
    on the callee (same as in the corresponding synchronous call), but it
    suggests instead that there is an operation with this name in the caller. In
    Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
    operation named foo in class C1, which is wrong: foo is defined in C2, not
    in C1. It would make more sense to label a reply message with the name of
    the value returned.

    PROPOSED SOLUTION
    The simplest solution would be to fix Figure 333 using a dashed arrow to
    represent object creation, although this would yield the same notation for
    object creation and reply message. Therefore, beyond this simplest solution,
    we propose something more advanced: First, state explicitly the notation for
    all kinds of messages, leaving no place for assumptions. Second, use a
    filled arrowhead for reply messages, since this emphasizes the conceptual
    proximity to the synchronous message it is a reply from. Third, use the
    notation for object creation also for object deletion, which currently is
    not mentioned. That is:

    asynchronous message - SOLID LINE open arrowhead
    synchronous message - SOLID LINE filled arrowhead
    reply message - dashed line FILLED ARROWHEAD
    object creation OR DELETION - dashed line open arrowhead

    Or better, simply drop object creation as an special kind of message. Object
    creation (and deletion) was not considered a special kind of message in UML
    1, and it is not at all clear why it should be in UML 2. Probably, an object
    creation is either synchronous or asynchronous, but not "something else" in
    the same meta-specialization row. In fact, the constraints and semantics of
    Message (Superstructure, p. 429) do not consider object creation as
    messages: "The signature must either refer an Operation (...) or a Signal",
    "A Message reflects either an Operation call (...) or a sending and
    reception of a Signal". Neither does the meta-attribute Message.messageSort,
    which has the following permitted values: synchCall, synchSignal,
    asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
    mean? The "sorts" of message are not defined in the Spec. Although calls are
    considered in other places to be either synchronous or asynchronous, signals
    are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
    and 395), therefore at least synchSignal is banned.

    Finally, we also propose to label reply messages with the name of the value
    returned by the operation call, not the operation name itself. In Figure
    333, this would leave the replies foo() and doit() without label, and the
    last reply would be labeled simply as "x".

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

    see above

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

UML 2 Issue: definition of navigability

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

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

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

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

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

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

Use 'represent' for the relationship of a model

  • Key: UML22-500
  • Legacy Issue Number: 6456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.

    At the same time, a lifeline represents a connectable element. [14.2]

    This is an example of a recurrent problem in the specification: model elements that represent other model elements.

    At the same time, "attributes of a class are represented by instances of Propert[ies]..."

    This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.

    The theory of representation needs to be settled. That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.

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

    No Data Available

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

UML 2 Super / Dependency / ownership of dependencies

  • Key: UML22-499
  • Legacy Issue Number: 6451
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted – it makes no sense to have a dependency independently of the depending (source) element.

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

    No Data Available

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

Clarification of Information Flow semantics

  • Key: UML22-498
  • Legacy Issue Number: 6446
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: Consider the following recommendations to improve Information
    Flow semantics:
    b) Allow Information Flow to be specialized and decomposed using
    aggregation.
    c) Allow Information Flow between classifiers with ports and interfaces.
    Make provisions for relating the information flow to a port, such that an
    Information Flow can flow through a port.
    d) Allow Information Flows between classifiers with object flows across
    activity partitions.
    e) Change the name from Information Flow to Item Flow (or something similar)
    to allow for the flow of non-information, such as physical items specified
    in systems engineering applications.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

Activity diagram problems

  • Key: UML22-497
  • Legacy Issue Number: 6444
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The following are some recommendations to improve Activity
    diagrams for systems engineering applications:
    a) Generalize pins so that they can be applied to control as well as data.
    b) Clarify how activity diagrams can be used to represent continuous
    behavior (e.g., streaming input).
    c) Clarify how an object node to represent a role.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Section 9.3.4 page 161, Presentation Option

  • Key: UML22-496
  • Legacy Issue Number: 6423
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
    the keyword «represents»." and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Super / Kernel features / cannot exclude superclass properties

  • Key: UML22-495
  • Legacy Issue Number: 6398
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

Syntax of names

  • Key: UML22-494
  • Legacy Issue Number: 6389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue: The UML infrastructure specification does not specify the syntax for names. This prevents model interchange.

    Proposal: Specify the syntax for the string in Name. At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.

    Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.

    [After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job. Or, in any event, get us started.]

  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

raisedException

  • Key: UML22-493
  • Legacy Issue Number: 6275
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well.

    I believe this violates a well-formedness rule that all structural features must be distinguishable.

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8461 for disposition

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

UML 2 Super / Templates / TemplateParameter not named

  • Key: UML22-492
  • Legacy Issue Number: 6262
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template.

  • Reported: UML 1.5 — Tue, 23 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super/pg.75/kinds of changeability

  • Key: UML22-491
  • Legacy Issue Number: 6216
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    pg. 75: StructuralFeature::isReadOnly
    Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values:

    Changeable (unrestricted)

    readOnly (no changes after initialization)

    [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.]

    The following additional choices were available in UML1:

    CreateOnly (add a set any time after initialization but no further changes)

    addOnly (may add members to the set but not change or remove any)

    Both of these occur in practice often enough.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

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

UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"

  • Key: UML22-490
  • Legacy Issue Number: 6201
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
    opposite =
    if owningAssociation->empty() and association.memberEnd->size() = 2 then
    let otherEnd = (association.memberEnd - self)->any() in
    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
    else Set {}
    endif

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8451 for disposition

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

UML 2 Super/Metamodel::Kernel/missing merges

  • Key: UML22-489
  • Legacy Issue Number: 6197
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super/Package merge/redefinitions issue - lost association ends

  • Key: UML22-488
  • Legacy Issue Number: 6194
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine

    {redefines ownedBehavior}

    <--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super/Metamodel::Super/missing merge

  • Key: UML22-487
  • Legacy Issue Number: 6187
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

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

UML 2 Super/Metamodel::Constructs/owningComment

  • Key: UML22-486
  • Legacy Issue Number: 6176
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Constructs association owningCommet:Element[0..1] c-> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c-> ownedCommet:Comment[0..*] as defined in Kernel/Root.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see below

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

relationship should just be a cross-reference

  • Key: UML22-481
  • Legacy Issue Number: 6002
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical.

    It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?

  • Reported: UML 1.5 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

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

formal/03-03-01 : Omission of definition of Class "Action"

  • Key: UML22-480
  • Legacy Issue Number: 5907
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I believe I found an omission from the UML 1.5 Specification formal/03-03-01:

    p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"

    In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".

    p. Index-1 cites "Action" p 2-103.

    p. 2-103 has no mention of "Action".

    The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.

    My question is what is definition of the "Action" Class in Fig. 2-18?

  • Reported: UML 1.5 — Mon, 21 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

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

logic upperbound is the same as the lower bound.

  • Key: UML22-479
  • Legacy Issue Number: 5896
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) =============================================

    according to the logic upperbound is the same as the lower bound.

    should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?

  • Reported: UML 1.5 — Fri, 4 Apr 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

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

AssociationClass

  • Key: UML22-45
  • Legacy Issue Number: 7400
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing.

  • Reported: UML 1.5 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The text in 11.5.3 clearly states that the ownedEnds of an AssociationClass are not
    attributes.
    Disposition: Closed - No Change

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

completion transitions

  • Key: UML22-41
  • Legacy Issue Number: 7254
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors.

  • Reported: UML 1.5 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add a clarification for this case based on the above discussion

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

show object flow or interactions

  • Key: UML22-35
  • Legacy Issue Number: 7166
  • Status: closed  
  • Source: Boeing ( David Hickerson)
  • Summary:

    There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

  • Reported: UML 1.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been discussed in previous F/RTFs and considered out of scope:
    FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address.
    RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them.
    Revised Text:
    None
    Disposition: Closed Out of Scope

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

UML 2 Super/Interactions/Need constraints that cover multiple Lifelines

  • Key: UML22-34
  • Legacy Issue Number: 7161
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
    None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.

    Or when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.

    In order to achieve this, it would be desirable to use:
    1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
    2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
    3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

  • Reported: UML 1.5 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects".
    Disposition: Closed Out Of Scope

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

Part subtype

  • Key: UML22-29
  • Legacy Issue Number: 6866
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Would be useful to be able to assign a subtype for objects that fill a
    part, to add additional characteristics. For example, a person fills
    the Employee part of a company, and is reclassified under a subtype of
    person that has an office. It is not sufficient to use the subtype as
    the type of the part, because the model wouldn't record what objects are
    allowed to fill the parts. The object is reclassified under the subtype
    after filling the part.

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

    The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF.

    Revised Text:
    None.

    Disposition: Closed, out of scope

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

UML 2.0 Kernel Operations Diagram and Features Diagram and mdl

  • Key: UML22-28
  • Legacy Issue Number: 6700
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The operations diagram redefines the formalParameter Property and removes the

    {ordered subsets parameter subsets ownedMember}

    .

    The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn’t defined in the spec.

    I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

    This would require the ownerformalParam be made navigable. But I feel that this change is already required to sync the OCL and Superstructure specs.

    An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No longer applicable closed no chnage

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

UML2 Super/Kernel Classes

  • Key: UML22-27
  • Legacy Issue Number: 6681
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    section 7.11 Does Property.aggregation have meaning for properties typed by
    value types, (Data Type and subtypes)?

  • Reported: UML 1.5 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The spec now says under the semantics of Property “The semantics of composite aggregation when the
    container or part is typed by a DataType are intentionally not specified.”
    Disposition: Closed - No Change

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

UML Superstructure FTF : isRoot property disappeared

  • Key: UML22-26
  • Legacy Issue Number: 6616
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.

    On page 399 FAS: section 13.3.4

    The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

    On page 86 FAS section 7.8.3 RedefinableElement:

    isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is
    true, then it is not possible to further specialize the RedefinableElement. Default value is
    false.

    But no mention of isRoot....

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

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

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

Federated models - UML2 issue

  • Key: UML22-25
  • Legacy Issue Number: 6500
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When creating a complete environment for agreements and BCF we need
    to
    work with ModelElements, classes, package, models etc created and
    managed by many unrelated person and organisations. This means that
    we
    need to support loosely coupled models (federated models) where an
    association starts in one model (stored in doc A) and ends in another
    model (stored in document B).

    This may mean that we need to add references to an external
    modelelement
    so the assoication that references "out" to external ME need to be
    annotated with for example UUID of remote modelelement, name of model
    where the remote/external model , physicial location of remote model
    (URL) etc.
    We may also want to attach constraints to the remote modelement that
    restricts "incomming" associations.

    The question is how are loosely coupled model handled in UML 2 ?

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

    closed no change

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

ptc-03-09-15/Separate classification and generalization in Core::Basic

  • Key: UML22-24
  • Legacy Issue Number: 6495
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: One of the main requirements for a core that can be reused by CWM
    hinges on whether it is possible to reuse the abstract syntax that supports
    classification and supports having properties (or features), without pulling
    in generalization constructs. U2P’s Core::Basic package, upon which EMOF is
    based, does not appear to adequately separate these concerns.

    The most abstract level of Core::Basic's inheritance hierarchy at which the
    ability to have properties appears is in the Class metaclass. But Class
    also carries the “baggage” of a definition of superclass.

    The Core::Abstractions package does appear to adequately separate these
    concerns. It does so by defining a simple Classifier in the
    Core::Abstractions::Classifiers package that supports features but not
    generalization. The Core::Abstractions::Super package defines another
    Classifier metaclass that subclasses
    Core::Abstractions::Classifiers::Classifier and adds support for
    generalization.

    Presumably, then, the intent is that CWM metamodels that support
    classification and properties but not generalization can reuse
    Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not
    reuse either of these basic definitions of Classifier from
    Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM
    metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
    share a common definition of Classifier with EMOF. That could mean that a
    metamodel expressed solely via EMOF will not be able to be the source or
    target in a unified approach to transformations. This is not a problem for
    CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
    are based on Core::Abstractions.

    Recommendation: Solving the problem for EMOF would require some refactoring
    of Core::Basic to separate concerns between classification and
    generalization.

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

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

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

Ports in Protocol State Machines

  • Key: UML22-23
  • Legacy Issue Number: 6489
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Protocol machines should not have ports in them. It should be an
    extension in the ports package. Otherwise there is a backwards
    dependency onto composite structure.

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

    Discussion
    Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency.
    Furthermore, creating a dependency from composite structures to statemachines would create a more serious
    layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done
    by an RTF at this point.
    UML 2.5 has a different modular structure than UML 2.4 and earlier versions, with a single-level “flat”
    structure in which inter-module dependency concerns, which are at the core of this issue, are no longer
    relevant.
    Disposition: Closed - No Change

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

UML 2 Issue: Qualified pathnames

  • Key: UML22-22
  • Legacy Issue Number: 6466
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for qualified names is double-colon ('::'). However, the Spec
    always and everywhere uses a different notation: instead of
    "Kernel::Comment", "Comment (from Kernel)".

    PROPOSED SOLUTION
    Use the standard notation for qualified names.

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

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

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

UML 2 Issue: isUnique

  • Key: UML22-21
  • Legacy Issue Number: 6464
  • Status: closed  
  • Source: Simula Research Laboratory ( 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: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: AssociationEnd

  • Key: UML22-20
  • Legacy Issue Number: 6462
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    In UML 1 the navigability of an association end was specified by the
    meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
    meta-attribute dissapears, and AssociationEnd is substituted by Property. We
    know whether an association end is navigable by the following rule: if the
    property is owned by a class, it represents a navigable end; if the property
    is owned by an association, it represents a non-navigable end (see
    Superstructure, p. 89). However, references to old metaclass AssociationEnd
    and old meta-attribute isNavigable still appear in the Spec in several
    places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
    33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
    245).

    PROPOSED SOLUTION
    Add derived meta-attribute /isNavigable to metaclass Property.
    Eliminate references to AssociationEnd.

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

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

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

instantiations of Classifiers

  • Key: UML22-19
  • Legacy Issue Number: 6455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    7 and 14: "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] There are no objects in a UML 2 model, but only models of objects, that is, instance specifications. The instantiation of a UML class is not in the model, but in the modeled system. At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution: Abandon the idea that there are no objects in a model. Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model. Likewise for an association and its links, and so on.

    This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.

    It is consistent with the existence of power types in the language.

    It is consistent with the MOF specification of meta-layers.

    It removes the conflation of the type conformance and instatiation relationships with the representation relationship. It reduces the meanings conflated into 'instance of' by one.

    Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

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

    Discussion
    The change proposed in the issue is fundamentally different than the basic interpretation of models in UML.
    Further, the assertion that UML “places instantiations of Behaviors in the UML model (not in the modeled
    system)” is not correct. An instance of a Behavior is an execution (in the modeled system), while an
    ExecutionOccurrence is a model of such an instance. This is quite similar to the difference between an
    instance and an InstanceSpecification. The UML 2.5 specification is now clearer on this.
    Disposition: Closed - No Change

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

UML 2 Super / Missing OCL constraints

  • Key: UML22-18
  • Legacy Issue Number: 6452
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

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

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

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

03-04-01 Chap 2 p. 112/Components: Different ways to wire components

  • Key: UML22-17
  • Legacy Issue Number: 6433
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
    paragraph says: “A component has a number of provided and required
    Interfaces, that form the basis for wiring components together, either using
    Dependencies, or by using Connectors.” Is this really an either or choice?
    What is the real semantic distinction? And what is the semantic distinction
    between wiring via connectors without ports vs. wiring via connectors with
    ports?

    Recommendation: Clearly specify the semantic distinctions among the three
    ways of wiring components together:

    1) Via Dependencies
    2) Via Connectors without Ports
    3) Via Connectors with Ports.

    If there are no semantic distinctions--that is, if the distinctions are
    purely mechanical--then the specification should probably changed such that
    there is one way to wire components together.

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

    Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired.
    We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.

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

UML2 super/ad-03-04-01/Derived attributes and associations

  • Key: UML22-16
  • Legacy Issue Number: 6430
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: There are many places where the specification indicates that an
    attribute or association is derived, but does not state how it is derived;
    that is, the specification does not state, in English or in OCL, how to
    compute the derivation.

    Recommendation: Specify, in English and OCL, how to compute the derivations
    of all derived attributes and associations.

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

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

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

Section 9.3.3

  • Key: UML22-15
  • Legacy Issue Number: 6422
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration. I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section. In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

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

    Original discussion:
    The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4.
    New comments (March 2009):
    This issue dates back to 2003. I propose we close it on the grounds of cost/benefit.

    Revised Text:
    None.

    Disposition: Closed, no change.

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

UML 2 Super/Interactions/missing OCL constraints

  • Key: UML22-14
  • Legacy Issue Number: 6409
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Not all the constraints in the Interactions section (14.3). They should be added

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

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

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

UML 2 super / Dependencies / improper subsetting?

  • Key: UML22-13
  • Legacy Issue Number: 6405
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty...

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

    No Data Available

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

Notes versus curly braces

  • Key: UML22-12
  • Legacy Issue Number: 6372
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Why do decision input behaviors use the note notation and join
    specification use curly braces?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and").
    Revised Text:
    None
    Disposition: Closed, no Change

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

Activity OCL

  • Key: UML22-11
  • Legacy Issue Number: 6346
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Not all the constraints in the Activities section have corresponding OCL
    specifications. These should be added

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints related to Activities that can be given OCL now have OCL in UML
    2.5.
    Disposition: Closed - No Change

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

UML 2 Super/Metamodel/redefinition and substitutability

  • Key: UML22-10
  • Legacy Issue Number: 6200
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The specific issue with state machines no longer applies, having been resolved in an earlier RTF. The general
    issue about redefinition is a complaint about a fundamental characteristic of UML semantics which are by
    now quite well understood. Changing these semantics would be very fundamental and disruptive.
    This also resolves issue 14929.
    Disposition: Closed - No Change

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

Target pin notation

  • Key: UML22-9
  • Legacy Issue Number: 6126
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    On CallOperationAction, etc, how do you tell graphically which pin is
    the target?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

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

State extension

  • Key: UML22-8
  • Legacy Issue Number: 6114
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    State should be an extension of type rather than object node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

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

Reentrancy 1

  • Key: UML22-7
  • Legacy Issue Number: 6111
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    How is the effect if isReentrant achieved for actions other than call
    actions? isReentrant is only on behaviors. Perhaps it should also be
    available on actions and operations

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default.
    In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.

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

Suspension Region

  • Key: UML22-6
  • Legacy Issue Number: 6082
  • Status: closed  
  • Source: Ostfold University College ( Oystein Haugen)
  • Summary:

    “Supspension region” is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call.

    This has been flagged as a potential FTF issue before.

  • Reported: UML 1.5 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision.
    Disposition: ClosedOutOfScope

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

saying {nonunique} on one end of a binary association is meaningless

  • Key: UML22-5
  • Legacy Issue Number: 5977
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is
    meaningless by the current rules, because the other end remains

    {unique}

    by
    default, so no duplicate links would be allowed

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is meaningless by the current rules, because the other
    end remains

    {unique}

    by default, so no duplicate links would be allowed
    Disposition: Merged with 6464

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

behaviour of the shallow history state and deep history state

  • Key: UML22-4
  • Legacy Issue Number: 5886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state.

    Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

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

    Disposition: Deferred to UML 2.4 RTF

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

Feature;ModelElement

  • Key: UML14-557
  • Legacy Issue Number: 5922
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    Why there are two different Backbone Diagrams in the UML 1.5 Specification. The one on Page 71 shows that a Feature has a visibility and a ModelElement has just a name, nothing more. On Page 596 an Feature has the visibility not anymore, but ModelElement has one, how this should be interpreted, which one is the right visibility

  • Reported: UML 1.5 — Tue, 29 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 2 Super / use cases / invalid subsetting

  • Key: UML14-469
  • Legacy Issue Number: 6874
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    UseCase::extensionPoint subsets Classifier::feature, but ExtensionPoint is not a specialization of Feature.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / state machines / non-existent return type

  • Key: UML14-468
  • Legacy Issue Number: 6873
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The LCA operation, defined in section 15.3.12 (page 194) has a non-existent return type, CompositeState

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / state machines / misplaced operation definition

  • Key: UML14-467
  • Legacy Issue Number: 6872
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The containingStateMachine() operation is defined in the "Additional Operations" for StateMachine (see section 15.3.12, page 491) rather than in the corrsponding section(s) for the type(s) to which it applies.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / state machines / incorrect property redefinition

  • Key: UML14-466
  • Legacy Issue Number: 6871
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Constraints 9 and 10 in section 15.3.8 (page 470) refer to the owner property, but the owner property is redefined by Vertex::container, as shown in Figure 354 on page 457. Vertex::container should probably subset owner instead

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of issue 6626 and is resolved by the same resolution.

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

UML 2 Super / state machines / non-existent property reference

  • Key: UML14-465
  • Legacy Issue Number: 6870
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Constraints 4 and 6 in section 15.3.8 (page 470) refer to the non-existent stateMachine property on PseudoState (i.e. self.stateMachine).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / state machines / oclIsKindOf arguments error

  • Key: UML14-464
  • Legacy Issue Number: 6869
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The syntax of the oclIsKindOf() is not correct in all occurrences. For example, constraints 4 and 6 in section 15.3.8 (page 470) use the syntax oclIsKindOf(self.stateMachine, ActivityGraph) whereas constraints 9 and 10 use the syntax owner.oclIsKindOf(Region).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/State machines/pseudostate name consistency

  • Key: UML14-463
  • Legacy Issue Number: 6868
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The specification refers to a PseudoState type (page 469), but in the Rose model, it is named "Pseudostate".

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Ambuiguity in value pin evaluation

  • Key: UML14-462
  • Legacy Issue Number: 6865
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    When the value specification of a ValuePin is an expression, when is the
    expression evaluated?

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

page 136, "BasicComponents",

  • Key: UML14-461
  • Legacy Issue Number: 6728
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    Superstructure, final adopted spec 03-08-02, page 136, "BasicComponents",
    contains this inscrutable phrase in the first paragraph:

    In addition, because a itself Class is a subtype of an
    EncapsulatedClassifier,...

    This should be fixed up in the final version, if you can
    figure out what you meant to say

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Consistent Naming

  • Key: UML14-460
  • Legacy Issue Number: 6691
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Associations with and end on the class Value Specification that subset owner have inconsistent names:

    ownerUpper

    ownerLower

    owningConstraint

    owningInstanceSpec

    owningParameter

    owningProperty

    owningSlot

    I would recommend renaming ownerUpper and ownerLower to owningUpper and owningLower to be consistent.

    All other properties that subset owner on other classes should be renamed consistently:

  • Reported: UML 1.5 — Thu, 11 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super/Signal

  • Key: UML14-459
  • Legacy Issue Number: 6690
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    13.3.21 suggests that Signal has no additional associations, and yet in
    Figure 316 it has ownedAttribute.

    I also note that in the mdl file Signal inherits from BehaviouredClassifier
    but I can't see that on Figure 316

    If it is a BehaviouredClassifier it seems odd that it has no concrete
    BehaviouralFeatures.

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Activities / subsetting two properties

  • Key: UML14-458
  • Legacy Issue Number: 6680
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Activity::structuredNode subsets two properties, Activity::node and Actvity::group. This is among the few, if not the only, cases in the metamodel where a containment property subsets two superset containment properties. What is the semantic intent of this constraint? Should Activity::structuredNode be derived from the set of structured activity nodes in Activity::node and Actvity::group (StructuredActivityNode is both a group and a node)?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Activities / association end naming

  • Key: UML14-457
  • Legacy Issue Number: 6679
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    ActivityNode::interruptibleRegion should probably be renamed to ActivityNode::inInterruptibleRegion so as to be consistent with ActivityNode::inGroup, ActivityNode::inPartition, and ActivityNode::inStructuredNode.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See changes for 6678.

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

UML 2 Super / Activities / inconsistency in representing subsetting

  • Key: UML14-456
  • Legacy Issue Number: 6678
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Instead of subsetting ActivityEdge::inGroup with an ActivityEdge::interruptibleRegion property (as is done with ActivityNode), a completely new association (ActivityEdge::interruptibleRegion<->InterruptibleActivityRegion::interruptingEdge) is introduced. Why the inconsistency?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Activities/invalid multiplicity 0

  • Key: UML14-455
  • Legacy Issue Number: 6677
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    InterruptibleActivityRegion::edgeContents redefines the multiplicity of ActivityGroup::edgeContents to be 0, which violates the constraint that an upper bound must be greater than 0

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Activities/assocition end specialization consistency

  • Key: UML14-454
  • Legacy Issue Number: 6676
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents are redefined by subclasses ActivityPartition (Figure 183), InterruptibleActivityRegion (Figure 191), and StructuredActivityNode (Figure 192), but the opposites of these properties are subsetted instead. Would make more sense to apply either redefinition or subset constraints to both ends of the associations rather than a mixture of both?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Activities/end naming consistency

  • Key: UML14-453
  • Legacy Issue Number: 6675
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents should probably be renamed to ActivityGroup::edgeContent and ActivityGroup::nodeContent so as so be consistent with the rest of the specification.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

subsettedProperty->forAll(sp | isDerivedUnion) ?

  • Key: UML14-452
  • Legacy Issue Number: 6674
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    As used in UML 2 Infra and Super is it intended that all properties that are subset by some other properties be derived unions?

    So that the following constraint would be true for the Class Property…

    subsettedProperty->forAll(sp | isDerivedUnion) ?

    I understand this may not be a requirement but am just trying to understand if this is how it is used in the Spec.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

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

UML2 Super/Connector End

  • Key: UML14-451
  • Legacy Issue Number: 6670
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    p 165, partWithPort: Property [ 0..1 ] Indicates the role of the internal
    structure of a classifier with the port to which the connector
    end is attached.

    Is there any significance to the fact that the term role is used, or is part
    meant here? There seems to be no constraint that makes it explicit that
    partWithPort must associate to a part (i.e. a property with
    isComposite=true.)

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/Ports

  • Key: UML14-450
  • Legacy Issue Number: 6669
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    page 168 - isBehavior: Boolean Specifies whether requests arriving at this
    port are sent to the classifier behavior of this
    classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383).
    Such ports are
    referred to as behavior port. Any invocation of a behavioral feature
    targeted at a behavior
    port will be handled by the instance of the owning classifier itself, rather
    than by any
    instances that this classifier may contain. The default value is false.

    This needs to be backed up by a constraint that ensures that no
    ownedConnectors may connect to such a Port.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/Connector

  • Key: UML14-449
  • Legacy Issue Number: 6668
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    If as has been suggested structured classes completely encapsulate their
    parts, then I would expect to see a constraint against Connector, which
    states that the parts associated to its ends via "role" or "partWithPort"
    should be owned by the same StructuredClassifier as owns the Connector.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Page 164 - there are two constraints sections for Connector

  • Key: UML14-448
  • Legacy Issue Number: 6667
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    Page 164 - there are two constraints sections for Connector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Delete the section “Constraints” at the top of p. 164 of adtf/03-08-02.

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

UML2 Super/Structured Classes

  • Key: UML14-447
  • Legacy Issue Number: 6666
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    03-08-02.pdf

    Figure 95 - the term

    {subsets redefinit ionContext}

    appears in an odd place - I assume it belongs as a complement to
    redefinedConnector, rather than ownedConnector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/parts

  • Key: UML14-446
  • Legacy Issue Number: 6648
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    03-08-02.pdf, page 174:part: Property References the properties specifying
    instances that the classifier owns by composition.
    This association is derived, selecting those owned properties where
    isComposite is true.

    This seems to imply that /parts can only reference Properties whose types
    are Class, Interface, Templateable Class., i.e. only those subtypes of
    Classifier that denote instances. Is this correct - if so then it should be
    more explicit in the constraints (I couldn't see any other reference to this
    constraint).

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/Composite Classes

  • Key: UML14-445
  • Legacy Issue Number: 6647
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    pg 168: The provided and required interfaces completely characterize any
    interaction that may occur between a classifier and its
    environment at a port.

    If the type of a port is a class, perhaps with superclasses, then I don't
    see how the above statement can be true.

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2.0 Superstructure Derived Union vs. derivationExpression?

  • Key: UML14-444
  • Legacy Issue Number: 6646
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The use of the latter would eliminate the isDerivedUnion Property from the Class Property and would eliminate the subsets and union property strings from all the associations. Also would allow for the definition of more complex derivations other than simple unions. A Property could be overridden/redefined for each child class to update the derivation for that class.

    Most importantly the information would be stored in a more appropriate location. When attempting to determine a value for a property one simply need look at the derivationExpression and not look at all other properties to determine which properties subset this derived union. Given the number of mistakes using derived union in the UML 2.0 Spec it seems apparent that this is error prone.

    Implementation would also be easier. Most modeling tools could simply add a couple of tagged values to allow for the definition of derivationExpression. Also languages would be able to generate a standard function call to calculate the derivationExpression.

    Example:

    The Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement. In order to determine how to actually derive the value of ownedMember one has to currently iterate all the properties to determine which ones subset the derived union property and then perform the union. Also, one would have to ensure the property strings are on each subsetting member.

    Using the derivationExpression one would only need the following in one location:

    ownedType->union(nestedPackage)->union(ownedRule)

    If desired, but not required, the derivation expression could be displayed on a diagram via a comment.

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is really a continuation of issue 6644, not a separate issue.

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

UML 2 Super / use cases / incorrect comments in notation section

  • Key: UML14-442
  • Legacy Issue Number: 6643
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    UML 2.0 Superstructure ptc/03-08-02

    In table 22, in the Notation cell associated to the "Include" Note Type,
    the comments associated to the two Use Case shoud be exchanged :
    the Whidraw UC should be the including UC; the Card Identification should
    be the included UC.

  • Reported: UML 1.5 — Sat, 29 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Error in definition of PackageMergeKind

  • Key: UML14-441
  • Legacy Issue Number: 6642
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    Figure 9-11 specifies that the two values for PackageMergeKind are 'extent' and 'define'. This is probably an editorial error. I suppose the same error exists in the OMG Standard petal file(s).

    Under PackageMerge, Properties, the sentence, 'mergeType: PackageMergeKind Specifies the kind of package merge to perform, define, or extend.', has an extra comma, the last, which should be removed. This sentence might better be written with a colon in place of the first comma:

    mergeType: PackageMergeKind Specifies the kind of package merge to perform: define or extend.

  • Reported: UML 1.5 — Thu, 27 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 2.0 Superstructure 3rd revision - Owner of triggers?

  • Key: UML14-440
  • Legacy Issue Number: 6629
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Trigger specializes Element which has the constraint self.mustBeOwned() implies owner->notEmpty()

    And defines mustBeOwned = true

    Trigger and all of its specializations

    1. never define any relationship that

    {subsets owner}

    2. Do not override mustBeOwned

    Therefore Trigger and all specializations will violate the constraint.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6206

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

UML 2 Super/Action/featuringClassifier misinterpreted

  • Key: UML14-439
  • Legacy Issue Number: 6628
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature!

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Actions/non-existent feature "multiplicity"

  • Key: UML14-438
  • Legacy Issue Number: 6627
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The third constraint on StructuralFeatureAction (page 258) uses the very non-existent feature "multiplicity" of the InputPin metaclass. Not only that, but because this "multiplicity" feature doesn't exist, who is to tell what kind of element it is that defines the "is(lower, upper)" operation! Recall that the InputPin is a specialization of ObjectNode, which is not a MultiplicityElement, but defines a single attribute "upper : ValueSpecification." Where is the corresponding "lower"?

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This duplicates 6090.

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

section 9 (State Machines) of 3rd revision

  • Key: UML14-437
  • Legacy Issue Number: 6626
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    In section 9 (State Machines) of 3rd revision

    Page 454 - The Description of the class “Transition” associations fails to list the association “container” depicted on the drawing on page 415.
    Drawing on page 415 displays

    {redefines owner}

    for both container of Vertex and for Transition. I believe these should be

    {subsets owner}

    (also in mdl file)

  • Reported: UML 1.5 — Sun, 23 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Actions/PrimitiveFunction missing properties

  • Key: UML14-436
  • Legacy Issue Number: 6625
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PrimitiveFunction is missing formalParameter and returnedResult properties, as referenced by ApplyFunctionAction on page 222. Should it be a specialization of Behavior?

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

    See resolution of 7405.

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

Notation when guards are used in conjunction with triggers in transitions

  • Key: UML14-435
  • Legacy Issue Number: 6608
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    According to the metamodel, a transition may have a guard and a trigger. However the specification
    does not say how to draw a transition that has both. Should we put the guard, (1) near the arrow
    which is before the "input" symbol representing the trigger signal, or (2) near the arrow which is after
    the "input" symbol or (3) inside the symbol representing the trigger?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Time trigger notation in state machines

  • Key: UML14-434
  • Legacy Issue Number: 6607
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In activity diagrams a time expiration event can be notated using a special "time consumation" icon.
    For state machines it is not clear whether the same icon can be used.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

No way to represent "uninterpreted" actions

  • Key: UML14-433
  • Legacy Issue Number: 6606
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Within a state machine we would like refer to an action defined rather "informally" using natural language.
    Among the list of actions metaclasses, we did not see any one that could be used to map our "informal"
    action.
    Suggestion for resolution: Add a UninterpretedAction metaclass in the metamodel.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Missing actual arguments in submachines states

  • Key: UML14-432
  • Legacy Issue Number: 6605
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A state machine, as a behavior, has formal parameters. When referencing it in a submachine state, we
    may need to pass actual arguments. However, nothing seems to be specified for that purpose in the
    UML2 metamodel. Is this a bug? If not, how can we send/retrieve data to/from a referenced submachine?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Incorrect usage/definition of "emergence" in Common Behavior Chapter

  • Key: UML14-431
  • Legacy Issue Number: 6527
  • Status: closed  
  • Source: Thematix Partners LLC ( James Odell)
  • Summary:

    PROBLEM STATEMENT

    In section 13.1 of the Common Behaviors chapter, the following paragraph is
    contains an incorrect definition of "emergent behavior":
    "Emergent behavior results from the interaction of one or more participant
    objects. If the participating objects are parts of a larger composite
    object, an emerging behavior can be seen as indirectly describing the
    behavior of the container object also. Nevertheless, an emergent behavior is
    simply the sum of the executing behaviors of the participant objects."

    The current area of scientific study know as Complex Adaptive Systems, or
    Complexity Science", describes emergent behavior as "the appearance of a
    coherent pattern that arises out of interactions among simpler objects, that
    is MORE than just their summed behavior." (emphasis mine) Furthermore,
    Complexity Science expressly states that a behavior that is limited to the
    sum of its behavior is NOT emergent. (See references, below.)

    Emergence is a primary area of study at the Santa Fe Institute and has Nobel
    Laureates and MacArthur geniuses studying the effect. Therefore, I think
    that the use of the terms "emergence" (used once) and "emergent behavior"
    (used 9 times) are not correct for Common Behavior chapter. If left in,
    they will cause confusion, because the terminology is already
    well-established in both science and industry.

    PROPOSED SOLUTION
    1) Common Behavior Domain Model (Fig. 306) to contain the classed called
    BehaviorEmergence. Therefore, the class should wither be removed or another
    tem substituted.
    2) Remove, or rename, all 9 usages of "emergent behavior" if the chapter and
    appendix.

    References (to name a few) :

    Holland, J.H., Emergence: From Chaos to Order. 1998, Reading, MA:
    Addison-Wesley. (MacArthur Fellowship Genius Award)

    Gell-Mann, M., The Quark and the Jaguar: Adventures in the Simple and the
    Complex. 1994, New York: W. H. Freeman. (Nobel Laureate in Physics)

    Kauffman, S., At Home in the Universe: The Search for the Laws of
    Self-Organization and Complexity. 1995, New York: Oxford University Press.
    (Professor, Santa Fe Institute)

    Coveney, P. and R. Highfield, Frontiers of Complexity: The Search for Order
    in a Chaotic World. 1995, New York: Fawcett Columbine.

    Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and
    Chaos. 1992, New York: Simon and Schuster. (PhD in elementary particle
    physics)

    The Emergence of Everything: How the World Became Complex
    by Harold J. Morowitz

    Emergence: The Connected Lives of Ants, Brains, Cities, and Software – by
    Steven Johnson

    A New Kind of Science by Steve Wolfram

  • Reported: UML 1.5 — Sun, 9 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

/pages 485,487,495/mixed names for state machine diagram

  • Key: UML14-430
  • Legacy Issue Number: 6526
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 1 terminology "StateChart" and another term "state diagram" also occurs.

    Appendix A of the Superstructure spec makes it clear that the UML 2 name is "state machine diagram"

    Recommendation: All occurrences of "statechart" and "state diagram" must be replaced with "state machine diagram"

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

    see above

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

Typos

  • Key: UML14-429
  • Legacy Issue Number: 6523
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    page 261, on the Description of complete activities:
    "Edges support controlling token flow and be contained in
    interruptible
    regions."

    page 269, second line says "It covers invocation nodes, control nodes
    (...)". I believe it should read "It covers executable nodes, control
    nodes
    (...)"

    page 282, second line:
    "A control flow is an edge starts an activity node after the previous
    one is
    finished."

    page 286, in constraints [2]:
    "The input parameter must be the same as or a supertype the type of
    object
    token coming along the incoming edge."

    page 301, in Semantics:
    "This is equivalent interposing a CentralBufferNode between the
    initial node
    and its outgoing edges."
    page 307, second line:
    "A loop node is a costructured activity node that represents a loop
    with
    setup, test, and body sections."
    page 331, Table 2 caption should be "Graphic paths (...)" instead of
    "Graphic nodes (...)". Table 3 caption should also be made more
    specific.

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

    duplicate

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

Order cancel request

  • Key: UML14-428
  • Legacy Issue Number: 6522
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    2. Assuming that, for example, "Order cancel request" that appears in
    figure
    6-86 (page 304), is an object nodes with signal as type, from where
    or how
    does it get the respective token which is then subtracted by the arc
    ending
    in Cancel order?

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

    No Data Available

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

The node "Order cancel request" that appears in figure 6-86

  • Key: UML14-427
  • Legacy Issue Number: 6521
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    I would really appreciate an answer to the following questions
    regarding the
    3rd revised submission of UML 2.0 superstructure from April 10, which
    I hope
    is the most recent one:

    1. The node "Order cancel request" that appears in figure 6-86 (page
    304),
    and the node "Ready to award bid" and "Bid arrives that appear in
    figure
    6-39 (page 265) are of the type "Object nodes for tokens with signal
    as
    type", presented in page 316?
    If they are then there is a discrepancy between the respective
    graphical
    notation in page 316 and page 331 (table 1), and pages 304 and 265.

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

    No Data Available

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

GeneralizationSet Description clarification - UML2 Superstructure

  • Key: UML14-426
  • Legacy Issue Number: 6520
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    On page 121 of 03-08-02 the GeneralizationSet description reads:
    7.17.3 GeneralizationSet (from PowerTypes)

    A GeneralizationSet is an AutonomousElement (from Foundation ::
    Kernel ::
    PackagingNamespaces) whose instances define

    partitioned sets of Generalization relationships.

    Description

    Each Generalization is a binary relationship that relates a specific
    Classifier to a more general Classifier (i.e., a subclass).

    For clarification, should the parenthetical read "(i.e., a subclass
    to a
    superclass). As written, it may convey to some that the subclass is
    the
    more general Classifier.

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

    see above

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

Activity nodes and Stereotypes - UML2 Superstructure issue

  • Key: UML14-425
  • Legacy Issue Number: 6519
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The new Profiles package and the respective Stereotypes still seem
    very
    "class-oriented" when it comes to notation (maybee my fault?).
    Specifically,
    I have the following doubt:

    If I want to define a Stereotype for an activity node, e.g. a
    ForkNode, is
    the notation in the attached file correct?

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

    No Data Available

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

does "is not instantiable" imply "isAbstract"? - UML2 Superstructure

  • Key: UML14-424
  • Legacy Issue Number: 6518
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor graphical typo: Page 487 of the superstructure document
    specifies an InformationItem as not instanciable. But the classifiers
    taxonomy provided at page E-565 of the same document depicts it as
    instanciable class.

    I guess it should be italicized.

    Or am I just misinterpreting the sentence "is not instanciable"? I
    guessed it implies "isAbstract == true".

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

    see above

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

Package Extensibility <> - UML2 Superstructure issue

  • Key: UML14-423
  • Legacy Issue Number: 6517
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When merging packages... How are associated state machines handled?

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

    see above

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

Dependency notation for interfaces - UML2 Superstructure

  • Key: UML14-422
  • Legacy Issue Number: 6516
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Comparing figure 1-63 (Superstructure document page 92) with the text
    placed above describing it and the presentation guidelines for
    interface
    relationships (i.e. the relationships connecting an interface with its
    requiring and/or providing classes) it seems that the dashed lines
    announced in the text are gone in the figure.

    Reading the text the arrow pointing from TheftAlarm to ISensor should
    be
    realized as a dependency relationship and also the arrow pointing from
    ProximitySensor to ISensor. The latter is currently realized as a
    generalization arrow which is solely a valid presentation option for
    relationships connecting a Component and their Interface. According to
    the spec the arrow should be a dependency relationship that is
    stereotyped with realizes having ProximitySensor as client and Isensor
    as supplier.

    Or am I just misreading the spec?
    Any help and clarification appreciated

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

    Resolved by the resolution to issue 6069

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

Inconsistency concerning VisibilityKind - UML2 Superstructure

  • Key: UML14-421
  • Legacy Issue Number: 6515
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor point, but still annoying to the reader ...

    The superstructure lists at page 16 all four possible types (i.e.
    "public", "private", "protected", and "package") but within the
    Infrastructure document (page 73) solely "public" and "private" are
    mentioned. The same for the enumeration example at page 116.

    Also it would be helpful to shift the visual presentation options
    ("+",
    "-", "#", and "~") for VisibilityKind from the chapter describing
    attributes (Superstructure p. 41) to more general description at page
    16
    which is multiple referenced from other parts of the spec.

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

    see abov e

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

Operation without - UML2 Superstructure

  • Key: UML14-420
  • Legacy Issue Number: 6514
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Page 55 of the current superstructure document lists the operation's
    syntax as "visbility name (parameter-list) : property-string" and
    states
    that "property-string optionally shows other properties of the
    operation
    enclosed in braces".

    I wondering where the good old return type or the property enclosed in
    curly brackets might have gone.

    If the "property-string" mentioned in the operation's syntax quoted
    above is the return type the possibility to add operation wide
    properties (like "query") is gone.

    If the "property-string" is the way to add properties it should be
    enclosed in curly brackets and the separation by the colon from the
    parameter list containing also the return type could be misleading.
    Hence the colon should be dropped or exchanged by another symbol.

    Or am I just misreading the spec?

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

    see above

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

Components and artifacts: Dependency problem - UML2 Superstructure

  • Key: UML14-419
  • Legacy Issue Number: 6513
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Reading the component section of the specification I come across a
    dependency
    problem. Figure 2-9 shows a white-bix representation of a component.
    The bottom
    compartment lists the related artifacts. But the direction of
    manifest dependency
    is from the artifact as source to the component as target. So the
    component
    does not know anything about its implementing artifacts.

    In my opinion the artifacts compartment is wrong.

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

    No Data Available

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

Guard conditions at fork nodes - UML2 Superstructure issue

  • Key: UML14-418
  • Legacy Issue Number: 6512
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I have a question about the token flow traffic rules within activity
    models:

    It is allowed to have guards at outgoing edges from fork nodes.
    The specification says about fork nodes:

    "When an offered token is accepted on all the outgoing edges,
    duplicates of the token
    are made and one copy traverses each edges."

    This means that the fork node offers tokens to its outgoing edges, if
    all guard
    conditions evaluates to true. So there is a dependency between the
    parallel flows
    after a fork node.

    Is that true?

    I think the fork node should offer tokens on all outgoing edges that
    accept the token.
    If there is a guard condition at an outgoing edge, it is possible
    that the flow continues
    only on two of three outgoing edges.

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

    see above

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

Token flow semantics: Implicit fork and join - UML2 Superstructure

  • Key: UML14-417
  • Legacy Issue Number: 6511
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    As mentioned on p. 250 an action execution is created when all its
    object flow and control flow prerequisites have been satisfied
    (implicit
    join). Same for outgoing egdes (implicit fork).

    Is it the same semantic for object nodes?

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

    see above

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

AcitivityEdge: weight=all vs weight=null - UML2 Superstructure

  • Key: UML14-416
  • Legacy Issue Number: 6510
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    there is a mismatch in the specification.

    On p. 262 about the weight attribute on activity edges:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But Fig. 6-39 on p. 265 specifies

    {weight=all} for the same purpose.


    Which one is the correct one?


    I think {weight=all}

    is the better alternative to express the
    semantic.

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

    Duplicate with 6096.

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

Large diamond for binary associations legal? - UML2 Superstructure issue

  • Key: UML14-415
  • Legacy Issue Number: 6509
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Reviewing the current Superstructure spec I noticed that it allows the
    usage of the large diamond in the middle of an association also for
    binary associations which significantly changes to notation compared
    to
    UML 1.x

    By doing so UML class diagrams become Entity-Relationship flavoured
    but
    do not have the semantics of those notation (identity, multiplicities,
    etc.) and also the notation is still different (multiplicity,
    association name, etc.).

    Is it really intended to allow the usage of the large diamond also for
    binary associations?

    Personally, I'm quite reluctant accepting these change ...

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

    No Data Available

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

Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue

  • Key: UML14-414
  • Legacy Issue Number: 6508
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    While trying understand the jungle of diagrams offered by UML I
    probably
    discovered an inconsistency within the most recent Superstructure
    document.

    Page A-546 shows a class digram giving a taxonomy of structure and
    behavior diagrams. The figure (numbered A-5) is accompanied with some
    descriptive text at the same page.
    The diagrams includes a box (class) for a diagram called the
    "collaboration diagram" which is not mentioned in the document set
    elsewhere. But the text mentiones a "communication diagram" which is
    completely missing in the figure.

    Additionally, shouldn't the "protocol state machine" be shown as a
    specialization of the "state machine diagram"?

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

    duplicate

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

Binary associations decorated with large diamonds legal?

  • Key: UML14-413
  • Legacy Issue Number: 6507
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Superstructure document states that "Any association may
    be
    drawn as a diamond ...". This changes the behavior present in UML 1.x
    significantly which only allowed the diamond for n-ary (n>2)
    associations.

    As a consequence of this change a UML diagram may look more like an
    Entity-Relationship model with some changes (placement of the
    association's name, multiplicity notation, and all the semantics)
    than a
    upward compatible UML digram.

    Is this intended?

    I tend to retain UML's former behavor to allow the large diamond only
    for n-ary associations.

    Any ideas or am I just misreading the spec?

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

    No Data Available

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

concurrent vs. parallel ExpansionRegions

  • Key: UML14-412
  • Legacy Issue Number: 6506
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The 3rd rev. draft of UML 2's superstructure document introduces the
    keywords "parallel", "iterative", and "stream" for ExpansionRegions
    (p.
    292).

    But the example figures given at page 296 uses "concurrent" instead of
    "parallel" without any introduction.

    Finally, the metamodel type ExpansionKind (p. 248) solely defines
    "parallel" and the other two keywords mentioned above. "concurrent" is
    completely missing.

    Sure, there is a distinction between concurrency (pseudo-parallel
    execution of processes or threads on one single CPU) and parallelity
    (parallel execution of processes or threads on multiple CPUs) but I'm
    not convinced if we should introduce this distinction at the
    specification level.

    Any ideas?

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

    Duplicate with 6099.

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

Use Case Metamodel - UML2 Superstructure issue

  • Key: UML14-411
  • Legacy Issue Number: 6505
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    I tried to understand some parts of the Use Case metamodel but get
    stucked ...

    Looking at figure 10-49 (p. 468) of the current (i.d. 3rd rev)
    Superstructure document it is not clear or at least not that obvious
    to
    me how the Actor is related to the Use Case.

    The only possibility seems to be the relationship where the UseCase
    participates taking the role useCase connected to the Classifier. But
    I
    don't think that the Actor should play the role subject ...

    Further, the relationship connecting Actors with UseCases allows the
    placement of Multiplicities but users are not encouraged to use roles.
    Why is this asymmetry introduced? I could imagine situations
    (especially
    for business models) where roles would perfectly make sense even for
    Actors. This would be the case always when a actor acts on behalf of
    another entity or an actor is to be specialized w.r.t. a specific
    context.

    Any ideas?

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

    No Data Available

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

ActivityFinalNode and running actions - UML2 Superstructure issue

  • Key: UML14-410
  • Legacy Issue Number: 6504
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Reaching an ActivityFinalNode terminates the activity.
    What happens to running actions within the activity?

    Is there an interruption? Or do they run to completion?

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

    see above

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

Multiobject in UML2

  • Key: UML14-409
  • Legacy Issue Number: 6499
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    I am looking for the multiobject in the UML2 spec.

    It is defined in the UML1.5 spec. as part of the collaboration
    diagram. The multiobject is shown as two rectangles in which
    the top rectangle is shifted slightly vertically and horizontally.

    Is this still valid for UML2? Where can I find the definition in the
    spec?

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

    No Data Available

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

Outputting constants

  • Key: UML14-408
  • Legacy Issue Number: 6491
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    How are constants introduced in a flow, eg, to output a constant to an
    activity parameter node? UML 1.5 had GetLiteralAction to output a
    constant. Reintroduce it or some construct that has the same effect.

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

    see above

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

Protocol machines do not subset state invariant

  • Key: UML14-407
  • Legacy Issue Number: 6490
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Protocol machines subset guards, but not state invariant. What's the
    difference?

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

    No Data Available

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

Conditions for parameter sets (02)

  • Key: UML14-406
  • Legacy Issue Number: 6488
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Parameter sets need conditions for pre/postconditions

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

    see above

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

Clarify termination of asynchronous invocations

  • Key: UML14-405
  • Legacy Issue Number: 6486
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Clarify that asychronously invoked behaviors/operations aren't
    terminated by activity final

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

    see above

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

Appendix A Diagrams

  • Key: UML14-404
  • Legacy Issue Number: 6485
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Figure 464 includes a Collaboration Diagram. Is this a carryover error from UML 1.x or a reference to a diagram that contains Collaborations and CollaborationOccurrences

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

    This is the same issue as issue 6066

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

Section 17

  • Key: UML14-403
  • Legacy Issue Number: 6484
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Page 534 states, "When it is attached to an information channel, a black triangle on the information channel indicates the direction." What is an information channel? This is the only sentence in the document in which this phrase is used.

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

    see above

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

Section 14.4 Diagrams (02)

  • Key: UML14-402
  • Legacy Issue Number: 6483
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 19 the Message entry- it is unclear which message is which and I don't think any of them are reply messages

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

    No Data Available

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

Section 14.4 Diagrams

  • Key: UML14-401
  • Legacy Issue Number: 6482
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    In the text describing Figure 345 it states, "Thus the appearance of a w message after the v is an invalid trace." There is no w message in the diagram.

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

    No Data Available

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

Section 14.4 Diagrams

  • Key: UML14-400
  • Legacy Issue Number: 6481
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 15. The text describing message states, "asynchronous message, a call and a reply" but the graphic shows them in the order of call, asynchronous, reply. The text should match the graphic.

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

    No Data Available

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

Section 14.3.14 Message

  • Key: UML14-399
  • Legacy Issue Number: 6480
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The semantics section states, "There will normally be a return message from the called lifeline..." while the Notation section refers to "The reply message from a method has a dashed line." If the return message and the reply message are the same ting then only use one name. If they are differnt, then explain the difference

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

    see above

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

Section 10 Deployments

  • Key: UML14-398
  • Legacy Issue Number: 6479
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Figure 130 and 131. If these are meant to be two representations of the same node, then make the contents the same or explain the differences. Figure 136 should be <<ExecutionEnvironment>> vice <<container>>. Either that or the text is incorrect and needs to be changed

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

    No Data Available

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

Section 9.4 Diagrams

  • Key: UML14-397
  • Legacy Issue Number: 6478
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 6. The Collaboration and CollaborationOccurrence notation is incorrect

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

    see above

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

Section 8.3.3 Realization

  • Key: UML14-396
  • Legacy Issue Number: 6477
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The text states, "A component realization is notated in the same way as the realization dependency, i.e. as a general dashed line with an open arrow-head." What is an open arrowhead. Compare and contrast that with the "stick arrowhead" described in the Presentation Options section of Class in Composite Structures (page 156). Stick arrowhead can be found 6 times in the spec, while open arrowhead can be found 4 times. They all appear to refer to the same notation. I recommend that you chose one term.

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

    see above

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

Section 8.3.1 Component

  • Key: UML14-395
  • Legacy Issue Number: 6476
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Figure 89 and 90. The text states "A component is shown as a Classifier rectangle with the keyword «component». Optionally, in the right hand corner a component icon can be displayed." Some of the example components do not have the <<component>> included, just the icon is present. My reading of the text is that this is incorrect. The icon is optional but the <<component>> designation is required

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

    see above

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

Section 8.3.1 Component

  • Key: UML14-394
  • Legacy Issue Number: 6475
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Figure 81 should have identifiers for the provided interfaces. Figure 83 is not consistent with section 7.15.3 in that it uses a realization instead of a dependency as described in the text related to Figure 62. The examples in this section are not cohesive. It is not clear how Figure 85 relates to the rest of the examples.

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

    see above

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

Section 8.1 Overview

  • Key: UML14-393
  • Legacy Issue Number: 6474
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types.

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

    see above

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

Section 7.18 Diagrams

  • Key: UML14-392
  • Legacy Issue Number: 6473
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Table 4 - the Package Import dependency should be <<access>> not <<uses>>.

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

    see above

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

Section 7.15.3 Interfaces

  • Key: UML14-391
  • Legacy Issue Number: 6472
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The text states "Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62)." Figure 62 has an association and a generalization relationship, not dependencies.

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

    This issue was resolved by the resolution to issue 6069.

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

Section 7.13.2 Package Merge

  • Key: UML14-390
  • Legacy Issue Number: 6471
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Figure 47. Some of the relationships appear to be generalization and some appear to be realization. It is not clear when Package Merge is useful or necessary. A more concrete example would help

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

    see above

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

Section 7.3.5 PackageImport

  • Key: UML14-389
  • Legacy Issue Number: 6469
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    This section is unique because it does not have a Notation section like all of the others

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

    No Data Available

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

Section 7.3.1 ElementImport

  • Key: UML14-388
  • Legacy Issue Number: 6468
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    The Semantics discussion includes the statement
    An imported element can be further imported by other namespaces using either element or member imports.

    The phrase "member import" is not defined and does not appear anywhere else in the spec. What does it mean? Provide an example of member import.

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

    see above duplicate

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

UML 2 Issue: Include(s) and Extend(s)

  • Key: UML14-387
  • Legacy Issue Number: 6465
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for the Extend and Include relationships is a dashed arrow with
    open arrow and the keyword <<extend>> or <<include>> (Superstructure, pp.
    516, 518). Nevertheless, the notation examples given in pages 521, 523 and
    524 write "extends" and "includes", with an final "s". The other examples
    are allright.

    PROPOSED SOLUTION
    Fix the notation examples.

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

    see above

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

UML 2 Issue: Connector types

  • Key: UML14-386
  • Legacy Issue Number: 6461
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    This is the definition of Connector (Superstructure, p. 163): "Specifies a
    link that enables communication between two or more instances. This link may
    be an instance of an association, or it may represent the possibility of the
    instances being able to communicate because their identities are known by
    virtue of being passed in as parameters, held in variables, created during
    the execution of a behavior, or because the communicating instances are the
    same instance. (...)"

    This paragraph is clearly a reinterpretation of the five old association and
    link stereotypes, now obsolete. Let's rewrite the second sentence as
    follows, inserting those old stereotypes for clarity:

    This link may be an instance of an association, <<association>>
    or it may represent the possibility of the instances being able to
    communicate because their identities are known
    by virtue of being passed in as parameters, <<parameter>>
    (by virtue of being) held in variables, <<???>>
    (by virtue of being) created during the execution of a behavior, <<local>>
    or because the communicating instances are the same instance. <<self>>

    It seems that the concept conveyed by the old <<global>> stereotype has
    completely disappeared (probably an improvement). But the comma between the
    words "variables" and "created" suggests that a new kind of connector, or
    link, has been introduced. But maybe the true intention of the writer was:

    (by virtue of being) held in variables created during the execution of a
    behavior, <<local>>

    That is, the comma between the words "variables" and "created" would be
    superfluous. It is not very important whether the kinds of Connector
    correspond to the old stereotypes, but it is important to know how many
    kinds of Connector there are.

    PROPOSED SOLUTION
    Suppress the comma between the words "variables" and "created".

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

    see above

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

glossary

  • Key: UML14-385
  • Legacy Issue Number: 6459
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The glossary included with the appendices of the text that was adopted by the voters has been removed and that text inserted as normative text. There is no authority for the editors preparing the final adopted specification to make this major change. To make matters worse, the change introduces contradictions into the normative part of the specification.
    ...

    Suggested resolution: Move this text back where it came from.

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

    see above

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

Change 'Part' to 'Role.

  • Key: UML14-384
  • Legacy Issue Number: 6458
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 1 specification, "every time a word coinciding with the name of some construct in UML is used, that construct is referenced." [UML 1 2.3.4]

    In the UML 2 specification, the word, 'part,' is used both to mean a Part and with its ordinary meaning.

    This is an example of a recurrent problem in the specification: words that name UML 2 concepts are used both to refer to that concept, or an instance of that concept, and with their ordinary meaning. The rule of the UML 1 specification needs to be both stated and carefully followed.
    ...

    Suggested resolution: Change 'Part' to 'Role.' This permits the use of 'part' to mean part. Add the rule of the UML 1 specification. Carefully follow that rule.

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

    No Data Available

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

Abandon the OMGS4LMMA

  • Key: UML14-383
  • Legacy Issue Number: 6457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    If the so-called OMGS4LMMA is accepted, it is not possible that an InformationFlow could connect both Classes and Instance Specifications.
    ...

    Suggested resolution: Abandon the OMGS4LMMA. Apply InstanceSpecification uniformly (for example, an informationFlow is used to connect classes and an instanceSpecification of an informationFlow is used to connect instanceSpecifications of classes, that is, to connect objects.

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

    No Data Available

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

14.3: StateInvariant and ExecutionOccurrence

  • Key: UML14-382
  • Legacy Issue Number: 6454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    14.3: StateInvariant and ExecutionOccurrence are both subclasses of InteractionFragment. "Each interaction fragment is conceptually like an interaction by itself." [14.3.9] And, indeed, "An ExecutionOccurrence is an instantiation of a unit of behavior..." [14.3.4] But, "A StateInvariant is a constraint on ... state..." [14.3.17] That's not like an interaction by itself, nor like any interaction at all. We've mixed models of behavior with specifications of constraints on state.

    This is an example of a recurrent problem in the specification: subclasses that are not like their superclasses.
    ...

    Suggested resolution: Review the specification with this in mind and correct all improper subtyping

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

    No Data Available

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

UML 2.0 Superstructure FTF issue - Profiles

  • Key: UML14-381
  • Legacy Issue Number: 6453
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    In the Profile chapter, there is no section for "Changes from UML 1.4" for
    stereotypes

    However, one feature of UML1.4 : attaching tagged values independently of
    any stereotype, has disappeared in UML2.0

    The evolution tagged values --> attribute should be discussed and that
    particular case enlighted. a specific pattern for converting UML1.4
    stereotype independant tags into UML2.0 should be provided.

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

    see above

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

Removal of gratuitous restrictions to software applications

  • Key: UML14-380
  • Legacy Issue Number: 6450
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Removal of gratuitous restrictions to software applications
    Description: UML is being used extensively for systems modeling as well as
    software modeling. Consequently, gratuitous restrictions to software
    applications should be removed from the specification.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT