Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 579
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML14-1045 Compliance ambiguity UML 1.3 UML 1.4 Duplicate or Merged closed
UML14-1041 There is a bug in additional operation 1 of the Namespace element UML 1.4 UML 1.4.2 Resolved closed
UML14-1040 How to properly designate exception returned from message sent to Java obje UML 1.4 UML 1.4.2 Resolved closed
UML14-1039 In 3.23.1 "Notation" (Internationalization issues) UML 1.3 UML 1.4 Resolved closed
UML14-1038 No servant with object . minorcode=0 completed=NO UML 1.3 UML 1.4 Closed; No Change closed
UML14-1037 The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4 UML 1.3 UML 1.4 Resolved closed
UML14-1036 Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics UML 1.3 UML 1.4 Resolved closed
UML14-1035 Who owns an Event? UML 1.3 UML 1.4 Resolved closed
UML14-1033 UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1034 UML 1.4 RTF Issue: Namespace notation too specific UML 1.3 UML 1.4 Resolved closed
UML14-1032 UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1031 UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1030 UML RTF 1.4 editorial comments (Part 2 Diagram Elements) UML 1.3 UML 1.4 Resolved closed
UML14-988 UML RTF 1.4 Issue: Join in collaboration UML 1.2 UML 1.4 Resolved closed
UML14-990 UML RTF 1.4 Issue: Guard evaluation for choice points. UML 1.2 UML 1.4 Resolved closed
UML14-940 UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99 UML 1.1 UML 1.4 Resolved closed
UML14-933 Some attributes can be expressed in OCL UML 1.1 UML 1.4 Resolved closed
UML14-926 Set of allInstances should be referrable by the class name UML 1.1 UML 1.4 Resolved closed
UML14-919 Synchronous request UML 1.1 UML 1.4 Resolved closed
UML14-918 Asynchronous action UML 1.1 UML 1.4 Resolved closed
UML14-559 UML 2 issue, Common Behaviors RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-558 Components / provided and required interfaces -- derived or subsets XMI 2.0 UML 1.4.2 Resolved closed
UML14-557 Feature;ModelElement UML 1.5 UML 1.4.2 Resolved closed
UML14-554 "Physical" Metamodel Package Structure (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-556 TaggedValue in TaggedValue XMI 1.3 UML 1.4.2 Resolved closed
UML14-555 Ambiguous semantics of classifier ownerscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-471 UML2 super/notation/Keywords XMI 2.0 UML 1.4.2 Resolved closed
UML14-470 Appendix B/Standard Stereotypes too heavyweight and incompletely defined XMI 2.0 UML 1.4.2 Resolved closed
UML14-480 UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition XMI 2.0 UML 1.4.2 Resolved closed
UML14-479 The contents of the Interfaces package is shown in Figure 51 XMI 2.0 UML 1.4.2 Resolved closed
UML14-482 UML 2 Super / Interactions / navigability of enclosingOperation XMI 2.0 UML 1.4.2 Resolved closed
UML14-481 UML 2 Super / Dependencies / Abstraction should have an optional mapping XMI 2.0 UML 1.4.2 Resolved closed
UML14-478 UML 2 Super / Templates / subsetting templateParameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-477 UML 2 Super / General / Idenitfy sections specifying run-time semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-476 UML 2 Super / Classes / XMI 2.0 UML 1.4.2 Resolved closed
UML14-473 importedMember property XMI 2.0 UML 1.4.2 Resolved closed
UML14-475 UML 2 Super / Interactions / Two typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-474 missing closing bracket XMI 2.0 UML 1.4.2 Resolved closed
UML14-472 "• value : InstanceSpecification XMI 2.0 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-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-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-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-553 Issue 6090 correction RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-543 UML2 Super / Classes / Operation constraints XMI 2.0 UML 1.4.2 Resolved closed
UML14-542 UML2 Super / ordering of association ends XMI 2.0 UML 1.4.2 Resolved closed
UML14-541 Q re Parameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-537 UML2 super/interactions XMI 2.0 UML 1.4.2 Resolved closed
UML14-536 UML 2 Super / Templates / invalid multiplicity XMI 2.0 UML 1.4.2 Resolved closed
UML14-535 UML 2 Super / Profiles / problem with name collisions XMI 2.0 UML 1.4.2 Resolved closed
UML14-548 XMI schema (02) RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-547 Question about Enumeration and EnumerationLiteral XMI 2.0 UML 1.4.2 Resolved closed
UML14-540 UML 2 Super / missing owners of concepts XMI 2.0 UML 1.4.2 Resolved closed
UML14-539 UML 2 Super / state machines / state should be a namespace XMI 2.0 UML 1.4.2 Resolved closed
UML14-538 UML 2 Super/Connector XMI 2.0 UML 1.4.2 Resolved closed
UML14-546 UML2 Super / Common Behavior / Trigger should be a named element XMI 2.0 UML 1.4.2 Resolved closed
UML14-545 UML2 Super / Use cases / navigation from subject to use case XMI 2.0 UML 1.4.2 Resolved closed
UML14-544 UML 2 Super / General / superclass pointers XMI 2.0 UML 1.4.2 Resolved closed
UML14-552 Issue 6094 correction. RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-551 UML 2 Super/Interactions/Need unattached lifelines RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-534 transition is simply never enabled XMI 2.0 UML 1.4.2 Resolved closed
UML14-533 UML Sequence diagram XMI 2.0 UML 1.4.2 Resolved closed
UML14-550 property strings on association ends RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-549 change trigger RAS 2.0b1 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-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-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-394 Section 8.3.1 Component 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-393 Section 8.1 Overview 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-397 Section 9.4 Diagrams 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-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-454 UML 2 Super/Activities/assocition end specialization 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-455 UML 2 Super/Activities/invalid multiplicity 0 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-453 UML 2 Super/Activities/end naming consistency 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-444 UML 2.0 Superstructure Derived Union vs. derivationExpression? UML 1.5 UML 1.4.2 Resolved closed
UML14-443 UML 2.0 Superstructure reccomendation (derived unions) UML 1.3 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-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-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-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-438 UML 2 Super/Actions/non-existent feature "multiplicity" 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-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-493 UseCase - Constraint for non-circular include relation XMI 2.0 UML 1.4.2 Resolved closed
UML14-492 What level of MOF 2.0 is the metamodel for UML 2.0? XMI 2.0 UML 1.4.2 Resolved closed
UML14-484 UML 2 Super / Realize keyword-stereotype XMI 2.0 UML 1.4.2 Resolved closed
UML14-483 UML 2 Super / Classes / Properties owned by properties XMI 2.0 UML 1.4.2 Resolved closed
UML14-489 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367 XMI 2.0 UML 1.4.2 Resolved closed
UML14-488 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366 XMI 2.0 UML 1.4.2 Resolved closed
UML14-487 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365 XMI 2.0 UML 1.4.2 Resolved closed
UML14-486 UML 2 Super / Deployments / Invalid cross-references XMI 2.0 UML 1.4.2 Resolved closed
UML14-495 UML 2 Super / use cases / incorrect table title XMI 2.0 UML 1.4.2 Resolved closed
UML14-494 UseCase - Include - Constraint for irreflexivity XMI 2.0 UML 1.4.2 Resolved closed
UML14-485 UML 2 Super / Classes / Dependency should not be abstract XMI 2.0 UML 1.4.2 Resolved closed
UML14-496 UML2 superstructur: actor XMI 2.0 UML 1.4.2 Resolved closed
UML14-491 UML 2 Super / General / specialization labeling convention XMI 2.0 UML 1.4.2 Resolved closed
UML14-490 Typo in Collaboration Diagram figure XMI 2.0 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-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-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-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-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-384 Change 'Part' to 'Role. 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-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-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-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-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-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-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-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-410 ActivityFinalNode and running actions - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-518 adopt a single notation to specify text strings used in the notation XMI 2.0 UML 1.4.2 Resolved closed
UML14-517 Appendix A of the superstructure spec XMI 2.0 UML 1.4.2 Resolved closed
UML14-516 UML 2 Super / Activities / Fig.192 constraint duplicated XMI 2.0 UML 1.4.2 Resolved closed
UML14-515 Ambiguous semantics of isStatic - resubmission of issue 4446 XMI 2.0 UML 1.4.2 Resolved closed
UML14-514 UML 2 Super / Interactions / Invalid subsetting for enclosingOperand XMI 2.0 UML 1.4.2 Resolved closed
UML14-513 UML 2 Super / Classes / makesVisible () operation incorrect XMI 2.0 UML 1.4.2 Resolved closed
UML14-512 Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition XMI 2.0 UML 1.4.2 Resolved closed
UML14-526 Operations and derived attributes XMI 2.0 UML 1.4.2 Resolved closed
UML14-525 use of stereotypes XMI 2.0 UML 1.4.2 Resolved closed
UML14-524 UML 2 Super / Appendix A / Typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-523 UML 2 Super/Interactions/Alternative with all false guards XMI 2.0 UML 1.4.2 Resolved closed
UML14-522 UML 2 Super / General / Classes chapter organization XMI 2.0 UML 1.4.2 Resolved closed
UML14-521 UML 2 Super / State machines / incorrect navigation specifications XMI 2.0 UML 1.4.2 Resolved closed
UML14-520 UML 2 Super / General / consistent formatting conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-519 UML 2 Super / General / Dcoument conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-528 Activity Diagrams: Relax Traverse-to-Completion semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-530 UML2 super/Deployments/CommunicationPath XMI 2.0 UML 1.4.2 Resolved closed
UML14-529 State machines / name of transitions association end XMI 2.0 UML 1.4.2 Resolved closed
UML14-532 UML2 Super/Composite Structure XMI 2.0 UML 1.4.2 Resolved closed
UML14-531 UML 1 activities XMI 2.0 UML 1.4.2 Resolved closed
UML14-527 Composite Structures, 03-08-02.pdf XMI 2.0 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-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-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-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-424 does "is not instantiable" imply "isAbstract"? - 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-432 Missing actual arguments in submachines states 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-511 Ambiguous example of a local action on a Lifeline in Figures 334, 335 XMI 2.0 UML 1.4.2 Resolved closed
UML14-510 ambiguous definition of the scope of a break CombinedFragment XMI 2.0 UML 1.4.2 Resolved closed
UML14-509 UML 2 Super/Interactions/inconsistent spelling for InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-502 Ambiguous sentence and typo in description of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-501 graphic nodes for state invariant and continuation are not always distingui XMI 2.0 UML 1.4.2 Resolved closed
UML14-498 Ambiguous semantics of isStatic XMI 2.0 UML 1.4.2 Resolved closed
UML14-497 self-activation notation in Sequence diagrams missing XMI 2.0 UML 1.4.2 Resolved closed
UML14-505 UML 2 Super/Interactions/rationale subsections not informative XMI 2.0 UML 1.4.2 Resolved closed
UML14-504 UML 2 Super/Interactions/incorrect grammar for XMI 2.0 UML 1.4.2 Resolved closed
UML14-507 word "execute" in definition of alternative CombinedFragment is ambiguous XMI 2.0 UML 1.4.2 Resolved closed
UML14-506 UML 2 Super/Interactions/Ambiguous description of state invariants XMI 2.0 UML 1.4.2 Resolved closed
UML14-500 UML 2 Super/Interactions/incorrect text and table title for Table 19 XMI 2.0 UML 1.4.2 Resolved closed
UML14-499 UML 2 Super/Interactions/incorrect text before Table 14 XMI 2.0 UML 1.4.2 Resolved closed
UML14-503 UML 2 Super/Interactions/incorrect spelling of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-508 text differs from metamodel for critical region InteractionOperator XMI 2.0 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-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-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-458 UML 2 Super / Activities / subsetting two properties UML 1.5 UML 1.4.2 Resolved closed
UML14-460 Consistent Naming 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-459 UML2 Super/Signal 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-469 UML 2 Super / use cases / invalid subsetting 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-367 ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics 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-219 Typos 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-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-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-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-226 InstanceSpecification UML 1.5 UML 1.4.2 Resolved closed
UML14-216 Instantiates stereotype 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-177 Parameter set corrections 3 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-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-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-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-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-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-333 Guards on initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-324 Control at joins 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-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-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-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-235 UML 2 Super/Metamodel::Communications/redundant merge error 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-236 UML 2 Super/Metamodel::Nodes/redundant merge error 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-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-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-196 Time spec text 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-193 ExpansionRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-197 Partition semantics 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-201 actions on properties that are association ends 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-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-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-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-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-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-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-340 Clarify ReadSelfAction in activity behaviors UML 1.5 UML 1.4.2 Resolved closed
UML14-337 Guard evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-334 Caption typo 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-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-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-267 UML 2 Super/pg.109/Permission redundant 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-266 UML 2 Super/pg.95/attributes in data types clarification 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-269 UML 2 Super/pg.130/missing notation explanation 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-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-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-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-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-313 UML2.super (or infra)/Profiles-Stereotype (18.3.7) 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-314 UML2 Super/Composite Structures 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-315 UML2 Super/Kernel::Classifier 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-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-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-261 UML 2 Super/Spec/completing mandatory sections 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-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-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-209 Protocol state machines are not pre/postconditions 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-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-213 Kernel::Classifier missing "attribute" 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-206 Concrete Behavior 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-205 Complex port 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-296 UML super/Section 2/Compliance points 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-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-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-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-301 What does redefines mean in package extensibility? 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-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-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-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-353 Figure 395 requires a lot more explanation 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-350 Questions about CentralBufferNode semantic 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-357 UML 2 super / Activities / structured activity node contradiction 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-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-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-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-242 UML 2 Super/Metamodel/merging of non-redefinable model elements 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-248 UML 2 Super/Metamodel::StructuredActivities/double redefinition 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-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-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-182 Parameter semantics clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-192 ExceptionHandler 1 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-187 Notation for for global pre/postconditions actions UML 1.5 UML 1.4.2 Resolved closed
UML14-183 Behavior execution instances UML 1.5 UML 1.4.2 Resolved closed
UML14-188 Notation for isSynchronous UML 1.5 UML 1.4.2 Resolved closed
UML14-186 Value Pin notation 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-176 Parameter set corrections 2 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-169 Pin multiplicity 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-172 ExecutableNode, ControlNode should be abstract 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-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-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-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-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-136 Description of GeneralizationSet 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-143 Obsolete notation used in state machine - transition examples UML 1.5 UML 1.4.2 Resolved closed
UML14-55 Profile Notation UML 1.3 UML 1.4.2 Resolved closed
UML14-54 Appendix A, UML Standard Elements UML 1.3 UML 1.4.2 Resolved closed
UML14-58 Issue: Conflicting WFRs on Transition UML 1.3 UML 1.4.2 Resolved closed
UML14-57 Add Multiplicity to Parameter. UML 1.3 UML 1.4.2 Resolved closed
UML14-56 Events, signals, stimuli, etc. UML 1.3 UML 1.4.2 Resolved closed
UML14-61 Predefined datatypes XMI 1.2 UML 1.4.2 Resolved closed
UML14-60 The definition of Multiplicity in Datatypes does not list the range associa XMI 1.2 UML 1.4.2 Resolved closed
UML14-65 Component notation: logical compartments XMI 1.2 UML 1.4.2 Resolved closed
UML14-64 Exceptions do not correspond to common usage XMI 1.2 UML 1.4.2 Resolved closed
UML14-53 Clarify the origin of an Action in a Collaboration. UML 1.3 UML 1.4.2 Resolved closed
UML14-59 Ambiguous semantics of classifier targetscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-63 Event => Event Specification XMI 1.2 UML 1.4.2 Resolved closed
UML14-62 The text and OCL of rule #5 for Method do not say the same thing. XMI 1.2 UML 1.4.2 Resolved closed
UML14-37 Another State machine issue XMI 1.1 UML 1.4.2 Resolved closed
UML14-36 Data Types Misplaced in the "Physical" Metamodel (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-30 Inheritance violation in "Auxiliary Elements" XMI 1.0 UML 1.4.2 Resolved closed
UML14-33 class EnumerationLiteral issue XMI 1.0 UML 1.4.2 Resolved closed
UML14-35 Operations and Constraints Missing from "Physical" Metamodels XMI 1.1 UML 1.4.2 Resolved closed
UML14-31 Incomplete Inheritance Specification XMI 1.0 UML 1.4.2 Resolved closed
UML14-32 Datatypes: Expression XMI 1.0 UML 1.4.2 Resolved closed
UML14-34 Interfaces on Nodes XMI 1.0 UML 1.4.2 Resolved closed
UML14-38 UML RTF 1.4 Issue: Dynamic concurrency arguments XMI 1.1 UML 1.4.2 Resolved closed
UML14-39 UML RTF 1.4 Issue: Parallel action iteration XMI 1.1 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-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-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-159 Tokens at fork UML 1.5 UML 1.4.2 Resolved closed
UML14-161 ExpansionRegions keywords 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-160 ActivityFinalNode 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-164 Pins owned twice 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
UML14-130 2.5.2.29 Node UML 1.4 UML 1.4.2 Resolved closed
UML14-128 2.5.2.15 Dependency UML 1.4 UML 1.4.2 Resolved closed
UML14-123 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-122 Section: 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-129 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-121 Designates a Generalization (02) UML 1.4 UML 1.4.2 Resolved closed
UML14-125 2.5.2.27 ModelElement UML 1.4 UML 1.4.2 Resolved closed
UML14-126 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-124 2.5.2.16 Element UML 1.4 UML 1.4.2 Resolved closed
UML14-127 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-82 UML 1.4: ClassifierRole contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-81 UML 1.4: Node, Artifact, Package and Model contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-89 Suggest that alternate syntax used in section 6.5.5 be adopted thoughout XMI 1.3 UML 1.4.2 Resolved closed
UML14-88 Invalid XMI.link.atts in UML 1.4 DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-95 UML 1.4.1 should use MOF 1.4 XMI 1.3 UML 1.4.2 Resolved closed
UML14-94 Add action for invoking an activity XMI 1.3 UML 1.4.2 Resolved closed
UML14-84 UML 1.4: Wrong target for StateMachine.top association XMI 1.3 UML 1.4.2 Resolved closed
UML14-83 UML 1.4: AttributeLink containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-87 Definitions in glossary don't conform to any standard for definitions XMI 1.3 UML 1.4.2 Resolved closed
UML14-86 Composite relationship between Event and StateMachine XMI 1.3 UML 1.4.2 Resolved closed
UML14-92 Simplify inputs/outputs of procedures XMI 1.3 UML 1.4.2 Resolved closed
UML14-91 match/correspond clarfication XMI 1.3 UML 1.4.2 Resolved closed
UML14-93 StartStateMachine clarification XMI 1.3 UML 1.4.2 Resolved closed
UML14-90 Namespace.contents XMI 1.3 UML 1.4.2 Resolved closed
UML14-85 Adding events to the class definition XMI 1.3 UML 1.4.2 Resolved closed
UML14-17 Parametrizable model elements not shown XMI 1.0 UML 1.4.2 Resolved closed
UML14-119 Inconsistency regarding guards on forks XMI 1.3 UML 1.4.2 Resolved closed
UML14-118 spelling of the word Use Case XMI 1.3 UML 1.4.2 Resolved closed
UML14-110 There is an unnecessary condition in rule 1 of the Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-109 Rule 6 of the Method element isn't formulated well XMI 1.3 UML 1.4.2 Resolved closed
UML14-115 There is a misprint in rule 2 of the Object element: “Stimuli” instead of “ XMI 1.3 UML 1.4.2 Resolved closed
UML14-114 There are misprints with numeration of rules of the Instance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-112 there is something wrong with rule 3 of the Trace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-120 The first sentence is not consistent with figure 2-9 on page 2-17 XMI 1.3 UML 1.4.2 Resolved closed
UML14-113 Wrong alphabetical order: DataValue section should be before DestroyAction XMI 1.3 UML 1.4.2 Resolved closed
UML14-111 Add rule to Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-116 There is a misprint in rule 1 of the SubsystemInstance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-117 font sizes XMI 1.3 UML 1.4.2 Resolved closed
UML14-69 Using or implementing an interface of a Subsystem UML 1.4 UML 1.4.2 Resolved closed
UML14-68 XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD UML 1.4 UML 1.4.2 Resolved closed
UML14-67 Optimize Instance data values XMI 1.2 UML 1.4.2 Resolved closed
UML14-66 Component notation: showing delegation of messages XMI 1.2 UML 1.4.2 Resolved closed
UML14-75 UML 1.4: State containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-74 UML 1.4: Action problem in Collaborations XMI 1.3 UML 1.4.2 Resolved closed
UML14-80 UML 1.4: Event containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-79 UML 1.4: Stimulus containment XMI 1.3 UML 1.4.2 Resolved closed
UML14-77 UML 1.4: Transition containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-76 UML 1.4: ExtensionPoint containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-78 UML 1.4: Feature containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-72 Compliance to the UML" pp xxxi -- Editorial? UML 1.4 UML 1.4.2 Resolved closed
UML14-71 Nameclash in UML 1.4 UML 1.4 UML 1.4.2 Resolved closed
UML14-70 Using OCL at the meta-model level UML 1.4 UML 1.4.2 Resolved closed
UML14-73 UML 1.4: Action containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-19 Guard in current metamodel can be replaced by Constraint with stereotype XMI 1.0 UML 1.4.2 Resolved closed
UML14-18 Need for notation for dealing with evolution of UML models XMI 1.0 UML 1.4.2 Resolved closed
UML14-25 Missing OCL XMI 1.0 UML 1.4.2 Resolved closed
UML14-24 OCL needs to be added XMI 1.0 UML 1.4.2 Resolved closed
UML14-26 ElementOwnership XMI 1.0 UML 1.4.2 Resolved closed
UML14-28 extension to the notation for a transition XMI 1.0 UML 1.4.2 Resolved closed
UML14-23 Page 19 semantic doc. name XMI 1.0 UML 1.4.2 Resolved closed
UML14-22 UML 1.1.section 4.2:editorial XMI 1.0 UML 1.4.2 Resolved closed
UML14-27 User-defined symbols for tagged values and properties XMI 1.0 UML 1.4.2 Resolved closed
UML14-29 Associate a predicate with a state XMI 1.0 UML 1.4.2 Resolved closed
UML14-21 Figure 7 p. 43 of the UML semantics guide XMI 1.0 UML 1.4.2 Resolved closed
UML14-20 AssociationEnd needs ownerScope XMI 1.0 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-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-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-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-146 Strange notation in Figure 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-147 No Glossary in 03-08-02 UML 1.5 UML 1.4.2 Resolved closed
UML14-100 Initial state for composite states - OCL example and missing constraint XMI 1.3 UML 1.4.2 Resolved closed
UML14-99 UML 1.4 - Partition relates to nothing XMI 1.3 UML 1.4.2 Resolved closed
UML14-104 In v1.4, section 3.84.1 the paragraph on semantics XMI 1.3 UML 1.4.2 Resolved closed
UML14-103 Section 2.13.4.3 XMI 1.3 UML 1.4.2 Resolved closed
UML14-101 UML Issue - Inconsistency between UML 1.3 XMI and DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-107 Section number duplicated XMI 1.3 UML 1.4.2 Resolved closed
UML14-106 Section 3.90.2.2 XMI 1.3 UML 1.4.2 Resolved closed
UML14-97 Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState XMI 1.3 UML 1.4.2 Resolved closed
UML14-96 A_context_raisedSignal XMI 1.3 UML 1.4.2 Resolved closed
UML14-102 How does one indicate the target object for a CallState XMI 1.3 UML 1.4.2 Resolved closed
UML14-105 parameters of object flow states XMI 1.3 UML 1.4.2 Resolved closed
UML14-98 Well-formedness rules for 2.12.3.8 XMI 1.3 UML 1.4.2 Resolved closed
UML14-108 Swap rule 2 and rule 3 of the Binding element XMI 1.3 UML 1.4.2 Resolved closed
UML14-49 MOF rules should disallow certain composition relationships UML 1.3 UML 1.4.2 Resolved closed
UML14-48 Notation for inherited associations UML 1.3 UML 1.4.2 Resolved closed
UML14-52 Conflicting constraint between ActivityGraph and StateMachine. UML 1.3 UML 1.4.2 Resolved closed
UML14-51 Attributes obsolete in UML 1.3 UML 1.3 UML 1.4.2 Resolved closed
UML14-50 Interface of an object UML 1.3 UML 1.4.2 Resolved closed
UML14-46 Why is a StateMachine's top a State instead of a CompositeState? UML 1.3 UML 1.4.2 Resolved closed
UML14-45 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings XMI 1.1 UML 1.4.2 Resolved closed
UML14-42 Efficient diagrammatic notation for Collaboration Specifications XMI 1.1 UML 1.4.2 Resolved closed
UML14-41 Statemachine/state as Namespace XMI 1.1 UML 1.4.2 Resolved closed
UML14-40 UML RTF 1.4 Issue: Missing notation mapping for association in composite XMI 1.1 UML 1.4.2 Resolved closed
UML14-47 Document 99-06-08 - UML Spec UML 1.3 UML 1.4.2 Resolved closed
UML14-43 ClassifierRoles should be independent of specific underlying base Classifi XMI 1.1 UML 1.4.2 Resolved closed
UML14-44 UML 1.4 issue: Top state in activity graphs XMI 1.1 UML 1.4.2 Resolved closed
UML14-7 issues and bugs on the UML 1.4 Draft UML 1.3 UML 1.4 Resolved closed
UML14-6 class TaggedValuewill two association-ends with the same name "stereotype" UML 1.3 UML 1.4 Resolved closed
UML14-14 Figure 2-15 of the uml 1.4 spec UML 1.3 UML 1.4 Resolved closed
UML14-13 page 2-163, the statemachine semantics escription UML 1.3 UML 1.4 Resolved closed
UML14-16 isPolymorphic is never in a diagram UML 1.3 UML 1.4 Resolved closed
UML14-15 well-formedness rule for Package is missing inUML 1.4 UML 1.3 UML 1.4 Resolved closed
UML14-10 it's => its on page 3-150. UML 1.3 UML 1.4 Resolved closed
UML14-9 Wf 2 for AssociationEnd UML 1.3 UML 1.4 Resolved closed
UML14-8 2.9.2 Abstract Syntax UML 1.3 UML 1.4 Resolved closed
UML14-12 Notation example typo in Fig. 3-99 UML 1.3 UML 1.4 Resolved closed
UML14-11 The glossary entry "call" should be "call state". UML 1.3 UML 1.4 Resolved closed
UML14-3 elimination of the Association Class TemplateParameter UML 1.3 UML 1.4 Resolved closed
UML14-2 2) Page 2-49, additional operation #7 for Classifier UML 1.3 UML 1.4 Resolved closed
UML14-5 Remove uses of multiple inheritance from UML meta model UML 1.3 UML 1.4 Resolved closed
UML14-4 Who owns a Comment? UML 1.3 UML 1.4 Resolved closed
UML14-1 Page 2-47, well-formedness rule #2 for Classifier UML 1.3 UML 1.4 Resolved closed

Issues Descriptions

Compliance ambiguity

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

    Although the current specification defines the basic units of
    compliance for UML, it does not clearly specify the extent to which they may
    be omitted (via the "no/incomplete" Valid Options in the summary table on p.
    xxv) before the implementation is not considered OMG UML. (As a degenerate
    case, it could be argued that they all could be omitted and that an
    implementation might still claim compliance.) Further note that the optional
    compliance of OCL is discussed as a special case on p. xxiii, although no
    special treatment of its compliance is reflected in the summary table.
    Optional compliance needs to be more clearly specified before we consider
    future optional compliance points, as some are proposing for the Action
    Semantics.

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Duplicate or Merged — UML 1.4
  • Disposition Summary:

    duplicate

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

There is a bug in additional operation 1 of the Namespace element

  • Key: UML14-1041
  • Legacy Issue Number: 5733
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: “contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)”.

  • Reported: UML 1.4 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Issue 4848 also raises a similar problem with Namespace.contents

  • Updated: Fri, 6 Mar 2015 21:40 GMT

How to properly designate exception returned from message sent to Java obje

  • Key: UML14-1040
  • Legacy Issue Number: 5433
  • Status: closed  
  • Source: ObjectShare ( Rebecca Wirfs-Broc)
  • Summary:

    I am trying to properly designate an exception returned from a message sent to a Java object.

    In UML a return is drawn as a dashed line with an open arrow. But is that the same for an exception returned? I can stereotype a return with the <<exception>> which is fine , but how do I properly draw the returned exception. I don't think the exception should be drawn the same as an asynchronous signal because control pops out from the exception raiser and returns to the callee at the exception handling point (it is the result of the original call, but the exception return is to a different point in the flow).... so it isn't exactly a signal.... but it does alter the control flow..

    So in my mind, if I wanted to show a returned exception, I should draw it like a return (dashed line with open stick arrowhead) labelled <<exception>>

    But I defer to someone with more expertise to untangle this for me. I spent time and could not find an answer to this in the UML 1.4 docs

  • Reported: UML 1.4 — Mon, 17 Jun 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of the issue addressed by issue 7397.

  • Updated: Fri, 6 Mar 2015 21:39 GMT

In 3.23.1 "Notation" (Internationalization issues)

  • Key: UML14-1039
  • Legacy Issue Number: 4120
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    > In 3.23.1 "Notation", it is described that
    > italics are used to represent abstract classes.
    > We don't usally use slanting letters in Japanese.
    > It seems strange. So, I think this should be moved into
    > "Presentaion Options" or "Style Guidelines".
    >
    > In 3.22.4 "Style Guidelines",
    > it is described that uppercase letters are
    > used to represent class names and
    > lowercase letters are used to represent attributes
    > and operation names.
    > Japanese language doesn't have uppercase nor lowercase
    > letters. However, this is "Style Guidelines", so I think
    > this is not a problem, because the specification already
    > says that "Style Guideline" and "Presentation Option" are
    > not mandatory.

  • Reported: UML 1.3 — Sat, 9 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

No servant with object . minorcode=0 completed=NO

  • Key: UML14-1038
  • Legacy Issue Number: 4060
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am running a simple program but i am getting the error

    "There is no servant with object . minorcode=0 completed=NO"

    but i am not finding any documentation that explains abt the minorcode=0. it starts from 1. can u please help me out

  • Reported: UML 1.3 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Closed; No Change — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4

  • Key: UML14-1037
  • Legacy Issue Number: 3637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4.4 as follows:

    2.9.4.25 Object and DataValue . 2-103
    2.9.4.26 Link . . . . . . . . . . 2-104
    2.9.4.27 Signal, Exception and Stimulus . 2-104
    2.9.4.28 Action . . . . . . . . 2-105

    It would appear that the fourth level carries on from 2.9.3.24

  • Reported: UML 1.3 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics

  • Key: UML14-1036
  • Legacy Issue Number: 3631
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    The Action ModelElement looks like it is abstract in the Rose MDL
    because the name is in italics.
    However, checking the details tab in Rose shows that it has not been marked
    as abstract.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Who owns an Event?

  • Key: UML14-1035
  • Legacy Issue Number: 3558
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    An Event is aggregated by a transition but there seems to be no
    reference to who owns an event.
    If it should reside in a Package the OCL-WellFormedness rule for Package
    should be updated.

  • Reported: UML 1.3 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams)

  • Key: UML14-1033
  • Legacy Issue Number: 3400
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 9 - Statechart Diagrams
    1. In Part 9 - Statechart Diagrams:[Proposed changes in red for the
    first 3 suggestions.] "A statechart diagram can be used to describe the
    behavior of instances of a model element such as an object or an
    interaction. Specifically, it describes possible sequences of states and
    actions through which the element instance can proceed during its lifetime
    as a result of reacting to discrete events (e.g., signals, operation
    invocations). " [The idea is that model elements are not dynamic or have
    lifetimes; rather they apply to instances of model elements.]
    2. In 3.74.1: "Typically, it is used for describing the behavior of
    classes instances, but statecharts may also describe the behavior of other
    model entities such as use-cases, actors, subsystems, operations, or
    methods." [A method is an instance of an operation. Therefore, you must have
    implementation level knowledge, in this case, the programming language used,
    to know about a method. This is antithetical to good modeling principles
    which state that a model should be implementation independent.]
    3. In 3.74.3: "That StateMachine may be owned by an instance of a model
    element capable of dynamic behavior, ..."
    4. Event-name or action-label??? 3.75.2 says "Internal transitions
    compartment This compartment holds a list of internal actions or activities
    that are performed while the element is in the state. The notation for such
    each of these list items has the following general format: action-label '/'
    action-expression" and later "The general format for the list item of an
    internal transition is: event-name '(' comma-separated-parameter-list ')'
    '[' guard-condition']' '/'action-expression". Which is to be used? Or is
    action-label the name of the expression: event-name '('
    comma-separated-parameter-list ')' '[' guard-condition']'? Compare this with
    3.78.2 which has " event-signature '[' guard-condition ']' '/'
    action-expression. The event-signature describes an event with its
    arguments: event-name '(' comma-separated-parameter-list ')'"
    5. In 3.75.2: "If the event has parameters, they can be used in the
    action expression through the current event variable." Should it be
    action-expression for consistency?
    6. 3.75.4: "The action expression maps into the ActionSequence and
    Guard for the Transition." Should it be action-expression?
    7. 3.75.4: "The Transition has a trigger Association to the Event." The
    term trigger does not appear to be unambiguously defined. It was previously
    mentioned in the section. " In all other cases, the action label identifies
    the event that triggers the corresponding action expression." Is this
    sufficient? It is not in the glossary.
    8. The use of the term pseudostate is not consistent throughout. In the
    glossary it is "pseudo-state", with a hyphen. In 2.12.2 it is pseudostate.
    9. 3.76.3, Figure 3-63: Passed and Failed are activities and not
    states. Change to the right graphic.
    10. 3.78.1: " A simple transition is a relationship between two states
    indicating that an object in the first state ..." Object should probably be
    instance. (This should be looked at throughout the document.) I suspect this
    opens a can of worms but the definitions, and probably the concepts
    themselves, of instance and object need clarification.
    11. 3.80.4 Figure 3-66: Each of the two diagrams should have a top level
    state around it to keep the rule about not transitioning from a stubbed
    state to an external state. See below. Granted they are implied but we are
    trying to be clear.
    12. 3.80.5: Eliminate the word "elision". It is not a common word plus
    it appears to be misused. "Elision is the omission of sounds, syllables, or
    words in spoken or written discourse
    </lingualinks/library/literacy/glossary/cjJ405/tks2801.htm>." and "The
    omission of a letter or syllable as a means of contraction, generally to
    achieve a uniform metrical pattern, but sometimes to smooth the
    pronunciation; such omissions are marked with an apostrophe <gl-a.html>.
    Specific types of elision include aphaeresis <gl-a.html>, apocope
    <gl-a.html>, syncope <gl-s.html>, synaeresis <gl-s.html> and synaloepha
    <gl-s.html>." Suggest replace with shortcut.
    13. 3.81.2: " represented by a a small white circle" Eliminate one "a".
    14. 3.83.2: " The bound is either a positive integer or a star ('*') for
    unlimited." "Unlimited" should be "any number" and "star" should be
    "asterisk".

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: Namespace notation too specific

  • Key: UML14-1034
  • Legacy Issue Number: 3408
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Namespace notation too specific

    The model management namespace containment notation (the circled plus
    sign ) should be available on all namespace elements.

  • Reported: UML 1.3 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams)

  • Key: UML14-1032
  • Legacy Issue Number: 3399
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 6 - Use Case Diagrams
    1. 3.56.1: Use different class names in the relationships: extend use A
    & B, generalization use C & D, include use E & F for clarity.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements)

  • Key: UML14-1031
  • Legacy Issue Number: 3398
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 3 - Behavioral Elements
    1. In 2.8: typo "that is used to model proocesses." Should be
    "processes"
    2. In 2.9.2, Figure 2-15: "Clas" should be "Class"
    3. In 2.9.2, Figure 2-15 and Argument: There is an internal
    inconsistency. The relationship from Argument to Action is diagrammed as a
    composition. The text says: [An argument] "is aggregated within an action."
    Is it aggregation or composition?
    4. Continuing #3: Also the glossary definition of composition ties
    non-fixed multiplicity and coincident lifetimes. Does 0..1 count as
    non-fixed? If so, where is it defined? What does this distinction mean in
    the first place?
    5. In 2.9.2, Instance: "The instance construct defines an entity to
    which a set of operations can be applied ..." Operation should be method.
    Operations exist at the Classifier level; methods are instances of
    operations and exist at the instance (application) level.
    6. In 2.9.2, Instance\Tagged Values\persistent: "Persistence denotes
    the permanence of the state of the instance, marking it as transitory (its
    state is destroyed when the instance is destroyed) or persistent (its state
    is not destroyed when the instance is destroyed)." Seems it should say that
    transitory is the default. Else add transitory as a tagged value.
    7. In 2.9.2, Figure 2-16: Would two refinements be clearer than the two
    associations from Link to Association and LinkEnd to AssociationEnd since
    they are a different levels of abstraction? Also from Instance to
    Classifier? [Should the relationship from Method to Operation in 2.5.2,
    Figure 2-5 also be a refinement?]
    8. In 2.9.2, Figure 2-16: Should the composition relationship from
    Attribute to Classifier also be modeled?
    9. In 2.9.2, Figure 2-16: The element Instance is abstract according to
    the text and should be stereotyped <<abstract>>.
    10. In 2.9.2, Link: "In the metamodel Link is an instance of an
    Association. It has a set of LinkEnds that matches the set of
    AssociationEnds of the Association." In Figure 2-16 LinkEnd to Link is

    {ordered}

    . Should this be consistent with AssociationEnd to Association?

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 2 Diagram Elements)

  • Key: UML14-1030
  • Legacy Issue Number: 3397
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 2 - Diagram Elements
    1. 3.6.4: Title should be 'Examples' for clarity. Or add a subheading
    to communicate that a list of examples follows.
    2. 3.10.3: same as above
    3. 3.10.7: same as above
    4. 3.12: "Examples of such pairs in UML include: Class-Object,
    Association-Link, Parameter-Value, Operation-Call, and so on." Should
    Operation-Call be Operation-Method? 3.59.5 defines a call as procedural.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Join in collaboration

  • Key: UML14-988
  • Legacy Issue Number: 3275
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is possible to model forks in sequence charts using multiple
    asynchronous messages. However, it is not possible to model
    joins, because return messages are considered activitators, and
    multiple activators are not allowed.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Guard evaluation for choice points.

  • Key: UML14-990
  • Legacy Issue Number: 3278
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Make guard evaluation procedure for choice points more explicit.
    It is not clear from the specification whether all guards are
    required to be evaluated, even after one is found to be true.
    This affects performance/real time issues even if the guards have
    no side-effects.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99

  • Key: UML14-940
  • Legacy Issue Number: 2292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the current version of UML, use cases must not have associations to other use cases specifying the same entity. Use cases can exchange messages only with actors and not with each-other. UML use cases are always initiated by a signal from the actor.

    However, there are use cases that are initiated by a system if a specific condition is met. Example: in the well-known ATM machine example the use case "dispense cash" is initiated by the system, if the customer request was evaluated as valid. The use case "dispense cash" is not initiated by the (user) actor. In other words, the use case "dispense cash" receives a message or signal from the other use case specifying the same system. Therefore, the association between use cases must exist.

    Solution: Allow associations between use cases specifying the same entity.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Some attributes can be expressed in OCL

  • Key: UML14-933
  • Legacy Issue Number: 2074
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At several places in the UML metamodel there are attributes of type
    "...Expression". Some of these might be specified in OCL. This should be
    stated in the metamodel. The OCL specification should expicitly describe the
    meaning and context of such an OCL expresion.
    Examples are:
    Action: attribute target : ObjectSetExpression
    Argument: attribute value : Expression
    ChangeEvent: attribute changeExpression : BooleanExpression

    Especially the last one should be expressable in OCL, since it is
    a Boolean Expression.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Set of allInstances should be referrable by the class name

  • Key: UML14-926
  • Legacy Issue Number: 2017
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ances of a class, as
    in "Person.allInstances". It is quite common in many area"s to use the
    class name for this collection.
    To get the size of the collection of persons we now need to write:
    Person.alllnstances->size"
    With the proposes change we can write:
    Person->size
    which is a shorthand for the use of allInstances.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Synchronous request

  • Key: UML14-919
  • Legacy Issue Number: 2006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: synchronous request is defined as a request where the client object
    pauses to wait for completion of the request.

    1) My understanding of CORBA is that a request is only synchronous
    with respect to a given thread. Is this true?

    • So, does the sending client truly pause to wait for results?
    • Or is it just a thread of that client that pauses for results?

    Deferred synchronous request (mentioned on p.78) has not been
    defined.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Asynchronous action

  • Key: UML14-918
  • Legacy Issue Number: 2004
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An asynchronous action is defined as a request where the sending object does not pause to wait for results. Synonym: asynchronous request [OMA].

    1) What results?
    In the OMA v3 (June 13 1995), it is said on p. 78 that
    an asynchronous request has no response (hence no results).
    So, soes "results" means "response", or something else ?

    2) The OMA speaks also of a deferred synchronous request –
    proceed after sending request; claim reply later).
    The synonym used is confusing since the OMA has a concept of
    deferred synchronous request in which the sending object does
    not pause to wait for results (proceed after sending request;
    claim reply later).

    3) In fact, my understanding is that the sending object does not
    even pause to wait for the receiving object to be notified of
    the request. The definition is silent about this.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML 2 issue, Common Behaviors

  • Key: UML14-559
  • Legacy Issue Number: 7380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Behaviors: objects that don't exist?

    At 13.1 we read:

    "Behaviors, as such, do not exist on their own, and they do not communicate. ... (Note that an executing behavior may itself be an object, however.)"

    It is not clear what this is intended to mean. To the untutored reader it seems to be a contradiction.

    What a behavior is and what a behavior execution is is fundamental to this half of UML. Whatever is intended should be spelled out clearly for the reader, very clearly.

  • Reported: RAS 2.0b1 — Wed, 26 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Components / provided and required interfaces -- derived or subsets

  • Key: UML14-558
  • Legacy Issue Number: 6875
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

  • Reported: XMI 2.0 — Fri, 2 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • 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

"Physical" Metamodel Package Structure (uml-rtf)

  • Key: UML14-554
  • Legacy Issue Number: 3123
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The package structure of UML 1.3 makes it difficult to deploy small parts of
    the "physical" metamodel separately. For example, a MOF-based facility that
    supports classes from Behavioral_Elements.Common_Behavior must support all
    of Behavioral_Elements. A facility that supports Exceptions must also
    support Use Cases and State Machines. This has been a problem in the
    formation of the CWM metamodel which extends UML. Its interfaces and DTDs
    are made to be much too large.

    The result of UML currently having three metamodels (two of which are large)
    rather than many smaller metamodels is that the IDL modules are very large
    and so are the DTDs. Breaking the metamodels into several smaller ones will
    allow smaller interface sets and DTDs that can be mixed and matched to
    provide necessary functionality without a huge overhead.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

TaggedValue in TaggedValue

  • Key: UML14-556
  • Legacy Issue Number: 4726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a ModelElement can contain any number of
    taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

    However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
    it can itself contain taggedValues.

    The question is: is this really intended? And if so: please explain the
    semantics of such a construction.

    If not, at simple well-formedness rule

    self.taggedValue = { }

    attached to TaggedValue would do the trick.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

Ambiguous semantics of classifier ownerscope

  • Key: UML14-555
  • Legacy Issue Number: 4446
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier ownerscope is ambiguous for structural
    features declared on classifiers that have children. It is not
    defined whether this gives value for the classifier and all its
    descendents, or values for the classifier and each descendant
    separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 super/notation/Keywords

  • Key: UML14-471
  • Legacy Issue Number: 6877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is a general issue that is quite pervasive. I think it is important
    enough to be considered by the FTF.

    The specification is littered with keywords which are used on diagrams
    to indicate various things.

    What the specification sorely needs is an Appendix that gathers them all
    together. And cross-references each with where it is defined and the
    compliance level it is associated with.
    Also what it needs is a general description of the semantics of
    keywords, how they differ from 'Standard Stereotypes' and associated
    constraints - e.g. it should not be allowed to declare a Stereotype with
    a name which, when decapitalized, is the same as a keyword (since they'd
    be indistinguishable).

    Arguably keywords would be depicted with a distinct notation from
    stereotypes (based on language design principles and to help users
    interpret diagrams where they see words in guillemets and don't know
    whether to look it up in the list of keywords or stereotypes) but that
    is probably too major a change to make at this stage. However the
    notation should be clarified to cover the following cases:
    A) if the same element requires a keyword and has a stereotype applied
    are they shown in 2 separate <<xxx>> expressions or in one, separated by
    a comma?
    B) if a stereotype is applied to a class normally indicated by a
    keyword, does that keyword still need to be provided?

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Appendix B/Standard Stereotypes too heavyweight and incompletely defined

  • Key: UML14-470
  • Legacy Issue Number: 6876
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is in my opinion important enough to be considered by the FTF since
    it affects implementability.

    Appendix B contains a list of Standard Stereotypes.
    Ironically, due to the nature of the UML2 Profile mechanism this
    mechanism is more heavyweight than a subclass since it requires a
    separate instance - so for the <<call>> stereotype of Usage one ends up
    with not only a instance of Usage but an attached instance of Call -
    this is far more heavyweight than having a distinct subclass of Usage
    which would result in only one object. And it's also harder to process
    via XMI or APIs.

    The Appendix is not adequate as a definition and does not use the
    official Stereotype notation? In particular it does not make clear the
    name of the instance of Stereotype (which I can only guess would be the
    capitalized form of the stereotype keyword e.g. "Call"), nor does it
    specify the name of the association used to attach an instance of the
    stereotype with the instance of the metaclass. And, of course, is there
    actually a Profile object (or objects) that contains these stereotypes?
    Can users consider this Profile already applied to any UML model or does
    it have to be explicitly done or is this a variation point?

    Finally, Appendix B is not properly referenced: 7.14.1 refers to the
    "Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
    Standard Profile".

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition

  • Key: UML14-480
  • Legacy Issue Number: 6925
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

    Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

    Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

  • Reported: XMI 2.0 — Sun, 18 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

The contents of the Interfaces package is shown in Figure 51

  • Key: UML14-479
  • Legacy Issue Number: 6913
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

    Should be "Figure 58"

  • Reported: XMI 2.0 — Fri, 16 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / navigability of enclosingOperation

  • Key: UML14-482
  • Legacy Issue Number: 6928
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

  • Reported: XMI 2.0 — Sun, 25 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Dependencies / Abstraction should have an optional mapping

  • Key: UML14-481
  • Legacy Issue Number: 6926
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

  • Reported: XMI 2.0 — Wed, 21 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Templates / subsetting templateParameter

  • Key: UML14-478
  • Legacy Issue Number: 6911
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / Idenitfy sections specifying run-time semantics

  • Key: UML14-477
  • Legacy Issue Number: 6902
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Classes /

  • Key: UML14-476
  • Legacy Issue Number: 6901
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    on page 115 (section 7.15.3) when talking about the Notation of an
    interface, the third paragraph (between figure 59 and 60) says:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *implements* this interface (see Figure 60).
    "

    And I think it should say:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *requires* this interface (see Figure 60).
    "

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

importedMember property

  • Key: UML14-473
  • Legacy Issue Number: 6897
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    The importedMember property is derived from the ElementImports and the PackageImports.

    self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

    The query importedMembers(...) should be importMembers(...). A fixed version is:

    self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Interactions / Two typos

  • Key: UML14-475
  • Legacy Issue Number: 6900
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 408 there is text that says:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335.

    I think it should say:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

    On page 414 there is text that says

    See example of the usage of collaboration occurrences in Figure 345.

    I think it should say:

    See example of the usage of collaboration occurrences in Figure 339.

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

missing closing bracket

  • Key: UML14-474
  • Legacy Issue Number: 6898
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) )

    The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) )

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

"• value : InstanceSpecification

  • Key: UML14-472
  • Legacy Issue Number: 6896
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Corrections and improvements to glossary definitions

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

    Description: Consider the following corrections and improvements to Terms
    and Definitions:

    Activation ­ Consider changing from “the execution of an action” to
    “initiating the execution of an action”.

    Analysis ­ Delete the term “software”.

    Artifact ­ Delete the term “software”.

    Comment ­ Replace term “note” with “comment”.
    Runtime. run-time for a physical system, to imply execution of the
    operational system. (S-pg 252)

    Deployment diagram ­ Replace “software artifacts as nodes” with “artifacts
    on nodes”. Delete the term software and change as to on.

    Design ­ Delete the term “software”. Delete “required functional and
    quality”. This is too restrictive, and doesn't include physical
    requirements, etc.

    Design time - Delete the term “software”.

    Development process - Delete the term “software”.

    Diagram ­ Update the types of diagrams to be consistent with the proposal
    (i.e. timing diagrams, structure diagrams, information flow, etc)

    Generalization ­ Insert “indirect” prior to “instance of the general
    classifier”.

    Inheritance ­ Delete last fragment “related by behavior”.

    Interaction diagram ­ Include reference to timing diagram.

    Interaction overview diagram ­ delete “s” on nodes

    Layer ­ Don’t restrict the use of the term partition to reflect a vertical
    slice of the architecture. This is too limiting. Add a qualifier such as
    may.

    Modeling time - Delete the term “software”.

    Module - Delete the term “software”.

    Object diagram ­ should this be replaced with Instance diagram.

    Part ­ Add the following after classifier instance “or roles of a
    classifier”. Reference the definition for “Role”, which provides
    clarification.

    Partition - Don’t restrict the use of the term partition too much. Partition
    can reflect the grouping of any set of model elements based on a set of
    criteria.

    Run time ­ Insert after “computer program” “or a system”.

    Specification ­ Consider changing the definition to “a set of requirements
    for a system or other classifier.

    Subsystem ­ Replace “See package” with “See system”

    System ­ Replace system definition with the following: A component which
    contains parts, and has observable properties and behaviors.

    Trace ­ Add the following ­ A dependency between a derived requirement and a
    source requirement

    Use case diagram ­ Change from “A diagram that shows the relationships among
    actors and use cases within a system” to “A diagram that shows the
    relationships among actors, the subject (system), and use cases

  • Reported: UML 1.5 — Thu, 6 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 name "required interface" is misleading

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

    The name "required interface" is misleading
    Description: The name "required interface" is misleading, since a required
    interface is not really an interface; it is a usage of an interface.
    Recommendation: Rename "required interface" to something more descriptive

  • Reported: UML 1.5 — Thu, 6 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 significant typo - collaboration diagram

  • Key: UML14-373
  • Legacy Issue Number: 6439
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In the UML 2.0 Superstructure final adopted specification
    document 03-08-02 (and all previous versions), the phrase
    "collaboration diagram" appears in the last row of Figure 464 on
    page 590, and in no other place in the entire document. This
    occurrence probably missed the global change from "collaboration
    diagram" to "communication diagram". This is a key figure that is
    likely to be reproduced in many articles and slide sets, and
    should be fixed.

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

    This is the same as issue 6066.

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

targetScope on StructuralFeature and AssociationEnd

  • Key: UML14-372
  • Legacy Issue Number: 6437
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x supported targetScope on StructuralFeature and AssociationEnd. This does not seem to be present in UML 2.0 when looking at Property or elsewhere. For backward compatibility this should be reinstated or alternatively at least be a standard tag in Appndix B.

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

    see below

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

Specification of parametric models

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

    Description: It is unclear how to specify parametric models as they are used
    in systems engineering. In particular, it is unclear how to specify
    mathematical or logical equations (e.g., Force = mass * acceleration) that
    constrain the values of classifier attributes/properties. Systems engineers
    must be able to:
    a) Specify the dependencies between parameters and expressions or
    constraints. This must support arbitrarily complex and continuous time
    equations.
    b) Allow parameters to be passed into expressions.

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

    No Data Available

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

Excessive syntactic and semantic overlap between structured Classifiers

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

    There is excessive syntactic and semantic overlap between two
    kinds of structured Classifiers: StructuredClasses::Classes and Components.
    It is confusing to users how to choose between these constructs, and how to
    apply them correctly. The confusion extends to how Ports and Interfaces are
    used with these constructs, since it is unclear how to use both of these in
    a complementary manner.
    Recommendation: Remove one of these structured Classifiers, or clarify how
    to choose between and apply them. Also explain how to apply Ports and
    Interfaces in a complementary manner for both black-box and white-box views
    of structured Classifiers.

  • Reported: UML 1.5 — Thu, 6 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 Superstructure: 03-08-02 / <>

  • Key: UML14-371
  • Legacy Issue Number: 6434
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Definition mismatch:

    p. 108/109:
    "...dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class."

    p. 595:
    "A usage dependency among classifiers indicating that
    operations on the client create instances of the supplier."

    Either use a <<create>> dependency on p. 108/109 or change definition on p. 595.

    I think the instantiate dependency is a relationshp between an instance and its specification.

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

    Duplicate of issue 6159

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

ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort

  • Key: UML14-370
  • Legacy Issue Number: 6432
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 3, Composite Structures, Table 3, p. 151: The "Reference"
    column for Port refers to ComplexPorts. ComplexPorts are not defined in the
    specification.

    Recommendation: Delete the reference to ComplexPorts and clarify the
    language in the Reference column for Port accordingly

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

    see above

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

ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint

  • Key: UML14-369
  • Legacy Issue Number: 6431
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures,
    constraint [1], p. 146, which says: "The multiplicities on connected
    elements must be consistent." This seems too vague. Consistency needs to be
    defined more precisely.

    Recommendation: The English statement of the constraint should be expressed
    directly in terms of the properties of the metamodel. (The constraint
    should be expressed in OCL too, of course.)

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

    see above

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

Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity

  • Key: UML14-368
  • Legacy Issue Number: 6429
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures, third
    paragraph of the Notation section, which starts on page 142: This paragraph
    discusses how to notate the multiplicity of a Port (last line of p. 142),
    referring to Figure 3-35 on page 143. However, the semantics of Port
    multiplicity do not appear to be spelled out.

    Recommendation: Define the semantics of the multiplicity of a Port.

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

    No Data Available

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

Issue 6090 correction

  • Key: UML14-553
  • Legacy Issue Number: 7561
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6090 correction. The following sentence should have been added to the last paragraph of the resolution to issue 6090: "An action may not put more values on an output pin in a single execution than the upper multiplicity of the pin."

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / Classes / Operation constraints

  • Key: UML14-543
  • Legacy Issue Number: 7366
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, the UML 2 specification defines Operation properties precondition, postcondition, and bodyCondition that are owned constraints. However, these properties do not subset the Namespace::ownedRule property, but rather the Namespace::ownedMember property.

    The opposites of these properties are preConstraint, postConstraint, and bodyConstraint, all of which are non-navigable and subset Constraint::context and Constraint::namespace.

    Also, the Constraint::namespace property, which is non-navigable, subsets Constraint::context, which is navigable. This is inconsistent, and in fact violates the UML's own constraint on property subsetting which stipulates that a navigable property can only be subsetted by a navigable property (constraint [4] of metaclass Property).

    The consequence of all this is that a Constraint that is the precondition (for example) of an Operation does not have a context . This means that a constraint such as an OCL expressions in pre-conditions cannot be parsed against the context namespace.

    There are (at least) two ways to solve this problem:
    let Operation::precondition and its cohorts subset Namespace::ownedRule instead of Namespace::ownedMember (which would leverage the eContainer() "cheat" that EMF offers to get the owner of an element that doesn't have a navigable owner property)
    let Constraint::namespace redefine NamedElement::namespace and make it navigable, thus making the subset relationship with Constraint::context valid

    The first option seems preferred, for two reasons:
    It makes sense that all constraints that a namespace owns should be included in the ownedRule property
    This would be consistent with the Behavior metaclass, whose precondition and postcondition properties do subset ownedRule

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / ordering of association ends

  • Key: UML14-542
  • Legacy Issue Number: 7365
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems to me the the following properties should perhaps be ordered (currently they are not):

    ApplyFunctionAction::argument
    Association::endType
    CombinedFragment::operand
    ConnectableElement::end
    InteractionOccurrence::argument
    Message::argument
    StringExpression::subExpression
    StructuredClassifier::ownedAttribute
    TemplateSignature::parameter

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Q re Parameter

  • Key: UML14-541
  • Legacy Issue Number: 7355
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There appears to be an inconsistency in the specification as to what it
    means to be a formal parameter or a return result. Please choose between the
    following two interpretations:

    A. A return result is a parameter that is specially indicated to be the
    return result. All other parameters are formal parameters.

    B. A return result is any parameter with direction return, out, or inout. A
    formal parameter is any parameter with direction in or inout.

    You could view (A) as focusing on the syntactical role the parameters play,
    while (B) focuses on when they communicate data.

    The difficulty arises from that the infrastructure and the superstructure
    have differing machineries of dealing with parameters.

  • Reported: XMI 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 7344

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

UML2 super/interactions

  • Key: UML14-537
  • Legacy Issue Number: 7301
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf: page 412: consider/ignore - I can find no explanation of how
    the message types to be considered/ignored are modeled. The spec should be
    clear on this issue, probably in the description of combined fragment.

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

    see above

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

UML 2 Super / Templates / invalid multiplicity

  • Key: UML14-536
  • Legacy Issue Number: 7277
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 428 says that TemplateParameterSubstitution::ownedActual has a multiplicity of (0..1). However, the association description on page 549 states that the multiplicity is (1..). However, it seems to me that the multiplicity was intended to be 0.. despite what the diagram (and Rose model) seem to suggest.
    This is because a template substitution may not necessarily own any of its actual parameter values.

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Profiles / problem with name collisions

  • Key: UML14-535
  • Legacy Issue Number: 7276
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new rule for extension end role names as adopted in ballot 10 (specifically for metaclass extension role names) is likely to lead to name collisions. For example, a stereotype that extends the Package metaclass with a property named 'basePackage' would conflict with the recommended role name of the metaclass extension end ('basePackage'). The recommended role names should be less likely to collide with names that might be chosen for stereotype properties, for example, base$"ExtendedMetaClassName" (i.e. base$Package).

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

XMI schema (02)

  • Key: UML14-548
  • Legacy Issue Number: 7402
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema." [2] The requirement to comply with an XMI schema may be ambiguous. If this is intended to require that a compliant implementation correctly create a model from an XMI file written according the the XMI scheam and write an XMI file from a model according to that schema, this ought to be spelled out.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This aspect has been clarified as part of the resolution to issue 6248

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

Question about Enumeration and EnumerationLiteral

  • Key: UML14-547
  • Legacy Issue Number: 7379
  • Status: closed  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    Enumeration is a subtype of DataType, and DataType allows both Properties and Operations. And since Enumeration has no additional constraints, this means that Enumeration also allows owned Property and Operation instances. Is there a reason why this is so? I would have expected an OCL constraint that limited the owned members of Enumeration to be only EnumerationLiteral instances.

    EnumerationLiteral is a subtype of InstanceSpecification, which itself is a subtype of PackageableElement. Because Package and own any number of PackageableElements, Package can actually own EnumerationLiteral. Is there a reason why this is so? The sematics talk about EnumerationLiteral being in the scope of an Enumeration, but it is somewhat vague about whether that is a constraint (there are no additional constraints). I would have expected an OCL constraint stating that EnumerationLiteral is only valid in the context of an Enumeration.

  • Reported: XMI 2.0 — Thu, 20 May 2004 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 / missing owners of concepts

  • Key: UML14-540
  • Legacy Issue Number: 7336
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined

  • Reported: XMI 2.0 — Fri, 14 May 2004 04: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 / state should be a namespace

  • Key: UML14-539
  • Legacy Issue Number: 7323
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, a State is not a namespace, even though it contians things such as entry and exit pseudostates, substates, etc. all of which are in the context of a State. Therefore, State should be made a kind of Namespace as well as being a kind of Vertex. (Note that Vertices in general do not need to be Namespaces.

  • Reported: XMI 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6207.

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

UML 2 Super/Connector

  • Key: UML14-538
  • Legacy Issue Number: 7321
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 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.

    Doesn't this imply a semantic variation point?

  • Reported: XMI 2.0 — Fri, 7 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super / Common Behavior / Trigger should be a named element

  • Key: UML14-546
  • Legacy Issue Number: 7369
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 317, Trigger is defined as a specialization of Element. However, it seems reasonable for triggers to have names, so it really should be a subclass of NamedElement

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / Use cases / navigation from subject to use case

  • Key: UML14-545
  • Legacy Issue Number: 7368
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current model of use cases does not allow navigation from a subject classifier of a use case to its use case. It should be possible to do this, so that a classifier can easily identify which use cases apply to it. The proposed resolution is to make Classifier::useCase navigable.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / superclass pointers

  • Key: UML14-544
  • Legacy Issue Number: 7367
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It would greatly improve readability if every metaclass had a section that listed all the immediate superclasses of that class. This would also make the document consistent with the resolution to issue 7156, which indicates that such a subsection should exist.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Issue 6094 correction.

  • Key: UML14-552
  • Legacy Issue Number: 7560
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6094 correction. The resolution to Issue 6094 made action concrete, but left the assocations input and output as unions, which are derived and cannot be used in a a direct instance of Action (the input and output associations were changed to nonderived, but this is inconsistent). Restore original model and introduce OpaqueAction instead

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/Need unattached lifelines

  • Key: UML14-551
  • Legacy Issue Number: 7553
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At present, a lifeline always requires a corresponding ConnectableElement. For informal users of UML this requires that have to declare a specific structure for every interaction diagram that they want to draw. However, there are many uses of UML who want a less formal approach. For example, people may want to attach scenarios to use cases informally, that is, without having to talk about any specific connectable elements.

    Therefore, the multiplicity of the Lifeline::represents association end should be changed from 1 to 0..1.

  • Reported: RAS 2.0b1 — Wed, 30 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

transition is simply never enabled

  • Key: UML14-534
  • Legacy Issue Number: 7256
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Maybe this is a stupid question. But I could not find an answer ... A transition is not required to have a trigger. If the source of the transition is a composite state, its triggering is described by the rules about "completion transitions". But what happens if the source is just a simple state: It would seem that the transition cannot be considered as a "completion transition", but at the same time, the transition never satisfies the rules about "enabled transitions". Hence it woulds seem that the transition is simply never enabled. Is this interpretation correct? If so, it this behaviour really intended?

  • Reported: XMI 2.0 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML Sequence diagram

  • Key: UML14-533
  • Legacy Issue Number: 7253
  • Status: closed  
  • Source: Independence Blue Cross ( Janardhanam Venkat)
  • Summary:

    In the UML Sequence diagram there are asynchronous message that is very useful in designing application. I am trying to create an activity diagram between 4 asynchronous system. Why cant we have asynchronous arrow in activity diagram between swim lanes? That is the true representation of a flow in a distributed system.

  • Reported: XMI 2.0 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

property strings on association ends

  • Key: UML14-550
  • Legacy Issue Number: 7404
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The drawings show property strings on association ends, which consist of a comma separated list of property strings. This is not authorized by the Notation section of 7.11.2.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

change trigger

  • Key: UML14-549
  • Legacy Issue Number: 7403
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value of one or more attributes or associations." [13.3.8] Does this intend to mean a change in value not of of one or more attributes, but of one or more slots? If so, then does it also intend to mean a change in value not of of one or more associations, but of one or more links? But, can the value of a link change? "A link is a tuple with one value for each end of the assocaition, where each value is an instance of the type of the end." [7.11.2] With a different value, we have a different tuple. Perhaps the text intends: A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value in one or more slots or the creation of destruction of one or more links.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04: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 ( Mr. 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 ( Mr. 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 ( Mr. 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 8.3.3 Realization

  • Key: UML14-396
  • Legacy Issue Number: 6477
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 ( Mr. 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 14.4 Diagrams

  • Key: UML14-401
  • Legacy Issue Number: 6482
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 ( Mr. 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 8.3.1 Component

  • Key: UML14-394
  • Legacy Issue Number: 6475
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 14.3.14 Message

  • Key: UML14-399
  • Legacy Issue Number: 6480
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 ( Mr. 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 8.1 Overview

  • Key: UML14-393
  • Legacy Issue Number: 6474
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 14.4 Diagrams (02)

  • Key: UML14-402
  • Legacy Issue Number: 6483
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 9.4 Diagrams

  • Key: UML14-397
  • Legacy Issue Number: 6478
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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

UML2 Super/Ports

  • Key: UML14-450
  • Legacy Issue Number: 6669
  • Status: closed  
  • Source: The MathWorks ( Mr. 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 ( Mr. 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

UML 2 Super / Activities / association end naming

  • Key: UML14-457
  • Legacy Issue Number: 6679
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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 ( Dr. 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/assocition end specialization consistency

  • Key: UML14-454
  • Legacy Issue Number: 6676
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

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 ( Mr. 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

UML 2 Super/Activities/invalid multiplicity 0

  • Key: UML14-455
  • Legacy Issue Number: 6677
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

UML2 Super/Structured Classes

  • Key: UML14-447
  • Legacy Issue Number: 6666
  • Status: closed  
  • Source: The MathWorks ( Mr. 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

UML 2 Super/Activities/end naming consistency

  • Key: UML14-453
  • Legacy Issue Number: 6675
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

Page 164 - there are two constraints sections for Connector

  • Key: UML14-448
  • Legacy Issue Number: 6667
  • Status: closed  
  • Source: The MathWorks ( Mr. 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

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.0 Superstructure reccomendation (derived unions)

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

    For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.

  • Reported: UML 1.3 — Thu, 30 Nov 2000 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

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

  • Key: UML14-442
  • Legacy Issue Number: 6643
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

UML2 Super/parts

  • Key: UML14-446
  • Legacy Issue Number: 6648
  • Status: closed  
  • Source: The MathWorks ( Mr. 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 ( Mr. 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

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 ( Dr. 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

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

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

  • Key: UML14-438
  • Legacy Issue Number: 6627
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

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

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 ( Dr. 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

UseCase - Constraint for non-circular include relation

  • Key: UML14-493
  • Legacy Issue Number: 6965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Constraint for non-circular include relation

    I suggest to add the following fragments to the sections "Additional Operations" and "Constraints":

    Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases.

    UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) )

    Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self)

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

What level of MOF 2.0 is the metamodel for UML 2.0?

  • Key: UML14-492
  • Legacy Issue Number: 6959
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    UML 2.0 does not state which level of MOF (EMOF, CMOF, or
    whatever else) provides its meta-meta-model. Therefore, there is
    no formal statement defining which Class definition (Basic or
    Constructs package level) and so forth is the basis for the
    definitions in the UML 2.0 specification. UML tools implement
    this class, so it's probably a good idea to know which one it's
    supposed to be. (Proof, in case you're wondering: The names
    EMOF and CMOF do not occur anywhere in the Superstructure
    final adopted specification 03-08-02. The name MOF does, but
    not in the context of which version of MOF defines the
    UML metametamodel.)

    If there is an ambiguity in which it is, the FTF needs to resolve
    it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it
    should be stated clearly in the specification.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Realize keyword-stereotype

  • Key: UML14-484
  • Legacy Issue Number: 6930
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired.

    The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this.

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 2 Super / Classes / Properties owned by properties

  • Key: UML14-483
  • Legacy Issue Number: 6929
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers)

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367

  • Key: UML14-489
  • Legacy Issue Number: 6949
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Top of page 367, text says:
    Activity diagrams have graphical elements for containment. These
    are included in Table 13.

    In the next line, the table caption says:
    Table 13 - Graphic nodes included in activity diagrams

    Proposed resolution:
    These are inconsistent, although not necessarily wrong. They should be
    made consistent.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366

  • Key: UML14-488
  • Legacy Issue Number: 6948
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Middle of page 366, text says:
    The graphic paths that can be included in structural diagrams are
    shown in Table 12.

    In the next line, the table caption says:
    Table 12 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365

  • Key: UML14-487
  • Legacy Issue Number: 6947
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:

    Issue 1:
    Top of page 365, text says:
    The graphic nodes that can be included in structural diagrams are
    shown in Table 11.

    In the next line, the table caption says:
    Table 11 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Deployments / Invalid cross-references

  • Key: UML14-486
  • Legacy Issue Number: 6946
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / use cases / incorrect table title

  • Key: UML14-495
  • Legacy Issue Number: 6969
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UseCase - Include - Constraint for irreflexivity

  • Key: UML14-494
  • Legacy Issue Number: 6967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Include - Constraint for irreflexivity

    I suggest to add the following constraint for Include:

    Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6965.

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

UML 2 Super / Classes / Dependency should not be abstract

  • Key: UML14-485
  • Legacy Issue Number: 6945
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some):

    Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown
    Table 4, P.130, defines a visual symbol for it
    Fig. 101, P.155, shown as abstract
    Fig. 126, P.183, shown as abstract
    Fig 130, P.188, shows a pure dependency in an example
    Table 9, P.199, defines a visual symbol for it

    Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 superstructur: actor

  • Key: UML14-496
  • Legacy Issue Number: 6970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML2 superstructure 03-08-02
    p. 513
    "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."

    A subsystem is a component stereotype, so it doesn't make sense to mention it here.

    I would propose the following constraint instead of the above one:
    "[1] An actor can only have associations to classifiers, and these associations must be binary."

    It makes sense that an actor can have binary associations to the subject they are interacting with.
    The subject of an use case is a classifier.

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / specialization labeling convention

  • Key: UML14-491
  • Legacy Issue Number: 6958
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Typo in Collaboration Diagram figure

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

    In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443,
    figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs
    a colon, and should be "y:superB" (as it is in the top right box).

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 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 ( Dr. 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

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
  • 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 ( Mr. 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 ( Dr. 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

Diagram Taxonomy corrections

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

    Description: The diagram taxonomy should be corrected as follows:
    a) "Collaboration Diagram" as a subtype of "Interaction Diagram" should be
    renamed "Communication Diagram";
    b) "Collaboration Diagram" should be added as a subtype of "Composite
    Structure Diagram";
    c) "Interaction Diagram" should be classified as a subtype of "Sequence
    Diagram" and "Activity Diagram"

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

    No Data Available

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

Inconsistent use of terms "implement" and "realize"

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

    Description: The terms “implement” and “realize” are used inconsistently
    throughout the specification. These terms should be defined in the glossary
    (Preface, Terms and Definitions) and applied consistently throughout the
    specification.

  • Reported: UML 1.5 — Thu, 6 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 ( Mr. 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 ( Mr. 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

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

Section 7.13.2 Package Merge

  • Key: UML14-390
  • Legacy Issue Number: 6471
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. 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 ( Mr. 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

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

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 ( Mr. 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

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

  • Key: UML14-416
  • Legacy Issue Number: 6510
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

Guard conditions at fork nodes - UML2 Superstructure issue

  • Key: UML14-418
  • Legacy Issue Number: 6512
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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 ( Mr. 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

Multiobject in UML2

  • Key: UML14-409
  • Legacy Issue Number: 6499
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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 ( Mr. 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

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

Protocol machines do not subset state invariant

  • Key: UML14-407
  • Legacy Issue Number: 6490
  • Status: closed  
  • Source: NIST ( Mr. 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 ( Mr. 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

ActivityFinalNode and running actions - UML2 Superstructure issue

  • Key: UML14-410
  • Legacy Issue Number: 6504
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. 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

adopt a single notation to specify text strings used in the notation

  • Key: UML14-518
  • Legacy Issue Number: 7135
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three different ways to specify text strings used in the notation and two variations.

    The three ways:

    1. a sort of Bakus-Naur form as in: multiplicity ::= <multiplicity_range> [ ‘

    {‘ <order_designator> ‘}

    ’ ] see Super 7.4.1

    2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [

    { property-string }] see Super 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown.

    3. a third way, combining features of both as in: visibility name ‘<‘ template-parameter-list ‘>’ ‘<<‘binding-expression-list ‘>>’‘( ‘ parameter-list ‘)’ ‘:’ property-string see Super 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.)

    Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }

    ] {{ [ name ] ‘:’ classname } | name } [ ‘[‘ multiplicity ‘]’ ] see Super 17.5.7

    The two variations:

    a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [

    { property-string }

    ] see Super 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see Super 7.10.1

    b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see Super 7.10.1

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Appendix A of the superstructure spec

  • Key: UML14-517
  • Legacy Issue Number: 7125
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Appendix A of the superstructure spec specify the usage of frames
    in diagrams. The text says:
    "Each diagram has a frame, a contents area, and a heading, see Figure 460."

    This statement implies that frames are normative. The text later says
    that "In cases where not needed, the frame may be omitted and implied by the border of the diagram area provided by a tool."

    This entire explanation distorts the common intent and practice of UML
    diagramming. Text should present the frames as an optional presentation
    option in the first place. Also, in all cases mentioned (ports, entry points)
    it is possible to notate the context using class boxes or states, so in none of these cases frames are "needed". It is a mere presentation option that might be

    used as an alternative to using prime container symbols.

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 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 / Fig.192 constraint duplicated

  • Key: UML14-516
  • Legacy Issue Number: 7099
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In Fig. 192 on pg. 277, the association end StructuredActivityNode::activity, the constraint

    {redefines activity}

    is duplicated

  • Reported: XMI 2.0 — Fri, 5 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of isStatic - resubmission of issue 4446

  • Key: UML14-515
  • Legacy Issue Number: 7098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6974

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

UML 2 Super / Interactions / Invalid subsetting for enclosingOperand

  • Key: UML14-514
  • Legacy Issue Number: 7069
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious model consistency issue with InteractionFragment::enclosingOperand because it is currently constrained to be a subset of NamedElement::namespace, but its type (InteractionOperand) is not a specialization of Namespace. Also, InteractionOperand::enclosingInteraction does not subset NamedElement::namespace (it probably should; Interaction is already an indirect specialization of Namespace).

    The simplest solution is to make InteractionOperand a specialization of Namespace

  • Reported: XMI 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / Classes / makesVisible () operation incorrect

  • Key: UML14-513
  • Legacy Issue Number: 7068
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there appears to be a bug in the specification with respect to the definition of the makesVisible() OCL query on packages. Here is the OCL expression from the specification (page 100):

    Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
    pre: self.member->includes(el)
    makesVisible = el.visibility->isEmpty() or el.visibility = #public

    As you can see, this definition makes even imported elements visible based on their own visbility rather than the visibility of the import
    relationship. The same applies to elements made visible indirectly via a package import.

  • Reported: XMI 2.0 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition

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

    It seems that there is an issue with the hasVisibilityOf(NamedElement) operation on Classifier. In particular, it doesn't consider visibilities when determining if a member is visible:

    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf =true

    One might logically expect the operation to exclude, for example, members with private visibility.

  • Reported: XMI 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Operations and derived attributes

  • Key: UML14-526
  • Legacy Issue Number: 7219
  • 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: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

use of stereotypes

  • Key: UML14-525
  • Legacy Issue Number: 7213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Today, the reason for this mail is that in my UML certification I was asked a question regarding the include and extend relationship between use cases.
    I was (and am still a bit) confused, because one question was dealing with the extend and include notation between use cases. I think the 640 pages UML 2 documnet 03-08-02.pdf is inconsistent here. (I now ask because I think I lost two correct answers in my fundamental UML 2 certification caused by include/includes and extend/extends...): UML 1 used the stereotype notations "extends" and "includes". Im UML 2, the classifiers are now called "include" and "extend". But confusingly enough, some association arrows inside the OMG document 03-08-02.pdf
    "UML Superstructure 2.0 Draft Adopted Specification" use the stereotypes (see <<extends>> and <<includes>> in Fig 406 p. 521 and twice <<extends>> and one time <<includes>> in Table 22 on page 523/524.)

    Who to report these inconsistencies to? Or are the stererotypes still allowed to be labeled <<extends>> and one time <<includes>> ?

  • Reported: XMI 2.0 — Fri, 26 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6465.

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

UML 2 Super / Appendix A / Typos

  • Key: UML14-524
  • Legacy Issue Number: 7162
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    p587 para 2 line 2 "UML diagrams contains graphical elements" (should be "contain")
    p587 para 5 line 1 "symbols defines the type" (should be "define")
    p587 last para "C1 and C1" (should be "C1 and C2")
    p588 para 1 line 2 "a graphical symbols" (should remove "a")
    p588 para 1 line 4 "assocition"

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/Alternative with all false guards

  • Key: UML14-523
  • Legacy Issue Number: 7160
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Semantics of the alternative CombinedFragment (page 410) does not describe what happens if all branches are guarded, and
    all guards are false.
    Does this means: a) empty trace, or b) (dynamically) invalid trace ?
    I suggest to add a sentence, defining such traces as dynamically invalid.
    This will be consistent with the behavior of a ConditionalNode in Activities (page 313): "if no test section yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node".

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / Classes chapter organization

  • Key: UML14-522
  • Legacy Issue Number: 7159
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Classes chapter is organized differently from all other chapters in the document – it should be made consistent with the organization of all the other chapters

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 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 navigation specifications

  • Key: UML14-521
  • Legacy Issue Number: 7158
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 354 on page 457, it is shown that it is not possible to navigate back from Region towards either the state machine that owns it or the state that owns it. However, it is often necessary to know who the owner of a region is, therefore these associations need to be made navigable in both directions.

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super / General / consistent formatting conventions

  • Key: UML14-520
  • Legacy Issue Number: 7157
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Different chapters in different parts of the spec use different conventions for naming, headings, layout etc. These should all be made consistent based on one shared convention.

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is resolved by the resolutions to issue 6958 and 7190.

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

UML 2 Super / General / Dcoument conventions

  • Key: UML14-519
  • Legacy Issue Number: 7156
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The document needs an explanation of how it is laid out and how the format and meaning of the various sections in the individual class descriptions

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML14-528
  • Legacy Issue Number: 7221
  • 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: XMI 2.0 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 super/Deployments/CommunicationPath

  • Key: UML14-530
  • Legacy Issue Number: 7228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 10.3.2 and Figure 125 the constraint is given that a
    CommunicationPath can only associate Nodes.
    This seems too restrictive and does not, for example, allow
    CommunicationPaths between actual servers (Instance Specifications).

    Proposed resolution:
    Relax constraint such that a CommunicationPath can link
    DeploymentTargets.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

State machines / name of transitions association end

  • Key: UML14-529
  • Legacy Issue Number: 7226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::StateMachines::BehaviorStateMachines::Region::transitions should be renamed to transition (i.e. made singular) to be consistent with the naming convention for other association ends.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super/Composite Structure

  • Key: UML14-532
  • Legacy Issue Number: 7231
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 178, table 6 - the entry for port shows the only option for a port as
    being on the boundary of an enclosing box whereas the notation section for
    ports (169) states that port boxes may be shown inside the boundary of the
    enclosing box. The port entry on table 6 should amended so that it includes
    all cases.

    page 179, the table is headed table 6 but should be table 7.

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 1 activities

  • Key: UML14-531
  • Legacy Issue Number: 7230
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    figure 274 - should the arrow between Award Quote and Quote Responses be the
    other way round

  • Reported: XMI 2.0 — Fri, 9 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Composite Structures, 03-08-02.pdf

  • Key: UML14-527
  • Legacy Issue Number: 7220
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Can a connector be typed by an association one of whose ends are composite
    or shared? I can't see anything in the spec that prohibits this but I'm not
    sure that it makes a lot of sense to do so.

  • Reported: XMI 2.0 — Mon, 22 Mar 2004 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 ( Mr. James J. 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

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

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

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

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

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

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

/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

Ambiguous example of a local action on a Lifeline in Figures 334, 335

  • Key: UML14-511
  • Legacy Issue Number: 6988
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 415-6 Figures 334,335 use a rectangular box with the text "DoSth" in it. The meaning of this symbols is not explained in the corresponding section, nor in Table 14 graphical nodes in Sequence Diagrams.
    In ITU Message Sequence Charts this would mean an informal action, local to the Lifeline.

    The syntax and semantics of local actions is the key issue in "executable sequence diagrams", and in proper alignment of semantics between Interactions, Activities and State Machines (and Actions).

    As a minimum, Figures 334, 335 need to be explained, and table 14 updated.
    It would be better to illustrate formal use of Actions.
    Ideally, Interactions will benefit from a data sublanguage based on Actions, in order to have a capability to fully specify flows of data between Lifelines:

    • message parameters (including composite values)
    • local attributes (storing data in Lifeliens; in data structures like lists, sets, tables, etc.)
    • identities of objects (input and output pins for actions)
    • actions (manipulations on data, access to data structures and composite values)
    • proper usage of data in guards and state invariants
    • proper usage of data in loop expressions
  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

ambiguous definition of the scope of a break CombinedFragment

  • Key: UML14-510
  • Legacy Issue Number: 6987
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 410 mentions that "Break CombinedFragments must be global relative o the enclosing InteractionFragment".

    This is ambiguous and needs to be explained in more precise way, involving InteractionOccurences and Interaction Overview Diagrams. There were debates on the scope of a similar construct in the ITU language.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/inconsistent spelling for InteractionOperator

  • Key: UML14-509
  • Legacy Issue Number: 6986
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    The enum type name InteractionOperator is often misspelt (e.g. interactionOperator or interaction operator). It is also used inconsistently when referring to a particular operator, e.g. InteractionOperator alt.
    I suggest using a single typigraphic convention:
    InteractionOperator <italic> alt </italic>

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Ambiguous sentence and typo in description of EventOccurence

  • Key: UML14-502
  • Legacy Issue Number: 6979
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 416:

    The sequences of Eventoccurences are the meanings of Interactions. >>Messages are sent through either asynchronous signal sending or operation calls.<<
    Likewise they are >>>recieved<<< by >>Receptions or actions of consuption.<<

    typo needs to be corrected.
    highlighted parts need to be re-phrased and terminology aligned with the rest of the spec.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

graphic nodes for state invariant and continuation are not always distingui

  • Key: UML14-501
  • Legacy Issue Number: 6978
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    It is not possible to visually distinguish between a continuation (oval with a name) and a simple state invariant (also oval with a state name). Compare Figure 345 and 334.

    One possibility is to use guard syntax for state invariants.
    Another possibility is to use a different graphic for continuations

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of isStatic

  • Key: UML14-498
  • Legacy Issue Number: 6974
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

self-activation notation in Sequence diagrams missing

  • Key: UML14-497
  • Legacy Issue Number: 6972
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.

    E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56

    This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

  • Reported: XMI 2.0 — Fri, 6 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

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

UML 2 Super/Interactions/rationale subsections not informative

  • Key: UML14-505
  • Legacy Issue Number: 6982
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Most sections in chapter 14 on Interactions do not have a Rationale subsection, while the remaining few only contain the text "not applicable". This is not informative.
    I suggest to remove the Rationale subsections altogether.

    Pages 414 421 423 425 428 430 433

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the empty “Rationale” sub-sections on pages 414, 421, 423, 425, 428, 430, 433.

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

UML 2 Super/Interactions/incorrect grammar for

  • Key: UML14-504
  • Legacy Issue Number: 6981
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Grammar for <state-info> at page 434 has a typo:
    <state-info>::=<region}

    {, <region> }*


    must be:
    <state-info>::=<region> {, <region> }

    *

    It is not clear, how to define <region-name> in Sequence Diagrams.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

word "execute" in definition of alternative CombinedFragment is ambiguous

  • Key: UML14-507
  • Legacy Issue Number: 6984
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 410 The word "execute" is used to describe the Alternative CombinedFragment i nthe context "operand will execute", etc. This word is ambiguous. I suggest changing it to "operand is chosen", etc.
    Or even the full description, like "the meaning of the InteractionOperator alt is a trace corresponding to only one of its operands".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/Ambiguous description of state invariants

  • Key: UML14-506
  • Legacy Issue Number: 6983
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 433 has the following text: "A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of >>eventual attributes<< of the Lifeline".

    The term >>eventual attribute<< may be ambiguous.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/incorrect text and table title for Table 19

  • Key: UML14-500
  • Legacy Issue Number: 6977
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 450 has the following text:
    "The graphic nodes that can be included into >>structural diagrams<< are shown in Table 19". Table 19 has the following title "Graphic nodes and paths included in >>sequence diagrams<<"

    The text needs to be changed into "The graphic nodes >>and paths<< that can be included into >>timing diagrams<< are shown in Table 19"

    Title of Table 19 should read "timing diagrams" instead of "sequence diagrams".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Interactions/incorrect text before Table 14

  • Key: UML14-499
  • Legacy Issue Number: 6976
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 436 has the following text:
    "The graphic nodel that can be included in >>structural diagrams<< are shown in Table 14."

    Table 14 is called "Graphic nodes included in sequence diagrams".

    Text needs to be changed into "sequence diagrams"

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6934, already resolved

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

UML 2 Super/Interactions/incorrect spelling of EventOccurence

  • Key: UML14-503
  • Legacy Issue Number: 6980
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    There are multiple places in the Interaction section, where class name EventOccurence is spelt incorrectly (usually as Eventoccurence).

    pages 403 410 411 416 417 419 420 422 427 429 431

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

text differs from metamodel for critical region InteractionOperator

  • Key: UML14-508
  • Legacy Issue Number: 6985
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    On page 411 subsection for Critical Region mentions the InteractionOperator "critical", while the metamodel uses the enum "region".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 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 ( Dr. 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 ( Dr. 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

Ambuiguity in value pin evaluation

  • Key: UML14-462
  • Legacy Issue Number: 6865
  • Status: closed  
  • Source: NIST ( Mr. 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

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

  • Key: UML14-468
  • Legacy Issue Number: 6873
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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 ( Dr. 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 / Activities / subsetting two properties

  • Key: UML14-458
  • Legacy Issue Number: 6680
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

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

UML 2 Super / state machines / oclIsKindOf arguments error

  • Key: UML14-464
  • Legacy Issue Number: 6869
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

UML2 Super/Signal

  • Key: UML14-459
  • Legacy Issue Number: 6690
  • Status: closed  
  • Source: The MathWorks ( Mr. 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/State machines/pseudostate name consistency

  • Key: UML14-463
  • Legacy Issue Number: 6868
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

UML 2 Super / use cases / invalid subsetting

  • Key: UML14-469
  • Legacy Issue Number: 6874
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. 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

ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2

  • Key: UML14-366
  • Legacy Issue Number: 6427
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: In the definition of Connector in Chapter 3, Composite Structures, p.
    137, the "end" Association's multiplicity is 2..*. It is not clear what the
    notation should be when the multiplicity is greater than 2.

    Recommendation: Define a notation for Connectors when multiplicity is
    greater than 2, or constrain the multiplicity to be 2..2.

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

    No Data Available

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

ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation

  • Key: UML14-365
  • Legacy Issue Number: 6426
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 118: The figure caption
    says that the figure is an example of connector wiring, but the text
    directly below the caption says that the figure "may be used as a notation
    option for dependency based wiring." These two statements appear to be
    contradictory.

    Recommendation: To avoid having an ambiguous notation, specify that
    dependency notation should be used for dependency based wiring. (This
    recommendation may be affected by the resolution of the issue submitted
    about semantic distinctions between different ways to wire components
    together).

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

    No Data Available

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

ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics

  • Key: UML14-367
  • Legacy Issue Number: 6428
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Connector in Chapter 3, Composite Structures,
    third paragraph of the Semantics section, which starts on p. 137 with "If
    the type of the connector is ommitted...": This paragraph is inpenetrable.

    Recommendation: Re-write the section around concrete examples for each
    point.

  • Reported: UML 1.5 — Tue, 4 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 Infras./Interactions/ execution occurrence should not be abstract

  • Key: UML14-364
  • Legacy Issue Number: 6425
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ExecutionOccurrence should not be abstract, as it has no specializations

  • Reported: UML 1.5 — Tue, 4 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-219
  • Legacy Issue Number: 6162
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On the Description of complete activities: :Edges support controlling
    token flow and be contained in interruptible regions."

    "It covers invocation nodes, control nodes (...)". I believe it should
    read "It covers executable nodes, control nodes (...)"

    "A control flow is an edge starts an activity node after the previous
    one is finished."

    "The input parameter must be the same as or a supertype the type of
    object token coming along the incoming edge."

    "This is equivalent interposing a CentralBufferNode between the initial
    node and its outgoing edges."

    "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.

    Add constraint numbers to ExceptionHandler.

    In ActivityNode, the entry for interuptibleRegion should be under a
    heading Associations (CompleteActivities).

    In semantics of ActivityEdge move sentence about guards from
    (IntermediateActivities) to basic.

    "in invoked" => "is invoked"

    Constraint 5 for ActivityParameterNode should read: "Activity parameter
    object nodes with no outgoing edges and one or more incoming edges must
    have a parameter with out, inout, or return direction."

    Text should list mustIsoloate under StructuredActivityNode, not
    ActivtyNode.

    Local pre/postcondition semantics: "must" => should.

    Local pre/postcondition semantics: "locaprecondition" =>
    "localPrecondition".

    Semantics of streaming parameter, third bullet/execution rule: replace
    "activity" with "behavior". Also in second bullet, remove "for" from
    "that is, for all". Also add analogous sentence after "not just at the
    beginning" for outputs.

    Search on "wil exist", replace with "will exist".

    Search on "(str-adv)" and remove.

    In ConditionalNode: "the modeler asserts that at least one true section
    will yield a true value." Should be "test section".

    IsReadOnly is in basic activities in the metamodel diagrams, but should
    be in complete, according to the attribute list on Activities.

    In ReclassifyObjectAction and elsewhere, replace "error" with "undefined
    semantics".

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

    see above

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

7.4.1 Multiplicity

  • Key: UML14-225
  • Legacy Issue Number: 6169
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Options

    The BNF for the syntax for the multiplicity string seems to have a couple of things wrong. First, the 'lower' is specified as an 'integer' whereas it is specified to be unlimited natural from Notation part. Second, it does not allow for multiplicities to include a uniqueness designation. The first sentence defining the 'multiplicity' non-terminal only contains <order_designator> and does not include <uniqueness-designator>. Also, if both a uniqueness designation and order designation are specified the BNF should probably specify a delimiter (as in Figure 11). Perhaps the following:

    multiplicity ::= <multiplicity_range> [ '{' <order_designator> | <uniqueness_designator> |

    {<order_designator> ',' <uniqueness_designator>}

    '}' ]

    In addition, the multiplicity specification for Purchase is different between Figure 11 and 12, the former uses a comma to separate ordered and unique and the latter seems to be missing the comma.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

7.3.1 ElementImport

  • Key: UML14-224
  • Legacy Issue Number: 6168
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The next to last sentence states: "A member may be further imported by other namespaces using element or member imports." What are member imports? Should this be package imports?

    Notation

    The difference between public import using <<import>> and private import using <<access>> is not explicitly stated, nor is an example of <<access>> given in the Examples part. My understanding is that <<import>> adds an element to importing namespace using public visibility, i.e., the imported element can be accessed without qualification within the importing namespace and any namespace the importing namespace encloses. My understanding of <<access>> is that it adds an element to the importing namespace using private visibility which does not allow the imported element to be further imported. Does the last sentence of the Description, "It is also possible to control whether the imported element can be further imported", refer to <<access>> element import?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Clarify that profiles can contain model libraries

  • Key: UML14-218
  • Legacy Issue Number: 6161
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of <<modelLibrary>> says it is:

    A package that contains model elements which are intended
    to be reused by other packages. A model library differs from
    a profile in that a model library does not extend the
    metamodel using stereotypes and tagged definitions. A
    model library is analogous to a class library in some
    programming languages.

    However, profiles can contain model libraries. UML 1.x has an explicit
    dependency to model this (called <<modelLibrary>> also). It should be
    clarified that in 2.0 this is done by including model library pacakages
    in profile packages. The above text should be clarified. Suggestion:

    A package that contains model elements which are intended to be
    reused by other packages. A model library can be contained in a
    profile package, but the classes in a model library are not
    stereotypes stereotypes and tagged definitions extending the
    metamodel. A model library is analogous to a class library in some
    programming languages.

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

    see above

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

Notation for anonymous instance

  • Key: UML14-217
  • Legacy Issue Number: 6160
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the notation for anonymous instance

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

    see below

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

UML Superstructure 03-08-02: Loop node notation missing

  • Key: UML14-221
  • Legacy Issue Number: 6165
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the loop node on page 341 is missing.
    I saw the notation in an older version of the specification

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

    Same as Issue 6071

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

UML Superstructure: 03-08-02 -- typos

  • Key: UML14-220
  • Legacy Issue Number: 6164
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 32, 2nd/3rd semantics paragraph
    "element" instead of "ele-ment" (twice)
    "qualified" instead of "qual-ified"

    p.38, presentation options:
    "identifies" instead of "identi-fies"

    p. 108, fig. 53:
    "<<dependencyName>>" instead of "<<dependecyName>>"

    p. 109, fig. 54:
    "An example of a instantiate dependency" instead of "An example of a instantiatedependency"

    p. 110, Description:
    First and second paragraph are the same.

    p. 114, 3rd line:
    "...mapping to a property of..." instead of "...mapping to a propertyof..."

    p. 117, fig. 65:
    Class name is "DoorBell" instead of "oorBell"

    p. 137, last paragraph, first line:
    "...by a component that offers equivalent..." instead of "...by a component that offers that offers equivalent..."

    p. 170, first line:
    "...while the figure on the right..." instead of "...while the figure onj the right..."

    p. 172, semantics paragraph:
    Reference to ""StructuredClassifier" on page 171" seems to be wrong (twice)

    p. 325, stream description:
    "..., in order of..." instead of "..., in oprder of..."

    p. 403, last but one paragraph:
    "...UML language..." instead of "...UML languatge..."

    p. 537, PrimitiveTypes, first paragraph:
    "These include primitive types..." instead of "These includes prmitive types..."

    p. 587, paragraph below fig. 460, last line:
    "..., the heading is..." instead of "..., the headning is..."

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

    see above

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

Notation for attributes

  • Key: UML14-215
  • Legacy Issue Number: 6158
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The notation for attributes is given in Kernel::Classifier, but the
    abstract syntax for classifiers have no features

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

    No Data Available

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

Property string undefined

  • Key: UML14-214
  • Legacy Issue Number: 6157
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The BNF for property-string is missing in Property and Operation. Eg,
    how are the properties delimited (a comma?)? How are property values
    shown (property-name property-value)?

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

    see above

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

InstanceSpecification

  • Key: UML14-226
  • Legacy Issue Number: 6170
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    The first paragraph indicates that both the instance name and the classifier can be omitted from an instance specification. This informal description leads open the possibility of specifying just the colon with neither the instance name nor the classifier. Is this what is intended? BNF should be used to clarify.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a more detailed version of Issue 6160.

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

Instantiates stereotype

  • Key: UML14-216
  • Legacy Issue Number: 6159
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 54 (An example of a instantiatedependency) shows the instantiates
    stereotype/keyword being used as an instance-of relation, whereas the
    entry for the instantiates stereotype in the standard stereotypes table
    says "A usage dependency among classifiers indicating that the
    operations on the client create instances of the supplier".

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

    see above

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

No notation defined for suppressing attributes or operations

  • Key: UML14-223
  • Legacy Issue Number: 6167
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    There is a mention that attributes and operations may be supressed for clarity, but no mention as to how. In UML 1.4 this was shown by including '...' in the compartment, to indicate that there was more information. Is this still viable?

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

    see above

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

Notation mismatch for the realization dependency

  • Key: UML14-222
  • Legacy Issue Number: 6166
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the realization dependency is described on p. 110:
    "A Realization dependency is shown as a dependency with the keyword <<realize>>
    attached to it."

    On p. 130 the Realization dependency is shown as a dashed line with
    a hollow triangle as an arrowhead.

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

    see above

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

Parameter set corrections 3

  • Key: UML14-177
  • Legacy Issue Number: 6117
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Examples are incorrect in implying that parameter sets can replace
    merges. They are separate parameters, not a single input as would come
    from a merge.

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

    see above

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

Streaming

  • Key: UML14-181
  • Legacy Issue Number: 6121
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Separate streaming from optionality and multiple tokens being input or
    output during action execution.

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

    see above

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

Parameter set corrections 6

  • Key: UML14-180
  • Legacy Issue Number: 6120
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that semantics for paramater sets on operations is the same as
    for behaviors.

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

    see above

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

Parameter set corrections 5

  • Key: UML14-179
  • Legacy Issue Number: 6119
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Rule 2 for parameter sets conflicts with nonoptional inputs: "If a
    behavior has input parameters that are in a parameter set, then any
    inputs that are not in a parameter set must be streaming. Same for
    output parameters." Just disallow parameters not in parameter sets in
    the presence of parameter sets. Since parameters be in more than one
    set, there is no need for parameters out of a set in this case

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

    No Data Available

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

Parameter set corrections 4

  • Key: UML14-178
  • Legacy Issue Number: 6118
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are parameter sets notated in classes? Parameter sets can be
    referred to by their names.

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

    No Data Available

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

Outgoing edges of initial nodes

  • Key: UML14-332
  • Legacy Issue Number: 6358
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint on initial nodes that its outgoing edges can only be
    control.

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

    see above

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

Port is a Property in XMI

  • Key: UML14-331
  • Legacy Issue Number: 6357
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Port is a Property in the XMI, but not in the spec. This is because in
    MDL file Port is a Property, but it is only visible in the object
    browser. It was only hidden from the diagrams instead of being deleted.
    U2P internal history live on. Search on name="Port"

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

    Duplicate of 6281.

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

InformationFlow realization

  • Key: UML14-326
  • Legacy Issue Number: 6351
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    InformationFlow realization should be to more than relationships. It
    could be to any set of elements

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

    see above

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

Dependency multiplicity to CollaborationOccurrence

  • Key: UML14-325
  • Legacy Issue Number: 6350
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Figure 100 says Dependency must be in exactly one
    CollaborationOccurrence. Presumably there are dependencies that are not
    in collaboration occurrences

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

    The multiplicity of the end at CollaborationOccurrence should be changed to “0..1”.

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

Ports as properties

  • Key: UML14-330
  • Legacy Issue Number: 6356
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Ports should be properties (better yet parts), to participate in
    composite association when desired.

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

    see above

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

partWithPort without ports

  • Key: UML14-329
  • Legacy Issue Number: 6355
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Seems like partWithPort should be able to connect parts of parts without
    needing to use ports. Just use partWithPort to part, connectorEnd to
    part of part. Loosen constraint 2 of ConnectorEnd to allow all parts

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

    Duplicate of 6251.

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

Control pins

  • Key: UML14-323
  • Legacy Issue Number: 6348
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There should be a special kind of pin for control tokens. This will
    allow parameter sets to be used with control, for example. Also
    resolves issue of where control is bufferred when it is direceted at a
    join. Can be implemented as a pin that has no parameter, by making them
    the last in the ordering of pins, so no parameter corresponds to them.
    This is also a request of the SysML team.

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

    see above

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

Profiles in fixed repositories

  • Key: UML14-322
  • Legacy Issue Number: 6347
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Do profiles working for fixed repositories in UML 2? My understanding
    is that they are at M3 now, so they wouldn't. If that's the case, then
    what is their purpose? The other feature of dynamically changing
    metaclasses is something a repository could provide if it was useful,
    instead of using stereotypes.

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

    see above

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

Association end names and part types

  • Key: UML14-328
  • Legacy Issue Number: 6354
  • Status: closed  
  • Source: MITRE ( Dr. Bruce Powel Douglass)
  • Summary:

    In the notation of composite structure, are association end names
    allowed to be presented on connectors? If so, how are they
    distinguished from port type?

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

    No Data Available

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

Deployment location

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

    In Deployments, the spec uses "location" as an association end name, but
    "node" in MDL file.

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

    see above

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

Guards on initial nodes

  • Key: UML14-333
  • Legacy Issue Number: 6359
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Carify whether guards can be used at initial nodes.

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

    see above

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

Control at joins

  • Key: UML14-324
  • Legacy Issue Number: 6349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Where are control nodes buffered when directing control to a join?

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

    see above

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

7.11.2 Association

  • Key: UML14-228
  • Legacy Issue Number: 6172
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    I cannot find where the hollow diamond notation for aggregation is specified. It is shown in Table 5 but specified in the body. Is this now called 'shared' aggregation?

    The second to last sentence states;" The notation for an attribute can be applied to a navigable association end name." By full notation is it meant the full attribute syntax specified in section 7.81. Classifier under Notation part can be used? This would allow redundant specification of multiplicity. Should it be stated that if attribute notation is used, then other types of association end adornments cannot be used?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

7.10.1 Operation

  • Key: UML14-227
  • Legacy Issue Number: 6171
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Semantics

    The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added).

    Notation

    BNF should be used for specifying the syntax of an operation string.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Metamodel::IntermediateActivities/redundant merge error

  • Key: UML14-234
  • Legacy Issue Number: 6179
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

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

    see above

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

BehaviorStateMachines/missing owningState end name

  • Key: UML14-233
  • Legacy Issue Number: 6178
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BehaviorStateMachines has association :State[0..1] c-> stateInvariant: Kernel::Constraint[0..1] is missing the owningState end name as defined in ProtocolStateMachines owningState:State[0..1] c-> stateInvariant: Kernel::Constraint[0..1]

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

    see above

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

UML 2 Super/Metamodel::Kernel::DataTypes/missing renames

  • Key: UML14-238
  • Legacy Issue Number: 6183
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else.

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

    see above

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

AuxiliaryConstructs::Templates::Operation/extra space

  • Key: UML14-237
  • Legacy Issue Number: 6182
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::AuxiliaryConstructs::Templates::Operation had a space at the end of the class name. This causes some matching algorithms to fail

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

    see above

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

UML 2 Super/Metamodel::BasicBehaviors/package merge issue

  • Key: UML14-232
  • Legacy Issue Number: 6177
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model

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

    No Data Available

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

7.15.3 Interface

  • Key: UML14-231
  • Legacy Issue Number: 6175
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Option

    In Figure 62 the relationship between TheftAlarm and ISensor should be a dependency relationship (dashed arrow) with the <<use>> stereotype rather than a unidirectional association. The relationship between ProximitySensor and ISensor should be an implementation relationship (probably same as realization consisting of dashed arrow with open arrowhead) rather than a generalization relationship (Table 5).

    Figure 63 shows attribute visibility notation for non-navigable association ends. The second from last sentence in section 7.11.2 Association under the Notation part indicates that attribute notation can only be applied to a navigable association end name.

  • Reported: UML 1.5 — Wed, 3 Sep 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/Metamodel::Communications/redundant merge error

  • Key: UML14-235
  • Legacy Issue Number: 6180
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: IntermediateActivities should not merge both StructuredActivities and BasicActivities as StructuredActivities already merges BasicActivities. IntermediateActivities both merges BasicActivities and explicitly references types in it (:Clause[0..1] -> decider:BasicActivities::OutputPin[0..1]). This makes resolving the type reference for association end named decider ambiguous

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

    Duplicate of 7436

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

7.14.1 Abstraction

  • Key: UML14-229
  • Legacy Issue Number: 6173
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Examples

    The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Metamodel::Nodes/redundant merge error

  • Key: UML14-236
  • Legacy Issue Number: 6181
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

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

    see above

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

7.14.6 Realization

  • Key: UML14-230
  • Legacy Issue Number: 6174
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The notation of a dashed arrow with hollow arrow head at the supplier is not mentioned. However, Table 5 shows this notation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

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

Pins on structured nodes 2

  • Key: UML14-195
  • Legacy Issue Number: 6136
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Is it really intended that all StructuredActivityNode's have pins, such
    as ExpansionRegions?

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

    No Data Available

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

Pins on structured nodes 1

  • Key: UML14-194
  • Legacy Issue Number: 6135
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 193 - Structured nodes (CompleteStructuredActivities) shows
    StructuredActivityNode, LoopNode, and ConditionalNode inheriting from
    Action, but LoopNode and ConditionalNode already inherit from
    StructuredActivityNode (Figure 192 - Structured nodes).

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

    see above

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

Action packaging

  • Key: UML14-203
  • Legacy Issue Number: 6145
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Structured actions should depend on structured activities for
    variables. In general, actions should be in smaller packages to

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

    see above

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

BroadcastSignalAction

  • Key: UML14-202
  • Legacy Issue Number: 6144
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether BroadcastSignalAction returns after the signals are sent
    or after they are received.

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

    see above

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

Time spec text

  • Key: UML14-196
  • Legacy Issue Number: 6138
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The overview of Activity says: "The UML does not provide for the
    specification of a time metric, but only describes sequences of
    executions.", but UML does have a time model that can be applied to
    activities. Remove sentence.

    It also says: "Execution is not instantaneous, but takes place over a
    period of time." Seems like activities should be agnostic on this.

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

    see above

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

Update actions for isUnique

  • Key: UML14-200
  • Legacy Issue Number: 6142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Update structural feature and associations actions for isUnique. For
    example, the semantics description of the class
    AddStructuralFeatureValueAction says: "Reinserting an existing value at
    a new position moves the value to that position (this works because
    structural feature values are sets)".

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

    see above

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

ExpansionRegion

  • Key: UML14-193
  • Legacy Issue Number: 6134
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why does ExpansionRegion have its own input/output metaassociations,
    rather than the ones on actions? (BTW, these associations are
    misnomers, they are not just elements). ExpansionRegion inherites pins
    from StructuredActivityNode in complete activities

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

    No Data Available

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

Partition semantics

  • Key: UML14-197
  • Legacy Issue Number: 6139
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that behaviors outside of actions, such as on decision nodes,
    guards, etc, that are contained in a partition, have the same semantics
    as behaviors invoked by actions.

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

    see above

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

Activity frame and parameter nodes 1

  • Key: UML14-198
  • Legacy Issue Number: 6140
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An object node with no input or no output notation should map to an
    ActivityParameterNode, so that frame isn't required.

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

    see above

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

actions on properties that are association ends

  • Key: UML14-201
  • Legacy Issue Number: 6143
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Clarify semantics for (or lack thereof) for modifying properties that
    are association ends

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

    see above

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

Activity frame and parameter nodes 2

  • Key: UML14-199
  • Legacy Issue Number: 6141
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter nodes can overlap frame as defined in the
    diagram appendix.

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

    see above

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

Flows across SAN boundaries

  • Key: UML14-347
  • Legacy Issue Number: 6375
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify that control and object flows can cross SructuredActivityNode
    boundaries (we need this).

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

    see above

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

Initial nodes in structured actions

  • Key: UML14-346
  • Legacy Issue Number: 6374
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify whether structured actions can have initial nodes

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

    see above

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

Parameters in Features and Common Behavior

  • Key: UML14-345
  • Legacy Issue Number: 6373
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Features model (Figure 28) shows BehavioralFeature with the
    parameter association presumably derived from formalParameter and
    returnResult, whereas the Common Behavior model (Figure 312) shows
    Behavior formalParameter and returnResult derived, derived from the
    parameter association. These parameter models for operations and
    behavior should be the same.

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

    see above

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

Clarify join specs referencing control flow edges

  • Key: UML14-342
  • Legacy Issue Number: 6369
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that join specs reference to control flow edge names as being
    boolean.

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

    No Data Available

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

Combining joined tokens

  • Key: UML14-341
  • Legacy Issue Number: 6367
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Join nodes should have an option to combine tokens with identical
    values. For example, when joining flows created by a fork duplicating
    tokens.

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

    see above

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

AcceptCallAction in SAN

  • Key: UML14-349
  • Legacy Issue Number: 6377
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    What is the behavior when a SAN contains an AcceptCallAction with no
    incoming control links. Is the accept only enabled once when the SAN
    receives a control token, or it it enabled for the lifetime of the SAN?
    Either way, how do you model the other behavior.

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

    see above

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

Terminating a SAN

  • Key: UML14-348
  • Legacy Issue Number: 6376
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    How do you end a SructuredActivityNode in the way that an
    ActivityFinalNode ends an Activity?

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

    see above

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

Join example

  • Key: UML14-344
  • Legacy Issue Number: 6371
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The example for join, Figure 263, doesn't make sense from a domain point
    of view. Orders aren't accepted and shipped concurrently.

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

    see above

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

Clarify join rules

  • Key: UML14-343
  • Legacy Issue Number: 6370
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that a successful non-and join spec still combines the incoming
    tokens by the same rules as "and".

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

    No Data Available

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

Side effects of value specifications

  • Key: UML14-336
  • Legacy Issue Number: 6362
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether guards and other value specification can have side
    effects

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

    No Data Available

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

Activity final clarification

  • Key: UML14-335
  • Legacy Issue Number: 6361
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the effect of an activity final node when only some of the
    non-streaming output parameters have tokens.

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

    see above

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

ReadSelfAction with no host

  • Key: UML14-339
  • Legacy Issue Number: 6365
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Extend ReadSelfAction to return behavior object if there is no host.

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

    see above

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

Decision behaviors on control tokens

  • Key: UML14-338
  • Legacy Issue Number: 6364
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that decision behaviors work on control tokens. Suggest that
    control tokens invoke behaviors with no input parameters. Behavior can
    use ReadSelfAction to access host if necessary

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

    see above

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

Clarify ReadSelfAction in activity behaviors

  • Key: UML14-340
  • Legacy Issue Number: 6366
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the semantics of ReadSelfAction for behaviors used in activities
    (decision input, etc).

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

    see above

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

Guard evaluation

  • Key: UML14-337
  • Legacy Issue Number: 6363
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that not all the guards are required to be evaluated, only that
    one succeed (expand on race condition sentence).

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

    see above

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

Caption typo

  • Key: UML14-334
  • Legacy Issue Number: 6360
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Caption to Figure 251 (Final node example) should be flow final
    example

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

    see above

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

Confusion regarding XMI for use of stereotypes

  • Key: UML14-291
  • Legacy Issue Number: 6242
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I've been looking at Figure 458 and can't quite get it, but don't know if
    it's an issue -the problem I have is that the instance model seems to mix
    meta-levels; we have an instance of the UML (meta) class, Class and an
    instance of the user stereotype(class) Clock - yet on the diagram this jump
    in metalevels is not mentioned. I can't see how this can be the true
    Instance model. Could someone provide me with the XMI fragment that this
    figure is intended to produce - I think that this would give me more of a
    clue about what's going on.

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Actors that are outside and inside the system

  • Key: UML14-290
  • Legacy Issue Number: 6241
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a fundamental problem with the Actor element.
    It is defined as
    "An Actor models a type of role played by an entity that interacts with the subject
    (e.g., by exchanging signals and data), but which is external to the subject."

    Now put your modeling focus on a subsystem. Use cases of that subsystem can have
    external subsystems as actors. Let A be an actor of a use case. A is an external subsystem.

    But now put your modeling focus on the whole system. Now A isn't an actor anymore, but
    a subsystem. The same "real world" entity is defined twice in my model: as an actor and
    as a subsystem. It depends on my modeling focus, but that's more a topic of the view and
    not of the model.

    The problem is common in business process modeling. In the BPM view a employee is a
    stereotyped class, e.g. business worker. In the system analysis view (for a system
    that should support parts of my business processes) the employee is an actor of the system.

    We solved that problem by not using actors, but stereotyped classes. But I'm not feel
    happy with that solution, because it just a workaround.

    Any ideas?

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

    No Data Available

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

UML2 super/pgs.17 + 598/"topLevel"

  • Key: UML14-289
  • Legacy Issue Number: 6240
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Subject: topLevel standard stereotype is referred to on pg 17 and retired on pg 598.

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

    Remove the complete entry for “top level” in the Glossary.

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

Actor

  • Key: UML14-288
  • Legacy Issue Number: 6239
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Three sentences define actor differently. One of these (or a fourth) shold be chosen.

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

    see above

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

Multiplicity of Regions owning Transitions

  • Key: UML14-287
  • Legacy Issue Number: 6238
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    The multiplicity of Regions owning Transitions shall be changed from 0..1 to 1, as Transitions can only be owned by Regions

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

State list

  • Key: UML14-286
  • Legacy Issue Number: 6237
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Statelist has to be done differently, as transitions outgoing from a junction point cannot have triggers

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2.0 serious layout problems with activity diagrams

  • Key: UML14-285
  • Legacy Issue Number: 6236
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In UML 1.x you can draw several outgoing transitions from an action state
    with guard conditions. That's semantically equivalent to a decision.
    The semantic changes in UML 2.0. Several outgoing edges from an action node
    are semantically equivalent to a fork. The new semantic is absolutely ok,
    but I have problems with the notation.

    Especially in business process modelling it is common that a decision
    follows each action. Now I have to draw a decision node after each action
    node. That blows up the diagrams and makes them hard to read. With UML 2 I
    need two pages for a diagram that fits on half a page with UML 1.x.

    Is it possible to use a notational shortcut to keep the diagrams small and
    readable?
    I heard from several people that they think about workarounds for that problem.
    But I think that's the wrong way.

    Any solutions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Stereotypes for Actions

  • Key: UML14-284
  • Legacy Issue Number: 6235
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I just recognized a change in UML 2.0 from UML 1.x.
    Stereotypes can only be attached to elements derived
    from Class. In UML 1.x a stereotype can be attached to
    elements based on ModelElement.

    Does that mean that I cannot define a stereotype for Actions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6199

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

UML Superstructure: 03-08-02 / Typos

  • Key: UML14-283
  • Legacy Issue Number: 6234
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some more typos:

    p. 191, figure 134
    Figure 134 does not show a deployment specification.

    p. 194, Manifestation
    "A manifestation is the concrete physical unit of one..." instead of "A manifestation is the concrete physical of one..."

    p. 200, table 9
    The manifestation relationship is shown with a solid line. Notation definition on p. 195 specifies a dashed line.

    p. 228, Presentation Option, last line
    "...than the operation name,..." instead of "...than the operaiton name,..."

    p. 233, CreateObjectAction
    The definition is not quite clear. The first constraint says "The classifier cannot be abstract". But
    the description says "The semantics is undefined for creating objects from abstract classifiers."
    The last one means that abstract classifiers are allowed, but the semantic is undefined. So the constraint
    is wrong. On the other hand if the constraint is correct, the sentence about the abstract classifier
    is suerfluous.

    p. 259, TestIdentifyAction, first line
    "...are identical objects." instead of "...are identical objects.t"

    p.286, 3rd paragraph from bottom
    "An activity with a classifier context..." instead of "An activity with a a classifier context..."

    p. 304, Semantics, first line
    "When an activity is invoked,.." instead of "When an activity in invoked,..."

    p. 355, Examples
    "The diagram on the left uses a decision diamond; the one on the left uses parameter sets
    to express the same notion".
    Text refers twice to the diagram on the left. The figure 279 does not show what the text describes.

    p. 473, below figure 373
    "A choice pseudostate is shown as a diamond-shape symbol as exemplified by Figure 374".
    Fig. 374 does not show a diamond-shape symbol, but the circle notation.

    p. 497, Rationale below figure 394
    "The rationale for statemachine extension..." instead of "The rationale for statemachie extension..."

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/Compliance points/confusing and redundant

  • Key: UML14-282
  • Legacy Issue Number: 6233
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain:

    There is no facility provided to indicate which particular compliance points are assumed in a given model – hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard.
    The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java.
    Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant.

    This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?).

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

    This is a duplicate of issue 6248.

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

UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition

  • Key: UML14-281
  • Legacy Issue Number: 6232
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 81: Association: subsetting, generalization, redefining: Just what is the precise difference among subsetting, specialization, and redefining? The explanations are vague and don't offer distinctions or examples showing the difference. They seem to do the same thing. If there is no semantic difference, why do we have them all? This is an important thing to clarify, preferably with examples for each of the possibilities. Other people are confused about this too.

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

    see above

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

UML 2 Super/pg.379/anyTrigger clarifications

  • Key: UML14-280
  • Legacy Issue Number: 6231
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 379: AnyTrigger: It is obviously illegal to have 2 anyTriggers in the same state (but the specification should say that, which it doesn't). What about multiple anyTriggers in nested states? The specification is silent on this point. It should probably be allowed with the most specific state taking precedence. This is a useful situation. Need to define it in any case.

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

    see above

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

UML 2 Super/pg. 556/notation for template binding inconsistency

  • Key: UML14-279
  • Legacy Issue Number: 6230
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 556: Classifier (in templates): Bound collaboration (Fig. 435): Separator should be arrow (->) not backslash () to be consistent with text on TemplateBinding on pg. 548

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

    see above

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

UML 2 Super/pg. 471/choice pseudostate notation

  • Key: UML14-278
  • Legacy Issue Number: 6229
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoState/Semanctics Choice – The text says the symbol is a diamond but the figure 374 on pg. 473 shows a circle. Probably an error in the figure but make them consistent. In UML1 it is a diamond so a circle would be a bad idea

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

    see above

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

UML 2 Super/pg.471/unclear terminate state semantics

  • Key: UML14-277
  • Legacy Issue Number: 6228
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoStatel/Semancis terminate – What are the semantics of terminate? Are exit actions performed (to return to the root state) or is the object just killed outright with no clear up? Probably need a SVP. In any case, the wording is too spare. It isn't very useful as it stands with vague semantics.

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

    see above

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

UML 2 Super/pg.519/multiplicity semantics of use case associations

  • Key: UML14-276
  • Legacy Issue Number: 6227
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 519: UseCase – semantics of multiplicity on Actor-UseCase association not explained. State what the multiplicity means and show an example

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

    see above

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

Question about InterruptibleActivityRegion

  • Key: UML14-295
  • Legacy Issue Number: 6247
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I am not sure about the semantics of the InterruptibleActivityRegion.

    If I have such a region with an Accept Event Action to wait for an
    event to terminate the region, what happens if there is no token
    flow within the region, but the event occurs?

    I think the Accept Event Action is active. I did not found another
    statement in the specification. That means that all outgoing
    egdes get tokens after event occurence.

    Normally that is not the semantic the modeler wants. Nothing should happen
    if there is no token flow in the activity region.

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

    see above

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

fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <

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

    medium significance

    The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities.

    This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs."

    This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction. Yet the Figure 175 says otherwise

    Suggested resolution:

    The root of this problem may be:

    a. Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed.
    b. In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages." It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages. This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages" is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction.
    c. Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two. This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept.

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

    No Data Available

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

Metamodel for applying a stereotype

  • Key: UML14-293
  • Legacy Issue Number: 6244
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What part of the metamodel is for applying a stereotype to a single
    element in a user model? I can only find the appliedProfile association
    for applying profiles to packages. Figure 458 shows a repository model
    for it, but doesn't give the name of the relation between a class and
    the Clock stereotype.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the solution to issue 6347.

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

Association not affecting ends

  • Key: UML14-292
  • Legacy Issue Number: 6243
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Restore UML 1.x capability of modeling associations without modifying
    the end types. This is needed for database modeling, for profiles to be
    used with fixed-schema repositories, and is the differentiator of UML
    over OWL, etc.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/pg.427/missing notation description for lifelines

  • Key: UML14-275
  • Legacy Issue Number: 6226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 427: Lifeline/Notation—need to add text stating that multiple activation rectangles (overlapped and offset) may be used to represent recursion. This shows in some examples but not in the text.

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

    see above

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

UML 2 Super/pg.429/incorrect constraint for Message

  • Key: UML14-274
  • Legacy Issue Number: 6225
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 429: Message/Constraint 5: It says that relations sendEvent and receiveEvent are mutually exclusive. The rest of the entry suggests that they are normally both present. The constraint appears erroneous

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

    see above

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

UML 2 Super/pg.416/incorrect multiplicities for event occurrence

  • Key: UML14-273
  • Legacy Issue Number: 6224
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 416: Associations EventOccurrence::startExec and finishExec should have multiplicity * as in figure 328 on pg.407

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

    see above

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

UML 2 Super/pg.395/multiple meaning of exception

  • Key: UML14-272
  • Legacy Issue Number: 6223
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue.

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

    see above

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

UML 2 Super/pg.235/missing semantics of destroy action

  • Key: UML14-271
  • Legacy Issue Number: 6222
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 235: DestroyAction: Must destroy links involving the object, at least, as they no longer have valid referents after the destruction. This is needed even if parts are not destroyed automatically. It is part of the essential semantics of links and objects, not an optional semantic variation point (as automatic part destruction is).

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

    see above

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

UML 2 Super/pg.130/incorrect stereotype name

  • Key: UML14-270
  • Legacy Issue Number: 6221
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: – private package import shown as «use» in chart, but should be «access» according to previous text for private import

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

    see above

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

UML 2 Super/pg.109/Permission redundant

  • Key: UML14-267
  • Legacy Issue Number: 6218
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 109: Permission – this used to be a superclass of access and import. Doesn't serve a useful purpose otherwise. It now seems to be a useless relict. Get rid of it. There is no need to give "permission" to access another element—the fact of the access itself means that you meant to do it. Giving "permission" is more of a tool thing to prevent errors, not a modeling thing. In any case, it now seems obsolete.

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

    see above

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

UML 2 Super/pg.64/Classifier redefinition notation

  • Key: UML14-265
  • Legacy Issue Number: 6215
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a <redefines> statement

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

    see above

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

UML 2 Super/pg.95/attributes in data types clarification

  • Key: UML14-266
  • Legacy Issue Number: 6217
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 95: DataType::ownedAttribute – is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example

  • Reported: UML 1.5 — Sun, 7 Sep 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/pg.99/misnamed "packageMerge" attribute

  • Key: UML14-268
  • Legacy Issue Number: 6219
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 99: Packages Diagram – association to PackageMerge should be called packageMerge, not packageExtension (as in text on pg. 100)

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

    This is addressed by the proposed resolution to Issue 6190

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

UML 2 Super/pg.130/missing notation explanation

  • Key: UML14-269
  • Legacy Issue Number: 6220
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: Realization/Notation –dashed generalization notation is not mentioned, but it is shown in the chart on pg. 130. Add it to the text

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

    see above

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

UML 2 Super/pg.79/underlined operation syntax missing

  • Key: UML14-264
  • Legacy Issue Number: 6214
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 79 Operation/Notation: Syntax for operation does not show underlining but example does show it.

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

    No Data Available

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

PackageMerge (from Kernel)

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

    A package merge defines how one package extends another package by merging their contents.

    Description

    A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable.

    This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions.

    It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified."

    The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set.

    This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with .

    This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name."

    Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards .

    A reductio ad absurdum argument can be posed, as follows:

    Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2.

    Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1.

    If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2.

    Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T.

    Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source.

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

    see above

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

Sequence diagram conditions on Message arrows

  • Key: UML14-311
  • Legacy Issue Number: 6278
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Sequence diagrams in UML 1.x supported a conditional expression to a
    message arrow that was inadvertently omitted from the UML 2.0 Superstructure
    specification. This annotation enabled the modeler to – in essence –
    place guards on messages. Such guards, or more properly ConditionalActions,
    would be evaluated at run time to determine which message arrow(s) would be
    executed. In particular, the UML 1.5 Superstructure document specifies the
    following:

    -In Section 3.60.5.1: "Any condition ... expression attached to the arrow
    becomes, in a detailed action model, the test clause action in a
    ConditionalAction ... in the dispatching Procedure.

    -In section 3.63.2: "An arrow may also be labeled with a condition and/or
    iteration expression."

    -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single
    point, each possibly labeled by a condition. Depending on whether the
    conditions are mutually exclusive, the construct may represent
    conditionality or concurrency."

    -In 3.72.2.4: "A condition represents a Message whose execution is
    contingent on the truth of the condition clause. The condition-clause is
    meant to be expressed in pseudocode or an actual programming language; UML
    does not prescribe its format. An example would be: [x > y]."
    A "branch" condition, or ConditionalAction, is expressed in the form:
    Œ[¹ condition-clause Œ]¹

    Recommendation:

    The UML 2.0 Superstructure FTF team should determine how to reinstate
    ConditionalActions for Sequence Diagrams, given the new abstract syntax for
    Sequence Diagrams. There are two reasons for this:
    1) To maintain backward compatibility with UML 1.0 through 1.5 is important.
    2) Pragmatically, it offers a graphically simple technique to express
    messaging situations that involve branching. Granted, the ALT operation
    supports the equivalent notion; however, it comes with a graphical
    complexity that is not always desired.

    Discussion:

    {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't}
  • Reported: UML 1.5 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/Instances

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

    03-08-02.pdf

    In Figure 120, "l1", which I believe is an InstanceSpecification appears to
    be nested inside another (anonymous) InstanceSpecification, ":Car". However,
    looking at the metamodel for Instances, one InstanceSpecification cannot own
    another. So, in the repository for the diagram in Figure 120, which model
    element owns the InstanceSpecification "l1"? This is important because for
    example when it comes to delete ":Car" how does the repository know to
    delete "l1"?

  • Reported: UML 1.5 — Wed, 15 Oct 2003 04: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-318
  • Legacy Issue Number: 6316
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf:

    This from the descrciption of Ports(p169):
    "For a behavior port, the instance of the owning classifier will handle
    requests arriving at this port (as specified in the behavior
    of the classifier, see Chapter 13, "Common Behaviors"),"
    Is how this works a semantic variation point - if so then it should say so.

    IMO, the very least we should allow is that Port can participate in an
    Association so that its class can have an association end that points to its
    parent, and so can delegate behaviour appropriately

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

    No Data Available

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

Recommendation for InteractionOccurrences

  • Key: UML14-310
  • Legacy Issue Number: 6264
  • Status: closed  
  • Source: Northrop Grumman ( Brian Willard)
  • Summary:

    Recommend for InteractionOccurrences be equated to ActivityNodes of Activity
    Diagrams rather than ObjectNodes as currently specified. This spec
    reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447):

    Interaction Overview Diagrams are specialization of Activity Diagrams that
    represent Interactions Interaction Overview Diagrams differ from Activity
    Diagrams in some respects.
    1. In place of ObjectNodes of Activity Diagrams, Interaction Overview
    Diagrams can only have either (inline) Interactions or
    InteractionOccurrences. Inline Interaction diagrams and
    InteractionOccurrences are considered special forms of ActivityInvocations.

  • Reported: UML 1.5 — Fri, 26 Sep 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 / Interactions / No way to model reply messages

  • Key: UML14-309
  • Legacy Issue Number: 6263
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is no direct way to specify a "reply" message in the UML metamodel for Interactions – even though there is a notation for this concept (dashed arrow).

  • Reported: UML 1.5 — Fri, 26 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

description of Component on page 137

  • Key: UML14-321
  • Legacy Issue Number: 6338
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description of Component on page 137 says that the provided and required
    interface associations are derived both directly, from implement and use
    dependencies, and from realizing classifiers and owned ports. What isn't
    clear to me is whether the cup and ball notation can be used for all
    provided and required interfaces, or just for those directly implemented and
    used. If it can be used for all then it isn't clear whether you can
    distinguish between direct and derived interfaces. However, I note on Figure
    89 that /orderedItem is preceded by a slash - is that how the difference is
    notated?

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

    see above

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

Figure 61

  • Key: UML14-320
  • Legacy Issue Number: 6337
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 61 - shows a ball connected to a cup, but this notation is not shown
    in the Diagrams section (7.18). It's not clear whether this is actually an
    Assembly Connector, or some other concept. The spec should be clear on
    whether this is an additional notation or not.

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

    see above

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

UML2.super (or infra)/Profiles-Stereotype (18.3.7)

  • Key: UML14-313
  • Legacy Issue Number: 6280
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram
    customization mechanism

    This feature was supported in UML1.4 by an attribute called "icon:string".
    At the time of the design of the Profile metamodel for UML2.0, it has been
    argued this this was a mechanism to be treated by the diagram interchange
    proposal. To my knowledge, this is not the case, or if it is this is not
    eplained.
    This is at least a backward compatibility issue
    Two options can at least be envisaged :
    1 if that is supported by the global "2.0" specifications, explain in the
    profile chapter how
    2 introduce back this "icon:string" attribute. In that cas, thenotation
    ch^pter has to be extended to explain how this icon can be displayed, and
    how multiple stereotype can be handled.

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

    see above

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

UML 2 Super/Components & Deployment chapters missing OCL constraints

  • Key: UML14-317
  • Legacy Issue Number: 6315
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The constraints in the Component and Deployment chapters are expressed in verbal English. They should ideally also be represented in OCL

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

    see above

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

UML2 Super/Profiles

  • Key: UML14-316
  • Legacy Issue Number: 6310
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In figure 446, only packages that specialise Constructs::Package can contain
    a Profile Application. Whereas I think that the packages to which we need to
    apply profiles are those packages that specialise Kernel::Package

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML2 Super/Composite Structures

  • Key: UML14-314
  • Legacy Issue Number: 6281
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Divergence between XMI/MDL and the PDF/FM
    The XMI and MDL files for UML 2 super both state that Port is a subclass of
    Property and yet the appropriate diagram in the spec (fig 97) doesn't - this
    fragment of the adopted XMI spec illustrates the point:

    <ownedType xsi:type="cmof:Class"
    xmi:id="_UML_CompositeStructures_Ports_Port" name="Port"
    > > superClass="_UML_CompositeStructures_InternalStructures_Property
    > > _UML_CompositeStructures_InternalStructures_ConnectableElement
    > > _UML_Classes_Kernel_StructuralFeature">

  • Reported: UML 1.5 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The resolution of issue 6356 removes this problem.

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

UML Superstructur 03-08-02: Notation for ConditionalNode is missing

  • Key: UML14-308
  • Legacy Issue Number: 6261
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Notation and Presentation Options sections of
    the ConditionalNode are empty (p. 315).

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071 (Conditional Node and Loop Node notation missing

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

UML2 Super/Kernel::Classifier

  • Key: UML14-315
  • Legacy Issue Number: 6309
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 03-08-02.pdf, page 62, attribute should be /attribute

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 Super/pg.78/missing return types syntax

  • Key: UML14-263
  • Legacy Issue Number: 6213
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    78 Operation/Notation: Syntax for operation omits the return types

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

    This is the same as issue 5951 and has been solved by the resolution to issue 7315.

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

UML 2 Super/pg.78/operation redefinition

  • Key: UML14-262
  • Legacy Issue Number: 6212
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 78 Operation/Constraints: Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care.

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

    see above

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

UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements

  • Key: UML14-258
  • Legacy Issue Number: 6208
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Properties UseCase::extend and UseCase::include subset property Namespace::ownedMember, but classes Extend and Include are not types of NamedElement

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

    see above

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

UML 2 Super/Metamodel/missing namespaces for metaclasses

  • Key: UML14-257
  • Legacy Issue Number: 6207
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious namespaces:

    ActivityPartition
    ConnectionPointReference
    Duration
    InstanceValue
    Interval
    LiteralBoolean
    LiteralInteger
    LiteralNull
    LiteralString
    LiteralUnlimitedNatural
    OpaqueExpression
    Pesudostate
    State
    TimeExpression
    Transition

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

    see above

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

UML 2 Super/Metamodel/Mis-named Manifestation class

  • Key: UML14-254
  • Legacy Issue Number: 6204
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of class Manisfestation is misspelled; it should be "Manifestation"

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

    Correct the typo in figure 124 FAS.

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

UML 2 Super/Metamodel::Templates/missing return type

  • Key: UML14-253
  • Legacy Issue Number: 6203
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    OCL operation UML::AuxiliaryConstructs::Templates::TemplateableElement::parameterableElements() is missing a return type

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

    see above

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

UML 2 Super/Spec/completing mandatory sections

  • Key: UML14-261
  • Legacy Issue Number: 6211
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new OMG document structure requires certain mandatory sections (Scope, Confromance, Normative References, Terms and Definitions, and Symbols). Since these sections were not in the original submissions spec (or at least not in the form expected by the new OMG document structure), they need to be completed by the FTF.

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

    see above

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

UML 2 Super/Metamodel::CommonBehaviors/redundant class?

  • Key: UML14-252
  • Legacy Issue Number: 6202
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class UML::CommonBehaviors::Communications::Call is in the model, but does not participate in any associations, is not referenced, and does not appear in any diagrams

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

    Delete the above-mentioned class from the mdl file.

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

UML 2 Super/Metamodel/missing owners for metaclasses

  • Key: UML14-256
  • Legacy Issue Number: 6206
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious owners:

    AnyTrigger
    CallTrigger
    ChangeTrigger
    InformationFlow
    PrimitiveFunction
    SignalTrigger
    TimeTrigger

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

    see above

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

UML 2 Super/Metamodel/mis-spelled implementingClassifier"

  • Key: UML14-255
  • Legacy Issue Number: 6205
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of property Implementation::implementatingClassifier is misspelled; it should be "implementingClassifier".

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

    see above

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

UML 2 Super/Metamodel/missing source and target for InformationFlow

  • Key: UML14-260
  • Legacy Issue Number: 6210
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class InformationFlow specifies neither its source(s) nor its target(s).

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

    see above

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

ProtocolStateMachines/ProtocolStateMachine not a type of Feature

  • Key: UML14-259
  • Legacy Issue Number: 6209
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Property Interface::protocol subsets property Classifier::feature, but class ProtocolStateMachine is not a type of Feature

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

    see above

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

Protocol state machines are not pre/postconditions

  • Key: UML14-209
  • Legacy Issue Number: 6152
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text in the semantics of ProtocolStateMachine says:

    The protocol transition can always be translated into pre and post
    conditions of the associated operation. For example, the transition
    in Figure 9-13 specifies that:

    1. the operation "m1" can be called on an instance when it is in
    the state S1 under the condition C1,

    2. when m1 is called in the state S1 under the condition C1,
    then the final state S2 must be reached under the condition
    C2.

    The above translation is not possible by the definition of protocol
    machines. Protocol machines are a client-side view, independent of the
    the internal behavior machine of the instance. This means the protocol
    states are not necessarily the same as the internal states of the
    intance. The protocol machine is keeping track of the operations that
    have been called to enforce and order, but the internal behavior machine
    may or may not be the same. If they are the same, there would be no
    purpose to the protocol machine.

    The spec actually makes the same point at the beginning of the semantics of
    PSM:

    Using pre and post conditions on operations is a technique well
    suited for expressing such specifications. However, pre and post
    conditions are expressed at the operation level, and therefore do
    not provide a synthetic overview at the classifier level. Protocol
    state machines provide a global overview of the classifier protocol
    usage, in a simple formal representation.

    That is, If PSM's were easiy mappable to operation pre/postcondtions,
    there would be no point to having PSMs.

    Suggested change to the text:

    A protocol state machine could in theory be translated to pre- and
    postconditions on operations, but the conditions would need to account
    for the operation call history on the instance, which may or may not
    be straightforwardly represented by its internal states. A protocol
    machine provides a direct model of the state of interaction with the
    instance, so that constraints on interaction are more easily
    expressed.

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

    see above

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

Replace "initial value" with "default value".

  • Key: UML14-212
  • Legacy Issue Number: 6155
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    "Default values" should be called "initial values", for example in
    property values. Defaults are values that are assumed if no value is
    available on the instance. This can be at any time during the life of
    the object. An instance may have a value for a property at one time and
    when the value is removed, the default takes over until another value is
    given.

    The current semantics is that the "default" value is put in the property
    only when the object is created. If the value is later removed, the
    "default" value does not return. This is normally called an "initial
    value".

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

    No Data Available

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

TimeObservationAction can't return values

  • Key: UML14-211
  • Legacy Issue Number: 6154
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    TimeObservationAction says it returns a value, but it is a kind of
    WriteStructuralFeatureAction, which doesn't return values. Does it
    write the value to a structural feature? I assume the semantics should
    be more like DurationObservationAction

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

    see above

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

Diamond notation for merge junctions

  • Key: UML14-208
  • Legacy Issue Number: 6151
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Merge junctions should have a diamond notation option, for readability
    and backward compatibility

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

    No Data Available

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

Activity attributes on Behavior

  • Key: UML14-207
  • Legacy Issue Number: 6149
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The attributes of Activity defined in CommonBehavior look like they
    belong on Behavior.

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

    see above

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

Kernel::Classifier missing "attribute"

  • Key: UML14-213
  • Legacy Issue Number: 6156
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Kernel::Classifier lists the feature "attribute", and gives semantics
    and notation, that isn't shown in the abstract syntax for
    Kernel::Classifier. There isn't an "attribute" in the MDL file.

    Kernel::Classes abstract syntax refers to "attribute" in the subsetting
    of ownedAttribute.

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

    see above

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

Interactions view of state machines/activities

  • Key: UML14-210
  • Legacy Issue Number: 6153
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Interactions should be able to show a message passing view on a state
    machine or activity, by referring directly to the invocation actions in
    those models. UML 1.4 worked this way.

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

    see above

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

Concrete Behavior

  • Key: UML14-206
  • Legacy Issue Number: 6148
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Behavior should be a concrete class so behaviors can be defined without
    committing to which model will be used to specify them later

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

    No Data Available

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

Composite structure dependent on Behavior

  • Key: UML14-204
  • Legacy Issue Number: 6146
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Composite structure uses Classifier from Communications, but composite
    structure should be usable without behavior.

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

    No Data Available

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

Complex port

  • Key: UML14-205
  • Legacy Issue Number: 6147
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ComplexPort is referred to in Diagrams section of composite structures,
    but it is not in the metamodel.

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

    see above

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

UML 2 Super / Interactions / no create message

  • Key: UML14-307
  • Legacy Issue Number: 6260
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I am trying to find a mechanism to create a message that represents creation of lifeline. It used to be modeled as a relationship 'action' between Message and Action in UML 1.4.

    Note: There is a mechanism in UML 2 to create a message that represents destruction of lifeline. Its modeled as 'Stop' metamodel element.

    Shouldn't we have something symmetrical to represent creation of lifeline message?

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

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

UML2 Super / Primitive Types / implementation issue

  • Key: UML14-306
  • Legacy Issue Number: 6259
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects.

    As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them.

    There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2.

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML super/Section 2/Compliance points

  • Key: UML14-296
  • Legacy Issue Number: 6248
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The actual compliance levels as given on p. 1 ("no", "partial", "compliant", "interchange") are inadequate.

    For example, it is unclear what it means to "comply to the semantics", since semantics is generally stated in the proposal in terms of the system being modeled. Does a tool that simply provides a way to draw syntactically well-defined UML diagrams "comply to the semantics"?

    Furthermore, it is also unclear what it means to "comply to abstract syntax". What about a tool that presents the notation, but does not use the abstract syntax as its internal representation? Would such a tool only be able to claim "partial compliance", even if it provides 100% of the UML notation? If not, what is the criteria for compliance with abstract syntax?

    Even more problematic, XMI compliance is only required at the "interchange" level, which also requires compliance to abstract syntax, notation and semantics. This would seem to exclude any tool that processes XMI, but does not use the notation-for example, an execution engine that runs off XMI input or a tool that configures itself using an XMI-formatted UML model. There should be a way to claim XMI compliance without being a full modeling tool.

    In general, the compliance levels do not seem to be defined in a way that will be useful for the range of tools that may want to usefully claim UML compliance.

    Recommendation:

    The 2U proposal (ad/2003-01-08) contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. The UML 2.0 specification as adopted should compliance discussion based on the 2U approach.

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

    see above

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

Defenition of redefines?????

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

    Redefinition of Associations is causing me some concern. I have a attached a RoseModel which expresses it better than verbiage.

    This is my first post to this group and I would appreciate a reply upon receipt just to let me know it is being reviewed

  • Reported: UML 1.5 — Mon, 15 Sep 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/Composite Classes/Connecting parts of parts

  • Key: UML14-299
  • Legacy Issue Number: 6251
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Consider a model where a composite class, CC, has two parts A and B, both
    typed by class CT. If CT has a part PT, then can I describe a connection
    between A.PT and B.PT? It seems to me that the metamodel can't capture this
    because Connections can only be associated to parts, not parts of parts (i.e
    the metamodel for parts has a flat structure) . So the connection would end
    up being just a reflexive connection from PT to itself, which would be typed
    by a reflexive association on the type of PT.

    If there is a way of connection parts of parts I would like to see more
    explanation somewhere in the spec.

  • Reported: UML 1.5 — Mon, 15 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML2 Super / association end naming convention

  • Key: UML14-303
  • Legacy Issue Number: 6256
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To be consistent with the convention of other names in the spec, the names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent).

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

    No Data Available

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

UML2 Super / Classes/ Incorrect reference to "access"

  • Key: UML14-302
  • Legacy Issue Number: 6255
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are several places in the draft spec that refer to an "access" relationship when it should refer to a "uses" relationship instead. The access relationship according to the appendix is obsolete. The the incorrect reference I have found are on page 39, page 32.

  • Reported: UML 1.5 — Wed, 17 Sep 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 / State machines-CommonBehavior / undefined owner of triggers

  • Key: UML14-305
  • Legacy Issue Number: 6258
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It is not clear which kind of model element owns a Trigger specification (the Behavior to which it applies or something else?)

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6629.

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

UML2 Super / SimpleTime package / missing multiplicities

  • Key: UML14-304
  • Legacy Issue Number: 6257
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicities for the various constraints are unspecified in the documentation and the metamodel:

    Specifically, the multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

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

    see above

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

fig236 Datastore example/Datastore should not directly linked with actions

  • Key: UML14-298
  • Legacy Issue Number: 6250
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A datastore is a specialized CentralBufferNode. But in figure 236
    the datastore node is directly linked with action nodes. That is not
    allowed.

  • Reported: UML 1.5 — Fri, 12 Sep 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/p125 and p126/typos

  • Key: UML14-297
  • Legacy Issue Number: 6249
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 125, last paragraph, first line
    "As it turns out, this seemis redunadancy..."

    p. 126, second line
    Figures 23.4 and 23.5 are not there

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

What does redefines mean in package extensibility?

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

    What does redefines mean in package extensibility?

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

    see above

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

UML 2 Super / Interfaces / Cannot nest classes in interfaces

  • Key: UML14-356
  • Legacy Issue Number: 6399
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Java spec says that it is legal to have Java Classes nested in Interfaces:

    9.1.3 Interface Body and Member Declarations
    The body of an interface may declare members of the interface:

    InterfaceBody:

    { InterfaceMemberDeclarationsopt }

    InterfaceMemberDeclarations:
    InterfaceMemberDeclaration
    InterfaceMemberDeclarations InterfaceMemberDeclaration

    InterfaceMemberDeclaration:
    ConstantDeclaration
    AbstractMethodDeclaration
    ClassDeclaration
    InterfaceDeclaration
    ;

    But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML

  • Reported: UML 1.5 — Fri, 31 Oct 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 / restriction on redefining transitions

  • Key: UML14-355
  • Legacy Issue Number: 6397
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 502, there is a constraint that says that if a transition has a non-unique par <source state, trigger> it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed.

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

    see above

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

Typo on Notation for CombinedFragment?

  • Key: UML14-352
  • Legacy Issue Number: 6380
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    On page 413 of Superstructure spec (Adopted) – section concerning notation for CombinedFragments of Sequence diagram, for the Operator Ignore/Consider, the Textual Syntax seems to have a typo – should that be straight brackets surrounding the last <message name> to denote optional, rather than the curly brackets?

    In other words:

    Textual syntax: (ignore | consider ){ <message name>

    {,<message name>}

    * }

    Should Be:

    Textual syntax: (ignore | consider )

    { <message name>[,<message name>]* }
  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Visibility of a Package

  • Key: UML14-351
  • Legacy Issue Number: 6379
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    Under notation (top of page 100), says that “The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (‘+’ for public and ‘-’ for private).”

    This statement does not mention protected () or package (~) visibility; only public and private.

    Cross Reference:

    On page 31 of Adopted Superstructure spec, figure 6, the VisibilityKind enumeration class has attributes public, private, protected

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

    see above

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

UML 2 Super / Simple Time / incorrect multiplicities

  • Key: UML14-359
  • Legacy Issue Number: 6402
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

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

    Duplicate of 6257

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

UML 2 Super / Interface / missing owner of operation

  • Key: UML14-358
  • Legacy Issue Number: 6401
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property.

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

    see below

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

UML 2 Super / Package Templates / StringExpression inconsistency

  • Key: UML14-361
  • Legacy Issue Number: 6404
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved.

  • Reported: UML 1.5 — Fri, 31 Oct 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 / inconsistent naming

  • Key: UML14-360
  • Legacy Issue Number: 6403
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent) to be consistent with the rest of the specification

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

    This is duplicate with 6256.

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

Figure 395 requires a lot more explanation

  • Key: UML14-353
  • Legacy Issue Number: 6381
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 395 requires a lot more explanation. The abstract syntax claims that
    the effect of a transition be expressed as an Activity and so I suppose this
    is what this diagram represents, but I don't recognise the rectangle
    notation from activities. It's also not clear whether the arrows represent
    flows or transitions - if fact they can't be either, because some of the
    arrows start on states and end on actions. It also isn't clear whether there
    are any rules about the construction of these transitions; for example, I
    assume that there can only be one signal receipt and that it has to be the
    first symbol encountered, but that isn't stated. There may be an explanation
    that I missed, in which case it should be placed nearer the figure, or an
    appropriate reference inserted. The various symbols should also appear in
    the diagrams section.

  • Reported: UML 1.5 — Thu, 23 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 2 super / Templates / parameters cannot have names

  • Key: UML14-363
  • Legacy Issue Number: 6407
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The specification refers to template parameters by their names, implying that they are named elements; however, TemplateParameter is defined as a specialization of Element. Should TemplateParameter be a type of NamedElement?

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

    This is the same issue as issue 6262.

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

UML 2 Super / Deployments / node composition

  • Key: UML14-362
  • Legacy Issue Number: 6406
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Node::nestedNode should be an aggregate (containment by value) property

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

    Add the composition to the MDL and the spec.in figure 125

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

Questions about CentralBufferNode semantic

  • Key: UML14-350
  • Legacy Issue Number: 6378
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I have a question about the flow semantic according to
    a CentralBufferNode.

    p.312 (Examples) says:
    "...because each token can only be drawn from the object node
    by one outgoing edge."

    What exactly happens if a CentralBufferNode has more than one
    outgoing edge. Is it defined which one is used?

    In the example on p. 312 I cannot see why the edge leading to
    the action "Use parts" is prefered to the action "Pack parts" as
    described in the text ("All the parts that are not used will be packed...").

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04: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 / entry and exit actions cannot be redefined

  • Key: UML14-354
  • Legacy Issue Number: 6396
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the current metamodel it does not appear as if state entry and exit actions can be redefined. Since transition actions can be redefined, this restriction does not make sense and should probably be removed.

  • Reported: UML 1.5 — Fri, 31 Oct 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 super / Activities / structured activity node contradiction

  • Key: UML14-357
  • Legacy Issue Number: 6400
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::structuredNode subsets both node and group, but structured activity nodes can only be contained in one place (either group or node); should it be derived?

  • Reported: UML 1.5 — Fri, 31 Oct 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 Infra/Section 5.9/missing merge rules

  • Key: UML14-244
  • Legacy Issue Number: 6190
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML2 Infrastructure specification says in section 5.9 Packages Diagram, under Package Merge Semantics: "If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve conflicts." These rules don't appear to be defined anywhere. RedefinableElement indicates one redefining element may redefine multiple inherited redefinable elements.

    Clean Model Rule 8 says "An attrubute must be explicitly redefined in any cases where more than one attribute of the same name would be inherited from different superclasses, unless one of them already redefines the other." Rule 7 says "Attribute redefinition will be done by redeclaring an attribute in the subclass with the same name." This means that a redefinition in a subclass redefines all the inherited properties of the same name in all superclasses, and hides those inherited properties in the subclass. However, no common OO language supportes these semantics.

    As a result, performing the transformation specified by package merge semantics on UML2 Superstructure results in many name collisions caused by multiple inheritance of merged classes. This causes problems for XMI Schema and Java API generation.

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

    see above

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

UML 2 Super/Metamodel/package merge and visibility

  • Key: UML14-243
  • Legacy Issue Number: 6189
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The package merge rules say that private elements from the merged package are not merged into the merging package. However, this can result in inconsistencies if for example, an association is public but its ends are private. And it would not work at all for define merge since the merged types are not retained. The merge implementation currently ignores visibility

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

    see above

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

UML 2 Super/Metamodel::BasicActivities/inGroup problem

  • Key: UML14-247
  • Legacy Issue Number: 6193
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicActivities has edgeContents:ActivityEdge <--> inGroup:ActivityGroup. CompleteActivities has edgeContents:ActivityEdge

    {redefines edgeContents} <--> inGroup:InterruptibleActivityRegion {subsets inGroup}. inGroup ends up redefining and subsetting the inherited inGroup Should this have been interruptingEdge:ActivityEdge {redefines edgeContents}

    <--> interruptibleRegion:InterruptibleActivityRegion

    {redefines inGroup}

    and the other association removed? Or does inGroup need a new name?

  • Reported: UML 1.5 — Sun, 7 Sep 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/Metamodel::StructuredClasses/erroneous association

  • Key: UML14-246
  • Legacy Issue Number: 6192
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package StructuredClasses contains class Class and an association +:Class ->+ownedAttribute:InternalStructures::Property which does not appear on any diagram. This association does not match the similar one in Constructs: +class:Class <->+ownedAttribute:Property because it is missing an end name and navigability in both directions. It is not clear if this was intended to constrain the Constructs association so that a property does not know the class that contains it, or if the association was meant to be deleted. It cannot simply be corrected by adding the missing end and making it navigable in both directions as this would result in Property having two properties called class. Either the association should be removed, or StructuredClasses needs to redefine Property instead of referencing it directly from InternalStructures

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

    see above

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

UML 2 Super/Package Merge/redefinition rules and standard OO languages

  • Key: UML14-245
  • Legacy Issue Number: 6191
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around.

    A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute."

    This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined.

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

    see above

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

UML 2 Super/Metamodel::Constructs/inconsistency with Kernel

  • Key: UML14-241
  • Legacy Issue Number: 6186
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constructs has association mergingPackage:Package[1..1] c-> packageMerge:PackageMerge[0..*] while Kernel has mergingPackage:Package[1..1] c-> packageExtension:PackageMerge[0..*] without a renames. Should this be changed to packageMerge to be consistent with Constructs?

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

    Resolved as part of the resolution to issue 6918.

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

UML 2 Super/Metamodel::BasicBehaviors/missing redefinition

  • Key: UML14-240
  • Legacy Issue Number: 6185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicBehaviors has association context:BehavioredClassifier[0..1] c-->ownedBehavior:Behavior[0..*]. BehaviorStateMachines has :BehavioredClassifier[0..1]

    {subsets redefinitionContext}

    c--> ownedStateMachine: StateMachine[0..*]

    {redefines ownedBehavior}

    . StateMachine specializes Behavior thereby inheriting context:BehavioredClassifier. Property redefinitionContext comes from RedefiningElement, but the inherited property context is skipped. Is the role name missing? Should context:Behavior subset redefinitionContext?

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

    see above

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

UML 2 Super/Package Merge/missing rule for operations

  • Key: UML14-250
  • Legacy Issue Number: 6198
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package merge rules do not specify how operations match when being merged, or how they are merged if they do match

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

    The appropriate rules for this case are now spelled out in the resolution to issue 6279.

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

UML 2 Super/Metamodel::Compliance::L3/Missing merges

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

    UML::Compliance::L3 doesn't merge: InfrastructureLibrary::Profiles, UML::AuxiliaryConstructs.Templates, UML::CompositeStructures.StructuredActivities, UML::Profiles, UML::StateMachines::MaximumOneRegion

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

    see above

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

UML 2 Super/Metamodel/merging of non-redefinable model elements

  • Key: UML14-242
  • Legacy Issue Number: 6188
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Model elements, like Constraint, that are not RedefinableElements are always copied from the merged model element to the merging model element. When a package like Kernel is merged into many packages which are then in turn merged into another common package, these non-redefinable elements are copied down multiple times in the leaf merging package. For example, L3::Classifier has a large number of ownedRules named general_equals_parent which it gets from Dependencies::Classifier. Dependencies is merged into Kernel which is merged into many packages in Superstructure. Perhaps a Constraint should be a RedefinableElement, or package merge should only copy down these elements once

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

    see above

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

UML 2 Super/Metamodel::Kernel::Packages/missing redefinition

  • Key: UML14-239
  • Legacy Issue Number: 6184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/Packages has association package:Package <--> ownedClassifier:Type without a redefinition while its ownedType in Basic and Constructs

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

    This issue was resolved by the resolution to issue 6918.

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

UML 2 Super/Metamodel::StructuredActivities/double redefinition

  • Key: UML14-248
  • Legacy Issue Number: 6195
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StructuredActivities has association activity:Activity

    {redefines activity, redefines activity}

    <--> structuredNode:StructuredActivityNode. It should only redefine activity once.

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

    No Data Available

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

Profile/inability to attach a stereotype to an element

  • Key: UML14-251
  • Legacy Issue Number: 6199
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package Profile does not specify any way to attach a Stereotype to an Element.

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

    This issue is resolved by the solution to issue 6347.

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

SendObjectAction

  • Key: UML14-191
  • Legacy Issue Number: 6132
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clean up SendObjectAction so it doesn't refer to signals. It can send
    any object, including a signal.

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

    see above

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

Clarification of insert

  • Key: UML14-190
  • Legacy Issue Number: 6131
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in AddStructuralFeatureAction, etc, that insert is not needed
    when isReplaceAll = true.

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

    see above

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

Colon notation for pins

  • Key: UML14-185
  • Legacy Issue Number: 6125
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter notation can be used for pins even when they
    aren't invocation actions.

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

    see above

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

Local pre/postcondition example

  • Key: UML14-184
  • Legacy Issue Number: 6124
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a local pre/postcondition example that is really local

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

    see above

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

Parameter semantics clarification

  • Key: UML14-182
  • Legacy Issue Number: 6122
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of parameters "Either all non-stream outputs must be
    posted when an activity is finished, or one of the exception outputs
    must be." Reword and clarify that exception outputs are non-streaming.
    Also state that exception outputs cannot be streaming.

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

    No Data Available

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

ExceptionHandler 1

  • Key: UML14-192
  • Legacy Issue Number: 6133
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add a constraint to ExceptionHandler that the input of the exception
    handler body must be one value of same type as the exception input
    object node, and constraint that the input object node must be a pin
    on/part of the protected node.

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

    see above

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

No-token activity termination clarification

  • Key: UML14-189
  • Legacy Issue Number: 6130
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that activities terminate if there are no tokens in it,
    including tokens inside actions. The semantics of Parameter only states
    the necessary conditions now.

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

    see above

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

Notation for for global pre/postconditions actions

  • Key: UML14-187
  • Legacy Issue Number: 6128
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for actions invoking beahviors with global
    pre/postconditions

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

    see above

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

Behavior execution instances

  • Key: UML14-183
  • Legacy Issue Number: 6123
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Executing behavior creates an instance of the behavior class.

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

    No Data Available

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

Notation for isSynchronous

  • Key: UML14-188
  • Legacy Issue Number: 6129
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for isSynchronous on CallAction.

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

    No Data Available

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

Value Pin notation

  • Key: UML14-186
  • Legacy Issue Number: 6127
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for value pins.

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

    No Data Available

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

ObjectFlowEffect

  • Key: UML14-171
  • Legacy Issue Number: 6109
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ObjectFlowEffect requires edges from pins to actions.

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

    see above

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

Optional parameters

  • Key: UML14-170
  • Legacy Issue Number: 6108
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics for invocation actions on behaviors that have
    parameters with multiplicity with lower bound of zero? Currently, the
    execution semantics requires all data inputs to arrive.

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

    Duplicate with 6105.

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

Parameter set corrections 2

  • Key: UML14-176
  • Legacy Issue Number: 6116
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that two parameter sets should not have exactly the
    same parameters in them

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

    see above

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

ObjectNode.isUnique

  • Key: UML14-174
  • Legacy Issue Number: 6113
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that ObjectNode.isUnique = false

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

    No Data Available

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

Reentrancy 3

  • Key: UML14-173
  • Legacy Issue Number: 6112
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a notation for isReentrant.

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

    No Data Available

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

Pin multiplicity

  • Key: UML14-169
  • Legacy Issue Number: 6107
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics of pin multiplicity? If it has no execution
    effect, then remove it. If it is the same as the multiplicity inherited
    from TypedElement, then use that. If multiplicity has the same
    semantics as bound, then multiplicity should be used instead of bound

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

    See discussion and resolution to Issue 6090.

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

Parameter set corrections 1

  • Key: UML14-175
  • Legacy Issue Number: 6115
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The end names on the association between Parameter and ParameterSet
    are reversed.

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

    see above

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

ExecutableNode, ControlNode should be abstract

  • Key: UML14-172
  • Legacy Issue Number: 6110
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExecutableNode, ControlNode should be abstract

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

    see above

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

UML's use of the word "unique" for multiplicity is ambiguous

  • Key: UML14-133
  • Legacy Issue Number: 5976
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    UML's use of the word "unique" for multiplicity is ambiguous. It means
    "distinct", but it could be mistaken to mean "unique across all instances".
    For example, if someone says that the employee-number attribute of employee
    is unique, it would likely be understood to mean that each employee has an
    employee-number that is different from every other employee. But that's not
    what UML defines "unique" to mean. I recommend that the FTF change
    "

    {unique}

    " to "

    {distinct}

    " or "

    {set}

    ".

  • Reported: UML 1.5 — Thu, 19 Jun 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.0 Superstructure: Operation vs. Attribute notation

  • Key: UML14-132
  • Legacy Issue Number: 5951
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    For reference, my copy here is ad/03-04-01.

    I wonder about an inconsistency between the notations for attributes
    (section 1.8, page 41, in "Classifier (from Kernel, Dependencies,
    PowerTypes)") and operations (section 1.10, page 55, in "Operation
    (from Kernel)").

    For attributes, the notation is (slightly simplified)

    visibility name : type [multiplicity]

    {property-string}


    and for operations, it is


    visibility name (parameter-list) : property-string


    So in the case of attributes, a colon separates the name from the
    type, and the property-string is in curly braces, whereas for
    operations, the colon separates the name and signature from the
    property-string, which is not in braces.


    I think this discrepancy is counter-intuitive, I would expect the
    same atoms to be used in both blaces. I realize that the syntax for
    operations changed from UML 1.5 because of promoting the "return
    value" to a parameter.


    My suggestion is to change the notation for operations to


    visibility name (parameter-list) {property-string}

    i.e. to remove the colon, and to add braces around the property-
    string. This would be more consistent with both the attribute
    notation and the old UML 1.x notation.

  • Reported: UML 1.5 — Fri, 13 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

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

The description of DataType is plainly wrong in the specification

  • Key: UML14-135
  • Legacy Issue Number: 5979
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of DataType is plainly wrong in the specification. A
    data type is a classification of data values. The identity of a data value
    is based on the value itself. And the identity definitely exists.
    Otherwise you would not be able to know when you had two occurrences of the
    same value. If a value has no identity, it would not be possible to
    distinguish different values of the same data type. Someone has confused
    the concept of having identity with the concept of having a memory address.
    Note also that an instance specification is capable, according to the
    specification, of identifying a data value, so it is a contradiction to say
    a data value has no identity. Perhaps the specification is using the word
    "identity" in a way that is completely different from anything in my
    dictionary. The key point to make is that a data value is not to be
    confused with a data variable or a slot in an object that can hold a data
    value.

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

    see above - resolved

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

notation for shared aggregation

  • Key: UML14-134
  • Legacy Issue Number: 5978
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    3. The notation for shared aggregation appears to be missing from the
    association notation section

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

    Add text to explain the so-called “white diamond” notation for shared aggregation.

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

Question on Connectors - fig 2-17

  • Key: UML14-139
  • Legacy Issue Number: 5995
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On fig 2-17, the left-hand of the diagram shows Order with two interfaces,
    OrderableItem and OrderEntry. On the right hand, the assembly connector
    lists only OrderableItem. Yet, the text above -

    "When this notation is used to connect "complex" ports that are typed by
    multiple provided and/or required inter-faces,
    the various interfaces are listed as an ordered set, designated with

    {provided}

    or

    {required}

    if needed."

    might be interpreted as indicating that on the Order side of the assembly
    connector, the adornment should read "OrderableItem,OrderEntry" (as an
    aside, the text above seems to indicate that this list is ordered, but I
    don't know what the order should be). There are a number of possible
    explanations for the current figure:

    • It's a mistake and both interfaces should be listed;
    • Only interfaces supported by both sides of the connector need to be
      listed, (but how about compatible interfaces that are not related by
      classification?)
    • The text above does not apply to parts, but that seems unlikely -
      they are connectable elements after all and can implement and use multiple
      interfaces
    • Something I haven't though of

    Can someone please enlighten me?

  • Reported: UML 1.5 — Fri, 11 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState

  • Key: UML14-138
  • Legacy Issue Number: 5992
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    There appears to be a typo on page 2-148, in section 2.12.2.13 on StubStates. In this section it states that StubState is a child of State. However, in Figure 2-24 on page 2-141 it shows StubState as derived from StateVertex

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

    No Data Available

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

Well-Formedness Rules for Procedure on Common Behavior Package

  • Key: UML14-137
  • Legacy Issue Number: 5982
  • Status: closed  
  • Source: Freelance Developers ( Francisco Araujo)
  • Summary:

    Well-Formedness Rules for Procedure on Common Behavior Package are wrong, document is actually showing same content as Abstract Sintax for Procedure on Common Behavior Package.

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

    No Data Available

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

An error in Figure 464

  • Key: UML14-141
  • Legacy Issue Number: 6066
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I found there still is an error in Figure 464 from ptc/03-07-06 to 03/08/02 of UML 2.0 Superstructure Specification, ie. Collaboration Diagram should be replaced with Communication Diagram

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

    see above, resolved

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

PackageableElement

  • Key: UML14-140
  • Legacy Issue Number: 6049
  • Status: closed  
  • Source: Anonymous
  • Summary:

    there was declared and inheritance relationship between NamedElement and
    PackageableElement defining in both cases an attribute "visibility". I
    suggest to suppress the declaration in PackageableElement because it is
    inherited from NamedElement

  • Reported: UML 1.5 — Thu, 31 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Figure 63 missing notation

  • Key: UML14-145
  • Legacy Issue Number: 6070
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Also Figure 63 is missing "<<" from in front of Interface>> IAlarm

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Interface Figure 62 uses wrong notation

  • Key: UML14-144
  • Legacy Issue Number: 6069
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Figure 62 uses the wrong notation. The text says that it is using dependcy arrows - they are solid - one of them has a generalization arrow head. Also the interface 'ISensor' rectangle does not include <<interface>> with the name

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

Description of GeneralizationSet

  • Key: UML14-136
  • Legacy Issue Number: 5980
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of GeneralizationSet uses the words "general" and
    "specific" to mean "specific" and "general" respectively. The description
    also uses unclear terms like "maps to classifier" without identifying which
    association. Also, the semantics has: "All of the Generalization links that
    share a given general Classifier are divided into disjoint sets (that is,
    partitions) using the generalizationSet association." This statement is
    nonsense. First, the metamodel does not require all generalizations to be
    put into partitions using "the generalizationSet association". Second,
    partitions are not required by the metamodel to be disjoint - the same
    generalization can be in multiple generalization sets (as should be the
    case).

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

    see above, resolved

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

Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01

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

    In this section the following statement appears:

    "An imported element can be further imported by other namespaces using either element or member imports."

    This is the first and only reference I have found to "member import." Please provide a definition of member import and include an example if it may be required to complete the understanding of the concept.

  • Reported: UML 1.5 — Mon, 18 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

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

Obsolete notation used in state machine - transition examples

  • Key: UML14-143
  • Legacy Issue Number: 6068
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Section 15.3.14 Transition

    Figures 395 and 396 use lozenge shapes (a rectangle with rounded ends - the notation for an activity in UML 1.4). However, these are state machine examples and this notation is meaningless in this context.

  • Reported: UML 1.5 — Wed, 20 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

Profile Notation

  • Key: UML14-55
  • Legacy Issue Number: 4219
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    I raised this issue at the AB level. I didn't recommend holding up approval
    of UML 1.4 over this but we agreed that the new RTF would take this matter
    up with dispatch.

    Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
    and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
    issue. I can speak to this as a practical matter based on the profiling
    work I've done. When I define a Stereotype on a UML metamodel element, as
    in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
    of the UML metamodel element. I don't want to have to define it again
    before defining the relationship between my new Stereotype and that UML
    metamodel element. Thus, requiring the <<metaclass>> Stereotype on the UML
    metamodel element means that, in the UML metamodel itself, I would have to
    Stereotype all the metaclasses this way so that, if I need to, I can reuse
    them in VMMs. True, I could opt not to display the <<metaclass>>
    Stereotype in a pure UML metamodel diagram and opt to display it a VMM
    diagram, but all the UML metamodel elements would be carrying the
    <<metaclass>> Stereotype.

    The best solution I can think of to this problem is to to drop the
    requirement to use the <<metaclass>> Stereotype in VMM diagrams. As long as
    the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
    is adhered to, it should be pretty clear in a VMM diagram what is a
    Stereotype and what is a UML metamodel element. Also, the the standard
    metamodel Stereotype of Package indicates that the elements in the
    Package are elements of a metamodel.

    I am open to other suggestions as to how to resolve this issue.

  • Reported: UML 1.3 — Fri, 9 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, close issue

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

Appendix A, UML Standard Elements

  • Key: UML14-54
  • Legacy Issue Number: 4218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

  • Reported: UML 1.3 — Thu, 8 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Issue: Conflicting WFRs on Transition

  • Key: UML14-58
  • Legacy Issue Number: 4298
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    UML 1.4 Specification, Section 2.12.3, p. 2-165

    Description:
    WFR 5 for the class Transition states that "Transitions outgoing
    pseudostates may not have a trigger" and the OCL supports this absolute
    statement. However, WFR 6 is intended to allow transitions out of initial
    states, which are a kind of pseudostate, to have "a trigger with the
    stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
    legal.

    Recommendation:
    Change WFR 5 as follows.

    [5] Transitions outgoing pseudostates other than initial states may not have
    a trigger.

    self.source.oclIsKindOf(Pseudostate) implies
    self.source.oclAsType(Pseudostate).kind<>#initial implies
    (self.trigger->isEmpty())

  • Reported: UML 1.3 — Thu, 10 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

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

Add Multiplicity to Parameter.

  • Key: UML14-57
  • Legacy Issue Number: 4292
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Adding multiplicity to Parameter would enable modeling of arrays,
    collections, sequences etc. I would like to model BehavioralFeatures that
    can return an array and take an array as an argument.
    The notation would simply add the [multiplicity] after the Parameter type.
    The initial value syntax would be

    { initial-value, initial-value..}
  • Reported: UML 1.3 — Tue, 1 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Events, signals, stimuli, etc.

  • Key: UML14-56
  • Legacy Issue Number: 4263
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Shane Sendall)
  • Summary:

    Here is my understanding of communication between instances on an
    example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
    An instance i1 performs a SendAction, according to the spec: "A send
    action is an action that results in the (asynchronous) sending of a
    signal". Then, the signal is delivered to say instance i2, and as a
    consequence of the receipt, a SignalEvent is generated (according to the
    spec, "A signal event represents the RECEPTION of a particular
    (asynchronous) signal")
    Now the problems:
    1) the spec goes on further to say about the signal event that "A signal
    event
    instance should not be confused with the action (e.g., send action) that
    generated it". The problem I have with my above understanding is that
    the send action should not be the one generating the send event but
    rather the reception of the signal should be the one generating it.
    2)According to the spec: "A signal is a specification of an asynchronous
    stimulus communicated between instances" where a stimulus is more
    general "In the metamodel Stimulus is a communication, i.e. a Signal
    sent to an Instance, or an invocation of an Operation". Thus, I conclude
    that the things sent between instances are stimuli.
    However, I'm a little confused of the relationship between events and
    stimuli with the following sentence taken from the spec "Event instances
    are generated as a result of some action either within the system or in
    the environment surrounding the system. An event is then conveyed to one
    or more targets. The means by which event instances are transported to
    their destination depend on the type of action, the target,..."
    Furthermore, how are stimuli and signals related in the metamodel?

  • Reported: UML 1.3 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Predefined datatypes

  • Key: UML14-61
  • Legacy Issue Number: 4452
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The various datatypes that are the result of expressions are not
    defined in UML. For example, there is no subtype of Datatype
    called Boolean. This means users will all define their own Boolean,
    Integer, etc., breaking interchangeability.

    The datatypes defined in the Datatypes packages are not model
    elements, so theoretically cannot be used in M1 models. However,
    the interchange model for UML includes these types, making them
    available for user models. If this is the case, it should be made
    clear in the UML spec. The overview of the Datatypes package
    (section 2.7.1) says it contains types used in defining UML, so
    they formally belong to the MOF.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

The definition of Multiplicity in Datatypes does not list the range associa

  • Key: UML14-60
  • Legacy Issue Number: 4449
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of Multiplicity in Datatypes does not list the range association

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Component notation: logical compartments

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

    The current component notation does not provide for separate
    logical compartments when nesting implementation classes and artifacts in a
    component, as shown in Notation, Figure 3-95. It would be useful to provide
    separate logical compartments for this, as we do for subsystems and classes.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Exceptions do not correspond to common usage

  • Key: UML14-64
  • Legacy Issue Number: 4457
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions in UML are signals, but the normal usage of the term is
    for non-local flow of control that is trapped in procdural code.
    No signal is normally sent with exceptions.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Clarify the origin of an Action in a Collaboration.

  • Key: UML14-53
  • Legacy Issue Number: 4123
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Actions seem to be owned by the Message in the following paragraph.

    Section 2.10 page 2-130. "In the metamodel a Message defines one specific
    kind of communication in an Interaction. A
    communication can be e.g. raising a Signal, invoking an Operation, creating
    or destroying an
    Instance. The Message specifies not only the kind of communication, but also
    the roles of the
    sender and the receiver, the dispatching Action, and the role played by the
    communication
    Link. Furthermore, the Message defines the relative sequencing of Messages
    within the
    Interaction."

    Is the Action a reference to a Action in the Sender, as the meta-model
    suggests, or is it owned by the Message as the above suggests?

    Please clarify.

  • Reported: UML 1.3 — Mon, 18 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Ambiguous semantics of classifier targetscope

  • Key: UML14-59
  • Legacy Issue Number: 4447
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier targetscope is ambiguous for
    associations with participating classifiers that have children. It
    is not defined whether this specifies links for the classifier and
    all its descendants, or links for the classifier and each
    descendant separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Event => Event Specification

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

    The event metaclass would better called "event specification". Or
    at least the runtime event should be called "occurences" rather
    than instances.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6682.

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

The text and OCL of rule #5 for Method do not say the same thing.

  • Key: UML14-62
  • Legacy Issue Number: 4455
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text and OCL of rule #5 for Method do not say the same thing.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Another State machine issue

  • Key: UML14-37
  • Legacy Issue Number: 3202
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines

    The metaclass StateVertext, including its subclasses PseudoState,
    StubState and SyncState is not owned by a StateMachine.

    The associations from StateVertext to

    • container : CompositeState
    • outgoing : Transition
    • incoming : Tranision
      can all be empty.
      If they are all empty in a model, we do not know to which statemachine
      this StateVertex belongs. IS this the intention ?
  • Reported: XMI 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Data Types Misplaced in the "Physical" Metamodel (uml-rtf)

  • Key: UML14-36
  • Legacy Issue Number: 3127
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    All data types used in the UML metamodels are clumped together in a
    Data_Types package in the Foundation metamodel. When a new type is needed
    by some other metamodel, such as for Activity Graphs, the type is added into
    Foundation. This breaks the whole concept of extensibility. Data types,
    like other model elements, should be defined in the specific packages where
    they are needed. A new package that requires new types should include those
    types itself and not impose a change on UML Foundation.

    Recommendation: In the "physical" metamodel, put data types into the
    packages where they are first used. For example, PseudostateKind should be
    defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Inheritance violation in "Auxiliary Elements"

  • Key: UML14-30
  • Legacy Issue Number: 2361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
    1999 and the associated Rational Rose model files

    Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
    Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
    2.5.3, pp.2-49

    Nature: Clarification

    Severity: Medium
    Summary: In the 1.1 model file, there is an inheritance relationship
    between
    "Presentation" (in "Auxiliary Element") and "Element" (in "Core").
    "Presentation" is an association class and "Element" is a normal class.
    The two types are not the same, this this brings up the following
    constraint in the semantic document:

    self.subtype.oclType = self.supertype.oclType

    Question:
    1) Is "Presentation" suppose to inherit from "Element"? The other
    association classes "ElementOwnership" and "ElementReference" do no
    appear to do so.

    2) If the answer to (1) is yes, then isn"t it a violation of the UML
    semantics" well-formedness rule.

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

class EnumerationLiteral issue

  • Key: UML14-33
  • Legacy Issue Number: 2582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that the class EnumerationLiteral should be an heir of DataValue
    (this inheritance relationship is currently missing).

    Once this is fixed, the association between EnumerationLiteral and Enumeration
    should be seen as a refinement of the association between DataValue and DataType
    (itself implicitly inherited from the association between Instance and classifier),
    with a supplementary OCL constraint in the case of EnumerationLiteral,
    namely that self.classifier.oclIsKindOf(Enumeration)
    (to ensure covariance, as is done for DataValue wrt DataType).

    BTW, shouldn"t there be a symetric OCL constraint in DataType
    specifying that its Instances are all DataValues,
    and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?

  • Reported: XMI 1.0 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Operations and Constraints Missing from "Physical" Metamodels

  • Key: UML14-35
  • Legacy Issue Number: 3126
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The "physical" metamodel should include the OCL constraints and operations
    defined in the UML Specification. This has been done in the MOF 1.3
    specification. The operations provide valuable capabilities and should be
    part of the standard UML facility interfaces. Making the operations part of
    the "physical" metamodel allows them to be used when defining new
    constraints in extension metamodels, such as in CWM.

    Recommendation: Add the specification's constraints and operations to the
    "physical" metamodel.

    Note that adding constraints and operations will affect IDL, but it will not
    affect XMI DTDs.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Incomplete Inheritance Specification

  • Key: UML14-31
  • Legacy Issue Number: 2362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta

    Specification section reference: None

    Nature: Clarification

    Severity: Minor

    Summary: There is an oddity in the inheritance relationship of
    "Classifier" in "Core". Is "Classifier" suppose to inherit from
    "Taxon-Datatype", but the specification is incomplete. Rational Rose
    and Rose98 raises an error for this association during a "Check Model".

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Datatypes: Expression

  • Key: UML14-32
  • Legacy Issue Number: 2541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the metaclass Expression includes an attribute called "language" of type
    Name. To enable tools to check OCL expressions, it is neccesary to
    define a standard value for this attribute, which denotes the fact that the
    expressions is an OCL expression.
    Without such a standard defined value tools cannot distinguish OCL
    expresions and cannot interpret them (for purposes of typechecking,
    code generation, etc....)

    I propose to add the value "OCL" as a standard value for the attribute
    "language" of metaclass "Expression" to the chapter on datatypes.

  • Reported: XMI 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Interfaces on Nodes

  • Key: UML14-34
  • Legacy Issue Number: 2613
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot
    determine if interfaces are allowed on Nodes. Since a Node is a kind
    of classifier, it seems possible that a Node can realize an interface.
    However, since this relationship is not explicitly mentioned as allowed
    or not, I am unclear as to the intention.

  • Reported: XMI 1.0 — Mon, 19 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Dynamic concurrency arguments

  • Key: UML14-38
  • Legacy Issue Number: 3276
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions in dynamically concurreny states in activity graphs need
    some way to access the arguments provided by the concurrency
    expression. The Reference manual suggests the "implicit" event,
    but does not define what that is (p 437). Perhaps it is an the
    action language issue.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Parallel action iteration

  • Key: UML14-39
  • Legacy Issue Number: 3285
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should have a isParallel attribute to specify if the iteration
    is sequential or parallel.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Pin/parameter matching 4

  • Key: UML14-168
  • Legacy Issue Number: 6106
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in CallBehaviorAction and CallOperationAction that the operation
    and behavior may have out or results and still be called asynchronously.
    The constraints on these actions regarding pin/parameter matching only
    applies in the synchronous case.

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

    see above

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

Pin/parameter matching 3

  • Key: UML14-167
  • Legacy Issue Number: 6105
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    If the multiplicity of a parameter has zero lower bound, how does that
    affect the execution semantics of an invocation action on the
    behavior/operation? If the pin value is optional in this case, then it
    violates the current semantics.

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

    see above

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

Weight=all

  • Key: UML14-158
  • Legacy Issue Number: 6096
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The weight attribute on activity edges says:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But a figure 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 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Provide notations for Loop and Conditional

  • Key: UML14-157
  • Legacy Issue Number: 6095
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notations for Loop and Conditional

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

    Same as Issue 6071 (Conditional Node and Loop Node notation missing)

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

Multiple outputs of object flow transformations

  • Key: UML14-163
  • Legacy Issue Number: 6101
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    It would be useful to allow object flow transformations to produce
    multiple tokens from one token.

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

    see above

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

Keywords or properties

  • Key: UML14-162
  • Legacy Issue Number: 6100
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    Should the keywords "parallel", "iterative", and "stream" for
    ExpansionRegions be in guillemets like localPrecondition? Or is it a a
    property that should be in curly braces, like streaming parameters.

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

    see above

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

Tokens at fork

  • Key: UML14-159
  • Legacy Issue Number: 6097
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Fork won't let tokens pass on all outgoing edge unless all outgoing
    edges accept the copied token. Guards or backed up flows may prevent a
    token from being accepted on an outgoing edge. This causes a dependency
    between the outgoing edges.

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

    This is duplicate with 6512.

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

ExpansionRegions keywords

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

    The keywords "parallel", "iterative", and "stream" are defined for
    ExpansionRegions, but the example figures use "concurrent" instead of
    "parallel". The metamodel type ExpansionKind solely defines parallel"
    and the other two keywords mentioned above, not "concurrent".

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

    see above

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

Pin/parameter matching 1

  • Key: UML14-165
  • Legacy Issue Number: 6103
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are pins matched to parameters for invocation actions when there is
    only one parameter list for behaviors and two for actions? There should
    be a general action-pin association specialized for inputs and outputs.

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

    see above

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

ActivityFinalNode

  • Key: UML14-160
  • Legacy Issue Number: 6098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What happens to running actions within the activity when a token reaches
    an ActivityFinalNode? Are the actions terminated immediately or do they
    run to completion. Would prefer that they are terminated immediately

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

    This is a duplicate of 6504.

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

Pin/parameter matching 2

  • Key: UML14-166
  • Legacy Issue Number: 6104
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What kind of pin is used for inout parameters? If two pins are used,
    how are they matched to the same parameter?

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

    Duplicate of 6103.

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

Pins owned twice

  • Key: UML14-164
  • Legacy Issue Number: 6102
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Pins are owned twice: by activities and actions

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

    No Data Available

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

representation of arrays of values in an action language

  • Key: UML14-131
  • Legacy Issue Number: 5924
  • Status: closed  
  • Source: FAU Erlangen ( Martin Jung)
  • Summary:

    While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23];

    However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict?

    Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics.

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

    see above - resolved

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

2.5.2.29 Node

  • Key: UML14-130
  • Legacy Issue Number: 5805
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "resident The set of resident elements may differ. Often it is more restrictive on the child." has no corresponding association or attribute in any diagram.

  • Reported: UML 1.4 — Fri, 20 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2.15 Dependency

  • Key: UML14-128
  • Legacy Issue Number: 5802
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15).

    The same issue applies to the supplier association end and its documentation.

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above and below - resolved

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

2.5.2 Abstract Syntax

  • Key: UML14-123
  • Legacy Issue Number: 5797
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The binary association between ModelElement and Flow is undocumented both in the ModelElement and Flow documentation.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section: 2.5.2.10 Classifier

  • Key: UML14-122
  • Legacy Issue Number: 5796
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    specifiedEnd Indicates an AssociationEnd

    does not agree with the cardinality * on the association end specifiedEnd between Classifier and AssociationEnd in Figure 2-6 Core Package - Relationships on page 70.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2 Abstract Syntax

  • Key: UML14-129
  • Legacy Issue Number: 5803
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named container that belongs to the aggregation association between Component and ModelElement (Figure 2-8) is not documented in Section 2.5.2.27 ModelElement.

    2.5.2.27 ModelElement DOES document implementationLocation as "The component that an implemented model element resides in." This association is not on any of the Class Diagrams in Section 2.5.2.

    Should the implementationLocation association be renamed to container in Section 2.5.2.27 ModelElement?

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Designates a Generalization (02)

  • Key: UML14-121
  • Legacy Issue Number: 5795
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    Designates a Generalization whose child GeneralizableElement is the immediate descendant of the current GeneralizableElement.

    disagrees in plurality with the * cardinality of the specialization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

  • Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2.27 ModelElement

  • Key: UML14-125
  • Legacy Issue Number: 5799
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    implementationLocation The component that an implemented model element resides in.

    disagrees with the * cardinality of the implementationLocation association end of the ModelElement - Component association in Figure 2-8 Core Package - Classifiers on page 2-16.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2.10 Classifier

  • Key: UML14-126
  • Legacy Issue Number: 5800
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    "specifiedEnd Indicates an AssociationEnd..."

    disagrees with the cardinality * on the association end labeled specifiedEnd of the association between Classifier and AssociationEnd. (Figure 2-6 on page 2-14)

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2.16 Element

  • Key: UML14-124
  • Legacy Issue Number: 5798
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    Element cannot have tagged values. There is no tagged values attribute or association for class Element. Should the taggedValue feature be moved from ModelElement to Element?

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

2.5.2 Abstract Syntax

  • Key: UML14-127
  • Legacy Issue Number: 5801
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named typedParameter that belongs to the association between Classifier and Parameter is not documented in the Classifier section (2.5.2.10 Classifier on page 2-28).

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: ClassifierRole contents problem

  • Key: UML14-82
  • Legacy Issue Number: 4736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
    "...specifies a restricted view of a [base] classifier.." and defines "...a
    set of Features, which is a subset of those available in the base
    classifier, as well as a subset of ModelElements contained in the base
    classifier...".

    The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
    "feature" association inherited from Classifier must be empty - instead the
    ClassifierRole must select features from the base classifier using the
    "availableFeature" association [UML 1.4, pp. 2-121].

    The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
    2-121] indicating "the subset of ModelElements contained in the base
    Classifier, which is used in the Collaboration". There is however no
    restriction in the wellformedness rules restricting the ownedElements
    contents of the ClassifierRole itself, meaning that a ClassifierRole can
    contain the following meta-elements:

    Method
    Attribute
    Operation
    Reception
    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState
    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction
    ExtensionPoint
    Stimulus
    Parameter
    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    So the question is: is this lack of restriction intentional? And if so, why
    are ownedElements handled differently from features? And what is the
    semantic difference between entities selected using the "availableContents"
    association and those contained directly?

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Node, Artifact, Package and Model contents problem

  • Key: UML14-81
  • Legacy Issue Number: 4735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, the abstract metaclass Namespace
    compositely contains any type of ModelElement, but does however state that
    subclasses may restrict this containment [UML 1.4, pp. 2-45].

    The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
    1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
    however.

    This means that Node, Artifact, Package and Model can compositely contain
    the following concrete metaclasses as ownedElements:

    Method
    Attribute
    Operation
    Reception

    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState

    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction

    ExtensionPoint
    Stimulus
    Parameter

    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    The question is: are all these ownedElement types intended for all the
    mentioned containers? Especially the first 28 in the list appear out of
    place.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Suggest that alternate syntax used in section 6.5.5 be adopted thoughout

  • Key: UML14-89
  • Legacy Issue Number: 4816
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification.

    This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away.

    Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

  • Reported: XMI 1.3 — Tue, 29 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Invalid XMI.link.atts in UML 1.4 DTD

  • Key: UML14-88
  • Legacy Issue Number: 4810
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
    XMI.link.att declaration as follows:

    <!-- _______________________________________________________________ -->
    <!-- -->
    <!-- XMI.link.att defines the attributes that each XML element that -->
    <!-- corresponds to a metamodel class must have to enable it to -->
    <!-- function as a simple XLink as well as refer to model -->
    <!-- constructs within the same XMI file. -->
    <!-- _______________________________________________________________ -->

    <!ENTITY % XMI.link.att
    'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
    CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
    xlink:actuate (show|user) #IMPLIED xlink:content-role
    CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
    (embed|replace|new) #IMPLIED xlink:behavior CDATA
    #IMPLIED'>

    The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
    these (p4-81 of formal/00-11-02).

    The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
    (this appendix was removed at XMI 1.2 since it was wrong and misleading).

    Many of the above link attributes seem actually to be invalid:

    • xml:link is invalid since this is not part of the xml namespace
    • xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
      namespace
    • xlink:actuate has invalid values - the standard values are
      (onLoad|onRequest|other|none)
    • xlink:show is missing values - the full set is
      (new|replace|embed|other|none) [I guess it is not so much of a problem to
      exclude certain values]
  • Reported: XMI 1.3 — Mon, 21 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4.1 should use MOF 1.4

  • Key: UML14-95
  • Legacy Issue Number: 4946
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the case of MOF 1.4 there are far more important reasons for moving to
    it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
    opposed to CORBA datatypes hidden away in typeCodes. Because of this:
    a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
    Java APIs to metamodels and is being adopted by a number of repository and
    UML tool vendors. Without an official version of UML expressed in MOF 1.4
    people will have to do their own conversion with subsequent interoperability
    problems

    b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
    Without being expressed in MOF 1.4, the UML interchange definition cannot be
    expressed as an XML Schema.

    c) the proper datatype model provides the opportunity to 'clean up' a
    number of datatype-related issues in UML (e.g. issue 4452). And represent
    UML's datatypes such as Multiplicity and MultiplicityRange as MOF
    (structure) datatypes rather than MOF classes.

    I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
    be willing to draft a proposal for this. Is there a version of this with
    already-agreed 1.4.1 changes incorporated?

  • Reported: XMI 1.3 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Add action for invoking an activity

  • Key: UML14-94
  • Legacy Issue Number: 4940
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add action for invoking an activity

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

    No Data Available

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

UML 1.4: Wrong target for StateMachine.top association

  • Key: UML14-84
  • Legacy Issue Number: 4739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A StateMachine compositely contains a State through the "top" association
    [UML 1.4, pp. 2-147, fig. 2-24].

    However, the wellformedness rules for StateMachine state that "A top state
    is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
    2-158].

    If that is the case, the top association should target a CompositeState, not
    the more general State.

    Note: of course this is not an error as such, but if a wellformedness rule
    can be expressed just as easily in UML, there is no reason to complicate
    matters

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: AttributeLink containment error

  • Key: UML14-83
  • Legacy Issue Number: 4738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
    2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
    fig.2-17].

    The former containment obviously prevents the latter from ever being
    realized.

    Note: If changing the former containment from mandatory to optional, please
    remember to exclude AttributeLink from other composite containments
    implicitly enabled by such a change - such as being an ownedElement of a
    Namespace, or a parameter of a template.

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Definitions in glossary don't conform to any standard for definitions

  • Key: UML14-87
  • Legacy Issue Number: 4800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS.

    For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words.

    Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right.

    People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it.

  • Reported: XMI 1.3 — Wed, 2 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Composite relationship between Event and StateMachine

  • Key: UML14-86
  • Legacy Issue Number: 4746
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    As previously mentioned in issues 3558 (Who owns an Event?) and
    4734 (Event containment problem).
    Based upon issue 3558 response I believe that an Event should be owned by a
    StateMachine.
    A composite relationship should be added between Event and StateMachine in
    the UML Meta-Model.

  • Reported: XMI 1.3 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Simplify inputs/outputs of procedures

  • Key: UML14-92
  • Legacy Issue Number: 4927
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
    they point at inputs/outputs of contained actions. Groups referred
    input pins together that receive the value from the same parameter.

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

    No Data Available

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

match/correspond clarfication

  • Key: UML14-91
  • Legacy Issue Number: 4917
  • Status: closed  
  • Source: International Business Machines ( Mr. Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes. The
    specification text does not clearly explain how 'match' and 'correspond'

    • dependencies are to be used. See figure 2-57, page 2-307 are used in
      the spec. Are these intended to be illustrative? Are they constraints
      on the values passing thru input and output pins. What is the
      difference between 'match' and 'correspond'?
  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

StartStateMachine clarification

  • Key: UML14-93
  • Legacy Issue Number: 4936
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock] Does StartStateMachine cause the intial state to be
    entered and its outgoing transition taken? Ie, what is the semantics in
    relation to the RTC step.

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

    No Data Available

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

Namespace.contents

  • Key: UML14-90
  • Legacy Issue Number: 4848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current definition of the operation Namespace.contents is:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement -> union(self.namespace, contents)

    (UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

    The last line of this definition seems wrong, since the "union" operation
    must have a single parameter.

    The former definition of this operation did not present any contradiction
    between text and OCL expression:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement

    (UML Semantics, version 1.1 page 32)

  • Reported: XMI 1.3 — Tue, 26 Feb 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Adding events to the class definition

  • Key: UML14-85
  • Legacy Issue Number: 4740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The proposal is to add an optional fourth compartment to the
    class artifact that lists events that are accepted by that
    class.

    If a class is 'Active', it will have an associated
    state/activity model. This state/activity model will respond to
    events sent to that class. At the moment the only way to
    determine what events can be accepted by a class is to observe
    its state/activity model. Very clumsy!

    A workaround is to list events in the operations compartment
    and label them with an appropriate stereotype <<event>> for
    example. This should only be a temporary solution, since events
    are no more operations than they are attributes.

    Events need to be part of the class definition.

  • Reported: XMI 1.3 — Fri, 7 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Parametrizable model elements not shown

  • Key: UML14-17
  • Legacy Issue Number: 1209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
    ModelElements". Implicitly not to all ModelElements. Which ModelElements
    can
    and which cannot be templates?
    Some clarifications would be welcome, in what concerns the
    parametrisation of other kind of model elements, such as packages,
    operations and methods.

  • Reported: XMI 1.0 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Inconsistency regarding guards on forks

  • Key: UML14-119
  • Legacy Issue Number: 5745
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards.
    The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

    However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

    Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines?

  • Reported: XMI 1.3 — Fri, 1 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

spelling of the word Use Case

  • Key: UML14-118
  • Legacy Issue Number: 5744
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    I have a question about the spelling of the word Use Case. The different
    >spellings used everywhere are a little bit irritating to me (but this may
    >not be the case for other people). I think that it should be one fixed
    >spelling of the word defined i UML. But even in the UML specification I
    >found three different spellings on the same side: Use Case, use case and
    >UseCase. In a book I'm reading they use the following spelling: Use Case
    >and, when used with other words, Use-Case (Realization for example).

  • Reported: XMI 1.3 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

There is an unnecessary condition in rule 1 of the Namespace element

  • Key: UML14-110
  • Legacy Issue Number: 5732
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Rule 6 of the Method element isn't formulated well

  • Key: UML14-109
  • Legacy Issue Number: 5731
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There is a misprint in rule 2 of the Object element: “Stimuli” instead of “

  • Key: UML14-115
  • Legacy Issue Number: 5738
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There are misprints with numeration of rules of the Instance element

  • Key: UML14-114
  • Legacy Issue Number: 5737
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There are misprints with numeration of rules of the Instance element

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

there is something wrong with rule 3 of the Trace element

  • Key: UML14-112
  • Legacy Issue Number: 5735
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

The first sentence is not consistent with figure 2-9 on page 2-17

  • Key: UML14-120
  • Legacy Issue Number: 5763
  • Status: closed  
  • Source: Combitech Systems ( Per Tengdahl)
  • Summary:

    The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1.." and not "".

  • Reported: XMI 1.3 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Wrong alphabetical order: DataValue section should be before DestroyAction

  • Key: UML14-113
  • Legacy Issue Number: 5736
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Wrong alphabetical order: DataValue section should be before DestroyAction section.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Add rule to Namespace element

  • Key: UML14-111
  • Legacy Issue Number: 5734
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

There is a misprint in rule 1 of the SubsystemInstance element

  • Key: UML14-116
  • Legacy Issue Number: 5739
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

font sizes

  • Key: UML14-117
  • Legacy Issue Number: 5740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Using or implementing an interface of a Subsystem

  • Key: UML14-69
  • Legacy Issue Number: 4619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem.

    Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen.

    Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications.

    Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility.

  • Reported: UML 1.4 — Mon, 15 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD

  • Key: UML14-68
  • Legacy Issue Number: 4617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The cited sections refer to the property "isPolymorphic" for operations of a class (2.5.4.3), operations in an interface (2.5.4.6), and receptions (2.9.2.17). Issue 1165 indicates that "Operation:isPolymorphic" was renamed to "Operation:isLeaf" in UML 1.3. The XML attribute "isPolymorphic" does not exist in either the UML 1.3 or UML 1.4 XMI DTD. The cited sections should be changed to accurately describe the means by which polymorphism is indicated.

  • Reported: UML 1.4 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Optimize Instance data values

  • Key: UML14-67
  • Legacy Issue Number: 4504
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations.

    There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances.

    Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode.

    NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost).

  • Reported: XMI 1.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Component notation: showing delegation of messages

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

    The current notation does not provide for showing how method calls
    or messages to a component interface are delegated (or propagated) to the
    interfaces in components or implementation classes that reside in the
    component. This is sometimes referred to as the "wiring problem."

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: State containment problem

  • Key: UML14-75
  • Legacy Issue Number: 4729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a State can either be contained as a
    "subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
    a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
    2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
    concrete subclasses of Namespace restrict their owned elements to exclude
    State). The latter containment does not seem to make a lot of sense.

    Fortunately, the description of a StateMachine states that "This means that
    a state machine owns its transitions and its top state. All remaining states
    are transitively owned through the state containment hierarchy rooted in the
    top state." [UML 1.4, pp. 2-153].

    The question is: does this mean that a State is restricted to being
    contained in a CompositeState or a StateMachine? If not, please explain the
    meaning of e.g. a State contained directly in an otherwise empty Package?

    If the mentioned restriction is intended, it should be stated
    unambiguously so in the wellformedness rules for State:

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Action problem in Collaborations

  • Key: UML14-74
  • Legacy Issue Number: 4728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    n UML 1.4, an Action is only used in the context of a StateMachine or a
    CollaborationInstanceSet.

    In a CollaborationInstanceSet, an Action is required as the cause of a
    Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
    a Namespace (or in the context of a StateMachine, which is irrelevant here),
    it cannot be contained in the Stimulus, nor in the Instances the Stimulus
    connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
    are part of. The "nearest" possible container is the Package that happens to
    contain the CollaborationInstanceSet.

    Intuitively, this makes no sense - used in this context, the Action is
    clearly part of the InteractionInstanceSet, or the participating Instances
    or Stimuli.

    If this error report is rejected, please elaborate on the intended
    containment structures for Collaboration instances.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Event containment problem

  • Key: UML14-80
  • Legacy Issue Number: 4734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, an Event is defined as "...a
    specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
    is used exclusively in the context of state machines, as triggers of state
    transitions [UML 1.4, pp. 2-147, fig. 2-24].

    Because Event is a direct subclass of ModelElement - and because no other
    composite containments are specified for Event or any of its subclasses - it
    must be compositely contained as an ownedElement in a ClassifierRole, Model.
    Package, Artifact or Node (all other concrete subclasses of Namespace have
    restricted their owned elements to exclude Event).

    The question is: is this containment intended, or should an Event be
    contained in e.g. the StateMachine in which it is used? If the currently
    allowed containment IS intended, please explain the semantics of e.g. an
    Event contained in an otherwise empty Package (or even Model).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Stimulus containment

  • Key: UML14-79
  • Legacy Issue Number: 4733
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Stimulus is a ModelElement representing
    a communication between two instances [UML 1.4, pp. 2-106]. It is used
    exclusively in the context of collaborations, as part of an
    InteractionInstanceSet [UML 1.4, pp. 2-120].

    Because Stimulus is a direct subclass of ModelElement - and because no other
    composite containments are specified for Stimulus - it must be compositely
    contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
    or Node (all other concrete subclasses of Namespace have restricted their
    owned elements to exclude Stimulus).

    Having the Stimulus be part of any of these classes makes no sense, as it is
    intuitively part of the InteractionInstanceSet.

    Proposed remedy: change the association between InteractionInstanceSet and
    Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
    containment (with Stimulus as the part).

    Alternatively, please clarify the intended semantics of each of the
    currently allowed containments listed above

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Transition containment problem

  • Key: UML14-77
  • Legacy Issue Number: 4731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
    contained either as an "internalTransition" in a State, as a "transition" in
    a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
    Package, Artifact, Node or ClassifierRole (other containers excluded because
    of restrictions they make on the "ownedElement" containment in their
    wellformedness rules). The latter containment does not seem to make a lot of
    sense.

    The question is: is the containment of a Transition as an "ownedElement"
    intended? If so, please explain the meaning of e.g. a Transition contained
    directly in an otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Transition, e.g.:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: ExtensionPoint containment problem

  • Key: UML14-76
  • Legacy Issue Number: 4730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
    can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
    Artifact, Node or ClassifierRole (other containers excluded because of
    restrictions they make on the "ownedElement" containment in their
    wellformedness rules).

    The questions are: what is the intended meaning of an ExtensionPoint in eg.
    an otherwise empty Package? Why isn't the ExtensionPoint contained in the
    UseCase it extends, as would appear more logical to the uninitiated?

    Suggestion: change the association between ExtensionPoint and UseCase [UML
    1.4, pp. 2-135] to an unconditional composite containment (with
    ExtensionPoint as the part).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Feature containment problem

  • Key: UML14-78
  • Legacy Issue Number: 4732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
    contained either as an "feature" in a Classifier, or as an "ownedElement"
    [UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
    (other containers excluded because of restrictions they make on the
    "ownedElement" containment in their wellformedness rules). In addition an
    Attribute (subclass of Feature) may be contained as a "qualifier" in an
    AssociationEnd [UML 1.4, pp. 2-14].

    The question is: is the containment as an "ownedElement" intended? If so,
    please explain the meaning of e.g. an Operation contained directly in an
    otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Feature:

    self.namespace = null

    Remarks:
    ========
    It should be noted that the standard does make a number of partly
    contradictory statements which seem to indicate that Features can not be
    used as ownedElements:

    Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
    Classifier."
    Page 2-36: "A feature [...] is encapsulated within a Classifier."
    [contradicts with the statement below].
    Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
    case it is a feature) or an AssociationEnd (in which case it is a qualifier)
    but not both."
    Page 2-42: "Method is a declaration of a named piece of behavior in a
    Classifier"
    Page 2-45: "Operation is a BehavioralFeature that can be applied to the
    Instances of the Classifier that contains the Operation.".

    These statements could however be made unambiguous by adding the mentioned
    wellformedness rule.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Compliance to the UML" pp xxxi -- Editorial?

  • Key: UML14-72
  • Legacy Issue Number: 4662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was just reading the intro to UML 1.4, and may have found a typo. In the
    "Compliance to the UML" pp xxxi, it shows a table of package dependencies
    and states that complying with a package requires compliance with it's
    dependent packages.

    Core is shown as dependent on Data Types and Extension Mechanisms, and
    Extension Mechanisms is shown as dependent on Data Types and Core, leading
    to a circular relationship.

  • Reported: UML 1.4 — Sun, 21 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Nameclash in UML 1.4

  • Key: UML14-71
  • Legacy Issue Number: 4645
  • Status: closed  
  • Source: University of Technology, Sydney ( Brian Henderson-Sellers)
  • Summary:

    As far as I can see there is a name clash in UML 1.4.
    <<implementation>> is used as both
    (1) a stereotype of Generalization to mean implementation (or private)
    inheritance
    and
    (2) a stereotype of Class to mean the coding or implementation details of
    a Class

  • Reported: UML 1.4 — Sat, 27 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Using OCL at the meta-model level

  • Key: UML14-70
  • Legacy Issue Number: 4626
  • Status: closed  
  • Source: Colorado State Univ, Dept of Computer Science ( Robert France)
  • Summary:

    A. page 2-55; 2.5.3.6 Binding
    constraint [1]

    self.client.oclIsKindOf(self.supplier)

    Using my current understanding of OCL this seems wrong for the following
    reason:
    1. self.client returns an element at the M1 level (a UML model construct)
    2. the oclIsKindOf predicate compares the type of self.client
    (I assume the type of self.client is a metaclass at the M2 level) with the
    argument (which I assume from the definition of the predicate
    is a type and is thus an M2 element).
    3. self.supplier is not an M2 element.

    B. page 2-61 constraint [5] (similar comments as above)

    Am I misinterpreting self, OclIsKindOf, ...?

  • Reported: UML 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4: Action containment error

  • Key: UML14-73
  • Legacy Issue Number: 4727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Because Action is a ModelElement, it may be contained as an ownedElement
    [UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
    Node or Collaboration (all other concrete subclasses of Namespace restrict
    their owned elements to exclude Action).

    Because Actions are only used in the context of either a StateMachine or a
    CollaborationInstanceSet, this containment does not seem to make sense.

    In order to exclude these containments, the wellformedness rules for Action
    could include the following statement:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Guard in current metamodel can be replaced by Constraint with stereotype

  • Key: UML14-19
  • Legacy Issue Number: 2020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Guard metatype in the current metamodel contains only one attribute
    of type BooleanExpression. Since a guard is semantically equivalent to
    a Constraint on the transition, we can remove the Guard metaclass and
    add e standard stereotype <<guard>> for Constraints, with the same
    semantics.

    It simplifies the metamodel by unifying the Guard and Constraint concepts.
    It also allows OCL as the optional language to write the guard expression.

    Within the OCL specification, it should be checked if there are any
    additions that need to be made to support everything neded to express
    udseful guards.

  • Reported: XMI 1.0 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Need for notation for dealing with evolution of UML models

  • Key: UML14-18
  • Legacy Issue Number: 1512
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:

  • Reported: XMI 1.0 — Mon, 8 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Missing OCL

  • Key: UML14-25
  • Legacy Issue Number: 2289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to note that in the UML Semantics specification (versions 1.1
    and 1.2) the third well-formedness rule for Association does not have an
    OCL expression. It has only the natural language expression.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

OCL needs to be added

  • Key: UML14-24
  • Legacy Issue Number: 2278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only binary associations may be aggregates. There needs to
    be OCL added to do this.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the missing OCL

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

ElementOwnership

  • Key: UML14-26
  • Legacy Issue Number: 2290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
    declares ElementOwnership as an AssociationClass. This appears to be a
    violation of MOF compliance, since the MOF meta-meta-model does not support
    the notion of an AssociationClass.

    Of course one could extrapolate AssociationClass from the MOF
    meta-meta-model since it does support both Association and Class, and one
    could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
    extrapolated MOF AssociationClass. However, two architects might
    extrapolate these mappings in perfectly valid but different manners, since
    there is no standard mapping for a MOF AssociationClass. Apparently such
    an extrapolation has been performed in order to derive the IDL for the UML
    meta-model that concerns ElementOwnership, but doing this without a
    standard mapping seems dangerous.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

extension to the notation for a transition

  • Key: UML14-28
  • Legacy Issue Number: 2336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to make an appeal for an extension to the notation for a transition
    to allow its effect to be specified declaratively rather than only imperatively by
    means of an action sequence, e.g.

    e() / [p]

    While I realize there are ways to work around this (e.g. by writing "e() / pTrue()"
    where the query pTrue() has the postcondition "result = p and in targetState"), I
    think the issues are readability and ease of use.

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Page 19 semantic doc. name

  • Key: UML14-23
  • Legacy Issue Number: 2277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 19 semantic doc. name is described here but is not shown as
    a metalevel attribute on Figure 6. It should be.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

UML 1.1.section 4.2:editorial

  • Key: UML14-22
  • Legacy Issue Number: 2276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Aggregation: "when on target end, specifies whether target end
    with respect to source end". I think target and source are the wrong
    way round here.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

User-defined symbols for tagged values and properties

  • Key: UML14-27
  • Legacy Issue Number: 2291
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties

    {ordered}

    ,

    {frozen}

    and

    {add only}

    may define they own user-defined icons for those properties, because UML does not define them.

    Suggested Solution:
    UML users should be allowed to define specific symbols and icons for tagged values and properties.

  • Reported: XMI 1.0 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Associate a predicate with a state

  • Key: UML14-29
  • Legacy Issue Number: 2337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Related to the previously submitted issue regarding the declarative specification of
    the effects of transitions, I would like to suggest that it be possible to associate
    a predicate with a state.

    Such a predicate (e.g. written in OCL) would appear within the state box in the
    notation, just below the name of the state.

    Rather than extend the notation directly, I suggest this be a predefined property,
    e.g.

    {predicate = boolean-expression}

    .

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Figure 7 p. 43 of the UML semantics guide

  • Key: UML14-21
  • Legacy Issue Number: 2208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On Figure 7 p. 43 of the UML semantics guide,
    Template is described as a shared aggregate of its templateParameters,
    while Binding (representing an instantiation of a Template) is described
    as a composite aggregate of the actual arguments.

  • Reported: XMI 1.0 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

AssociationEnd needs ownerScope

  • Key: UML14-20
  • Legacy Issue Number: 2083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
    model a static (as in Java) relationship? Currently, it appears to only be
    possible using an Attribute of Classifier.

  • Reported: XMI 1.0 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

running a “Check Model” in Rose you get the following errors

  • Key: UML14-151
  • Legacy Issue Number: 6089
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When running a “Check Model” in Rose you get the following errors. Of which I am sure you are aware of. But do these errors indicate the absence of the parent element in the particular package or should the Specialize relation be deleted?

    12:52:41| [Check Model]

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Packages

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Classes

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Collaborations"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "InternalStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "CompositeStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "ActivityEdge"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "OutputPin"

    12:52:42| to Item with name Logical View::UML::Infrastructure::Core::Foundation::Classifiers::TypedElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Message"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Type"

    12:52:42| to Item with name Logical View::InfrastructureLibrary::Core::Constructs::Type

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "State"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

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

    No Data Available

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

Clarify wording on executable activity nodes

  • Key: UML14-154
  • Legacy Issue Number: 6092
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Name: Jim Frank
    Company: IBM
    mailFrom: joachim_frank@us.ibm.com
    Nature: Clarification
    Severity: Significant
    Subject: Clarify wording on executable activity nodes

    In the Activities chapter, an action "is an executable activity node
    that is the fundamental unit of executable functionality in an activity,
    as opposed to control and data flow among actions." Aren't control and
    data flow required to execute an action? The clause after the comma
    should be removed, and perhaps replaced with a sentence saying actions
    are used with control/data flow.

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

    see above

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

Outgoing edges from input pins

  • Key: UML14-153
  • Legacy Issue Number: 6091
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    (Quote from Semantics of CompleteStructuredActivities) "An object
    node attached to a structured activity node is accessible within the
    node. The same rules apply as for control flow. An input pin on a
    structured activity node implies that no action in the node may begin
    execution until all input pins have received tokens. An output pin on
    a structured activity node will make tokens available outside the
    node only after no tokens left in the node or its contained nodes
    recursively."

    So input pins on structured activity nodes are "accessible within the
    node" (as one would expect), but a constraint on InputPin says "input
    pins have incoming edges only". So how are they accessed from within
    the structured activity node? Analogous question for output pins of
    structured activity nodes, which can have outgoing edges only.

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

    see above

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

UML2 super/pg. 580/Stereotype typo

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

    The second paragraph of subsection "Notation" reads "When a stereotype
    is applied to a model element (an instance of a stereotype is linked to
    an instance of a metaclass), the name of the stereotype is shown within
    a pair of guillemets above the name of the Stereotype."

    I think the sentence should end with "... name of the model element".
    Otherwise the stereotype's name would be mentioned twice.

  • Reported: UML 1.5 — Wed, 27 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    End the sentence with “name of the model element”.

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

UML2 super/pg.470/entry and exit points for composite states

  • Key: UML14-149
  • Legacy Issue Number: 6075
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Two OCL constraints for entry and exit pseudostates of state machines (numbered [9] and [10]) only allow these psuedostates to be defined for the topmost regions of a state machine. This restriction is completely unnecessary and precludes common design patterns and should be removed. (In fact, from discussions with the authors of the spec, it seems that they were included due to a misunderstanding between two of the authors.)

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

    see above

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

Multiplicities diagram in section 7.4

  • Key: UML14-148
  • Legacy Issue Number: 6074
  • Status: closed  
  • Source: DeveloPeer Inc. ( Javier Estrada)
  • Summary:

    The Multiplicities diagram in section 7.4 defines two associations with ValueSpecification, namely upperValue and lowerValue. However, the constraints stated in section 7.4.1 for MultiplicityElement, are defined in terms of upperBound() and lowerBound()

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

    No Data Available

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

Action should be concrete

  • Key: UML14-156
  • Legacy Issue Number: 6094
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Action should be concrete. The description of the "effect" attribute
    says: "An optional text specification of the effect of the action. This
    may be used to indicate the behavior of an action without specialization
    into a subclass, ... " We think this is a good concept, and would like
    to instantiate Action for activity nodes whose behavior is only verbally
    described. Behavior, too.

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

    In Figure 176, make Action concrete.

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

Edge constraint for control nodes

  • Key: UML14-155
  • Legacy Issue Number: 6093
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The constraint for ControlNode ("The edges coming into and out of a
    control node must be either all object flows or all control flows.") is
    inconsistent with the semantics for JoinNode, which permit mixed types
    of incoming edges. Likewise a merge node can merge control and data
    flows. What type of edge should be outgoing in this case?

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

    Remove constraint [1] for Control Node, p 317.

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

Strange notation in Figure

  • Key: UML14-146
  • Legacy Issue Number: 6072
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The figure showing a use case with an associated state machine behaviour use lozenges (rectangles with rounded ends). This notation is obsolete

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Variable and Pin multiplicity

  • Key: UML14-152
  • Legacy Issue Number: 6090
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text refers to multiplicity of Variable and Pin, but they do not
    inherit from MultiplicityElement

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

    see above

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

No Glossary in 03-08-02

  • Key: UML14-147
  • Legacy Issue Number: 6073
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The certification includes the glossary. However, it is missing from 03-08-02, it was there in in 03-07-06.

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Initial state for composite states - OCL example and missing constraint

  • Key: UML14-100
  • Legacy Issue Number: 5273
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue was triggered by what seemed to be an ill-formed state machine
    example which revealed a deeper lack of rigor in the spec.

    The example state machine in section 6.5.10 (illustrating oclInState) does
    not have an initial pseudostate within the 'Off' state. Section 3.80.2
    indicates that this is mandatory:
    "A transition drawn to a composite state boundary indicates a transition to
    the
    composite state. This is equivalent to a transition to the initial
    pseudostate within the
    composite state region. The initial pseudostate must be present."

    [Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
    object.oclInState(Off:NoPower) should have a double colon:
    object.oclInState(Off::NoPower)].

    If indeed it is mandatory to have an initial state where there is a
    transition to a composite state (this does seem sensible for
    predictability), this should be reflected in a constraint within the
    abstract Syntax (section 2.12) to the effect that a CompositeState with
    'incoming' Transitions must contain an initial PseudoState.

    For example 2.12.4.3 contains the following which implies an initial
    pseudostate, though uses the ill-defined 'default transition' as well as
    'initial transition':
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, the
    default
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

    Proposed Resolution
    -------------------

    1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
    composite with a transition to 'Standby'.

    2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
    should have a double colon: object.oclInState(Off::NoPower)

    3. Add the following constraint to section 2.12.3.1
    [7] A composite state with an incoming transition must have an initial
    state.
    self.incoming->notEmpty() implies
    self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
    Pseudostate | p.kind = #initial)->size = 1

    4. Alter the section in 2.12.4.3 to read as follows:
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, there
    must be an initial state and the initial
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

  • Reported: XMI 1.3 — Thu, 9 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

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

UML 1.4 - Partition relates to nothing

  • Key: UML14-99
  • Legacy Issue Number: 5269
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 1.4 has no association for showing what a Partition relates to.
    Typically this would be something representing a role in a process.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

In v1.4, section 3.84.1 the paragraph on semantics

  • Key: UML14-104
  • Legacy Issue Number: 5657
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    "An Activity Diagram is a special case of a state machine in which the
    states represent performance of actions or subactivitities and the
    transitions are triggered by the completion of actions or subactivities. It
    represents the state machine of a procedure itself."

    But in Section 2.13.1 it says:

    "An activity graph is a special case of a state machine that is used to
    model processes involving one or more classifiers. Its primary focus is on
    the sequence and conditions for the actions that are taken, rather than on
    which classifiers perform those actions. Most of the states in such a graph
    are action states that represent atomic actions; that is, states that invoke
    actions and then wait for their completion. Transitions into action states
    are triggered by events, which can be

    • the completion of a previous action state (completion events),
    • the availability of an object in a certain state,
    • the occurrence of a signal, or
    • the satisfaction of some condition.
      "

    The latter statement implies that (a) events other than completion of prev
    activity can be triggers and (b) entire processes, not just procedures can
    be modeled in ADs.

    Which one is it?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section 2.13.4.3

  • Key: UML14-103
  • Legacy Issue Number: 5656
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    2) Section 2.13.4.3 says

    "Unless there is an explicit "fork" that creates orthogonal obect
    states only one of an object flow state's outgoing transitions will fire as
    determined by the guards of the transitions",

    which seems to require that if you want to "feed" the object to multiple
    actions, you will need a "fork" bar. But then 3.90.2.2 says:

    "The same object may be (and usually is) the output of one action
    and the input of one or more subsequent actions".

    This would seem to suggest that a "fork" bar is not required. Please
    clarify.

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML Issue - Inconsistency between UML 1.3 XMI and DTD

  • Key: UML14-101
  • Legacy Issue Number: 5525
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
    exist in the UML metamodel XMI file. This causes problems for my product
    which is metamodel-driven so reports an error when an import attempts to
    supply a value for the non-existent reference. This is strictly speaking a
    bug in the DTD (since it's not generated according to the XMI rules):
    however changing the DTD might cause inconvenience for vendors who are
    making use of it, and because not having the reference would make processing
    the tags much harder.

    At UML 1.4 the reference has been added to the metamodel, which suggests
    that the metamodel rather than the DTD be fixed. However this could require
    a restructuring to avoid circular package dependencies [see UML issue 3735].

    The same issue applies to the 'stereotype' reference on ModelElement - again
    it should ideally be added to the metamodel.

    The reason I'm raising the issue on UML 1.3 is that this is the chosen
    version for interoperability work. A decision is needed as to which way to
    resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
    1.4.

  • Reported: XMI 1.3 — Fri, 19 Jul 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section number duplicated

  • Key: UML14-107
  • Legacy Issue Number: 5685
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    Probably an Action Semantics RTF Issue, but one that may be addressed
    in an UML RTF.

    In the UML 1.5 spec in the action semantics chapter, sections numbers
    2.16 and 2.17 are duplicated. The section content appears all right
    but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.

    The document simply needs consistent renumbering of that chapter.

  • Reported: XMI 1.3 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Section 3.90.2.2

  • Key: UML14-106
  • Legacy Issue Number: 5659
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    Section 3.90.2.2 says

    "In other words when a state prodices an outpout that is input to the
    subsequent state, that object flow relationship implies a control
    constraint."

    I take it that this is not the same as isSynch being true? That is isSynch
    means that an object in an object flow is rather like a token in a Petri
    net. ie once it flows out to the consuming state, its gone from its place.
    Is that correct?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState

  • Key: UML14-97
  • Legacy Issue Number: 5267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
    oclIsKindOf, which should only take a single argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

A_context_raisedSignal

  • Key: UML14-96
  • Legacy Issue Number: 5005
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    The
    association in question is not named in the UML 1.4 interchange model. The
    name "A_context_raisedSignal", is an artificial one that was created by the
    program that created the DTD. It was using an algorithm recommended by the
    MOF RTF for naming unnamed associations. However, it would seem to be wise
    policy for this association to have a name. This would remove any
    dependency on the vagaries of various MOF tools.

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

    No Data Available

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

How does one indicate the target object for a CallState

  • Key: UML14-102
  • Legacy Issue Number: 5655
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    How does one indicate the target object for a CallState (i.e. the actual
    object that executes the stated action/method)? If the target action takes
    no parameters then it may be possible to say that the target object is just
    the object flowing into the CallState. But what if it does take parameters?
    (e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
    more than one object to be flowing into the CallState and leads to an
    ambiguity about which constitutes the target and which the parameter.

    P.S. The actual object may be passed around by the activity diagram, so it
    is not possible to show it statically on a swimlane (even if that is the
    recommended way)

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

parameters of object flow states

  • Key: UML14-105
  • Legacy Issue Number: 5658
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    parameters of object flow states – The Notation section of the UML 1.4
    Spec does not discuss it, nor is an example provided. I am still in the dark
    about how parameters are supposed to be used in the context of object flow
    states. Are output parameters supposed to be like reference parameters in
    the Algol style languages?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Well-formedness rules for 2.12.3.8

  • Key: UML14-98
  • Legacy Issue Number: 5268
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
    incorrect use of oclIsKindOf, which only takes one argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Swap rule 2 and rule 3 of the Binding element

  • Key: UML14-108
  • Legacy Issue Number: 5730
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Swap rule 2 and rule 3 of the Binding element. It improves readability

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

MOF rules should disallow certain composition relationships

  • Key: UML14-49
  • Legacy Issue Number: 3735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF rules should disallow composition relationships in instance metamodels
    where the container is in one MOF Package and the contained item is in
    another MOF Package and a dependency of the first package on the second is
    not allowed by the physical version of the metamodel due to MOF-imposed IDL
    generation rules.

    Reason for the issue:

    In the process of implementing an XMI-based interchange for UML 1.3, I have
    encountered a serious problem.

    This problem has to do with a divergence between the "Logical" and
    "Physical" model for UML 1.3 caused by rules imposed by MOF.

    In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
    version), "Preconditions for IDL Generation", requires that there be no
    cyclical dependencies between ModelElements in a meta-model.

    However, the UML 1.3 specification (June 1999) has a cyclical dependency
    between the Core and the Extension Mechanisms packages in the metamodel (See
    Figure 2-4). This cyclical dependency is explicitly disallowed by the
    precondition cited above.

    This circular dependency was removed from the "Physical Model" for UML 1.3
    in order to allow CORBA IDL and XMI DTD declarations in conformance with the
    precondition. As a result of the removal of this dependency, there are
    tremendous difficulties expressing the composition relationship between the
    UML ModelElement and the UML Tagged Value (see figure 2-10). In fact, the
    TaggedValue XML elements cannot even be in the exported UML Package element
    – they must be placed outside of it. This greatly complicates the export
    and import of UML 1.3 model files.

  • Reported: UML 1.3 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Notation for inherited associations

  • Key: UML14-48
  • Legacy Issue Number: 3682
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The CWM submitters needed to display inherited associations on some class
    diagrams to enhance understandability. These were not intended to be
    derived associations; that is, there was no intention to specify additional
    computational machinery when showing these inherited associations.
    Unfortunately, the MOF and UML have no succint way to display inherited
    associations. The CWM submitters placed the "/" derived prefix on the
    association end names in the class diagrams. At the same time, in order to
    prevent the generation of additional computational machinery, they omitted
    the inherited association from the normative XMI rendition of the metamodel.
    This was probably a reasonable choice under the circumstances. However, it
    means that the class diagrams and the XMI representation of the metamodel
    conflict with one another.

    It is very common to need to show inherited associations on a class diagram.
    We ran into this when we specified the CORBA metamodel for the CORBA
    Component Model submission. We used derived associations in the class
    diagrams as well. However, we retained the derived associations in the XMI
    rendition of the metamodel. In order to prevent additional computational
    machinery from being generated, we stereotyped the associations as
    <<implicit>>. This stereotype is defined in the UML specification but not
    in the MOF specification and says that an association is only conceptual and
    not manifest. We then made sure that the generator producing the IDL and
    XML DTDs was sensitive to the <<implicit>> stereotype. This had the
    advantage of maintaining consistency between the class diagrams and the XMI
    rendition of the metamodel. Of course this is also a non-standard
    approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
    generators to understand it.

    The lack of a standard means for representing inherited associations in
    class diagrams is thus resulting in a proliferation of non-standard
    approaches in adopted OMG metamodels. This could become unmanageable as the
    number of metamodels grows. A standard means should be specified.

  • Reported: UML 1.3 — Mon, 3 Jul 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Conflicting constraint between ActivityGraph and StateMachine.

  • Key: UML14-52
  • Legacy Issue Number: 4083
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Since an ActivityGraph is derived from a StateMachine its
    constraints must be consistent with that of a StateMachine. If an
    ActivityGraph has a Package as its context it violates the constraint
    inherited from StateMachine.

    ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
    (self.context.oclIsTypeOf(Package) xor
    self.context.oclIsKindOf(Classifier) xor
    self.context.oclIsKindOf(BehavioralFeature))

    StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
    self.context.oclIsKindOf(BehavioralFeature) or
    self.context.oclIsKindOf(Classifier)

    One way to avoid this problem is to change the StateMachine constraint to be
    applicable when self is oclIsTypeOf(StateMachine) so the constraint is not
    applied to it children.

    A general mechanism to disable inherited constraints could also solve the
    problem.

  • Reported: UML 1.3 — Wed, 29 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Attributes obsolete in UML 1.3

  • Key: UML14-51
  • Legacy Issue Number: 3999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    the association between StructuralFeature and Classifier should be
    removed. Attributes can not describe more information than
    Associations/AssociationEnds can. Therefore it is obsolete and confuses
    the user of UML, which to choose when modeling.

    On page 3-40 in the UML 1.3 specification it says: "Note that an
    attribute is semantically equivalent to a composition association;
    however, the intent and usage is normally different."

    If the semantics are equivalent, then it is impossible to distinguish
    between them. There is no extra layer of meaning above the semantics
    layer that can distinguish between two things with equal semantics.
    Semantics is meaning. I think this sentence is contradictory. I have not
    been able to find out what the difference in "intent and usage" is. If
    this is defined, it will obviously make the semantics of the two
    different.

    To improve the readability of class diagrams when everything is
    associations, I propose that associations should be possible to
    represent as text in the compartment where attributes are written today.

  • Reported: UML 1.3 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

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

Interface of an object

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

    This is a request for an interpretation of UML 1.3.

    The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

    -------- Background -------

    Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

    The UML submission said:

    "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."

    UML 1.3 says:

    "2.5.4 Semantics

    "Interface

    "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

    [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

    --------

    I am hoping this is easy to interpret and can be resolved quickly.

  • Reported: UML 1.3 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

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

Why is a StateMachine's top a State instead of a CompositeState?

  • Key: UML14-46
  • Legacy Issue Number: 3569
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Every StateMachine must have one top State. However, there is an
    OCL constraint that says that the top State must be a CompositeState
    (Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
    2-141). So, why not make the top relationship from StateMachine to
    CompositeState instead of from StateMachine to State. The constraint can
    then be eliminated.

  • Reported: UML 1.3 — Tue, 18 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-45
  • Legacy Issue Number: 3391
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

    The various places that uninterpreted strings are used in UML should
    support multiple languages. For example, the Expression metaclass has
    an metaattribute for language and another for the uninterpreted string.
    This should be a set of such pairs. Then code generators can target
    multiple languages from the same model.

  • Reported: XMI 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, see above

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

Efficient diagrammatic notation for Collaboration Specifications

  • Key: UML14-42
  • Legacy Issue Number: 3368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

    Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

    I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling ) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Statemachine/state as Namespace

  • Key: UML14-41
  • Legacy Issue Number: 3341
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    I am not sure if this qualify as an Issue, but I what just wondering
    why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: XMI 1.1 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML RTF 1.4 Issue: Missing notation mapping for association in composite

  • Key: UML14-40
  • Legacy Issue Number: 3291
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    No mapping for this in mapping section, p 3-77:

    [p 3-75, Notation section for Composition] An association drawn
    entirely within a border of the composite is considered to be
    part of the composition.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

Document 99-06-08 - UML Spec

  • Key: UML14-47
  • Legacy Issue Number: 3632
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'd find the document easier to digest if Chap 2 had some pictures in it.
    >>
    >>I know that the semantics is supposed to be independent of the
    >>representation. However, Chap 3 does contain some semantics in it for
    >>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
    >>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
    >>picture of the diamond shaped association end for aggregations, it would be
    >>easier to follow what the document is talking about.
    >>
    >>At least sections 3.55.1 and 2.11.4 for instance might have links, even if
    >>only footnotes, to connect actor notation and semantics.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

ClassifierRoles should be independent of specific underlying base Classifi

  • Key: UML14-43
  • Legacy Issue Number: 3376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example.

    Collaboration Templates don't do the trick; templates serve a different purpose.

    Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

UML 1.4 issue: Top state in activity graphs

  • Key: UML14-44
  • Legacy Issue Number: 3382
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Top state in activity graphs

    The state machine meta-model currently requires a top state, whereas
    activity graphs should not. Composite states are not required for
    activity graphs (wf [2] for PseudoState, p 2-166).

  • Reported: XMI 1.1 — Tue, 29 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

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

issues and bugs on the UML 1.4 Draft

  • Key: UML14-7
  • Legacy Issue Number: 4300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

    Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

    ---Begin of issues---------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

    (p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

    (p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

    (p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

    (p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

    ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

    Please clarify or correct the statement.

    (p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

    (p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

    (p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

    (p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

    (p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

    (p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

    (p. 3-3) Typographical/Editorial: There is no Part 8.

    (p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

    (p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

    (p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

    (p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

    (p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

    (p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

    (p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

    (p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

    (p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

    Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

    Please clarify

  • Reported: UML 1.3 — Sun, 13 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see below

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

class TaggedValuewill two association-ends with the same name "stereotype"

  • Key: UML14-6
  • Legacy Issue Number: 4187
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    In the physical metamodel for extensions (Figure 6-8) the class
    TaggedValuewill have two association-ends with the same name "stereotype".
    One
    from the association with the superclass ModelElement
    (extendedElement-stereotype) and one on its own (requiredTag-stereotype).

  • Reported: UML 1.3 — Wed, 31 Jan 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    in Uml 1.4 final, there is only one association end with this name

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

Figure 2-15 of the uml 1.4 spec

  • Key: UML14-14
  • Legacy Issue Number: 4531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

  • Reported: UML 1.3 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix in diagram: metaclass name is truncated (ModelElement => Model…). Duplicate of 4349

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

page 2-163, the statemachine semantics escription

  • Key: UML14-13
  • Legacy Issue Number: 4508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty

    I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state.

    On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add?

    On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

  • Reported: UML 1.3 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see above

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

isPolymorphic is never in a diagram

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

    2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic);

    2.5.4.3 Class has methods which can be polymorphic (isPolymorphic)

    2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic)

    But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

  • Reported: UML 1.3 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This is a duplicate of issue 4617,

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

well-formedness rule for Package is missing inUML 1.4

  • Key: UML14-15
  • Legacy Issue Number: 4534
  • Status: closed  
  • Source: Enea Business Software ( Karin Palmkvist)
  • Summary:

    A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

  • Reported: UML 1.3 — Fri, 24 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    The rule seems to have unintentionally disappeared from 1.3 to 1.4.

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

it's => its on page 3-150.

  • Key: UML14-10
  • Legacy Issue Number: 4453
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    it's => its on page 3-150.

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix

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

Wf 2 for AssociationEnd

  • Key: UML14-9
  • Legacy Issue Number: 4450
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The second wf rule for AssociationEnd uses the OCL operation
    applied to the wrong type (max applied to multiplicities).

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    obvious error, OCL only fix.

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

2.9.2 Abstract Syntax

  • Key: UML14-8
  • Legacy Issue Number: 4349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'.

    This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

  • Reported: UML 1.3 — Mon, 18 Jun 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix : Rose truncating the diagram, Previously fixed.

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

Notation example typo in Fig. 3-99

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

    In the example the dependencies between the focus class and the two
    auxiliary classes should connect to the target interfaces of the auxiliary
    classes, rather than their class rectangles. (Note: this typo may be
    corrected in the formal version of the UML 1.4 specification, which is not
    yet available.)

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Diagram to be fixed

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

The glossary entry "call" should be "call state".

  • Key: UML14-11
  • Legacy Issue Number: 4454
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The glossary entry "call" should be "call state".

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Change the name of the glossary entry

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

elimination of the Association Class TemplateParameter

  • Key: UML14-3
  • Legacy Issue Number: 3803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9.

    My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version:

    1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association

    B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1

    2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement

    B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of *

    3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances

    B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind

    Can you help me to solve this trouble?

  • Reported: UML 1.3 — Tue, 5 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

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

2) Page 2-49, additional operation #7 for Classifier

  • Key: UML14-2
  • Legacy Issue Number: 3531
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
    follows:

    1 oppositeAssociationEnds : Set (AssociationEnd);
    2 oppositeAssociationEnds =
    3 self.association->select ( a | a.associationEnd->select ( ae |
    4 ae.type = self ).size = 1 )->collect ( a |
    5 a.associationEnd->select ( ae | ae.type <self ) )->union
    6 (
    7 self.association->select ( a | a.associationEnd->select ( ae |
    8 ae.type = self ).size 1 )->collect ( a |
    9 a.associationEnd) )

    In line 5, the expression 'ae.type <self' is clearly wrong. I believe the
    intention may have been to test for inequality, i.e. 'ae.type <> self'.

    In line 8 'size 1' doesn't parse. I'm not sure what the intent was.

    A greater concern is that, even if corrected to address these flaws, this
    logic doesn't seem right in the case where we are dealing with an
    association where both ends are of the same type. It appears to be relying
    on detecting whether an end is opposite by testing the end's type. A fair
    number of other well-formedness rules leverage this operation in one way or
    another, so they are affected by this apparent flaw. Correcting this would
    require comparing the end instances, i.e. something like 'ae <> self' which
    does not have the same problem as 'ae.type <> self'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This issue has been fixed in UML 1.4. The correct operator is "<>"

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

Remove uses of multiple inheritance from UML meta model

  • Key: UML14-5
  • Legacy Issue Number: 3931
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model.

    Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It’s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

  • Reported: UML 1.3 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

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

Who owns a Comment?

  • Key: UML14-4
  • Legacy Issue Number: 3860
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
    Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2, p. 2-17, Figure
    2-9 Core Package - Auxiliary Elements
    Nature: Revision
    Severity: Minor
    Summary: A Comment is shown as having a relationship to ModelElement
    (annotatedElement). However, the ownership of a Comment is not specified
    anywhere. If it should reside in a Package the OCL-WellFormedness rule for
    Package should be updated. Also, shouldn't a Comment have a text field to
    hold the annotation?

  • Reported: UML 1.3 — Mon, 18 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Add Comment to wfr listing what may be owned by a Package

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

Page 2-47, well-formedness rule #2 for Classifier

  • Key: UML14-1
  • Legacy Issue Number: 3530
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    In the UML 1.3 specification (ad/99-06-08) there are the following problems:

    1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
    operation 'oppositeEnds' which is not defined. This probably should be
    'oppositeAssociationEnds'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

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