Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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-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-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-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-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-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-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-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 ( 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 ( 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 ( 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 ( 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

Issue 6090 correction

  • Key: UML14-553
  • Legacy Issue Number: 7561
  • Status: closed  
  • Source: NIST ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( Conrad Bock)
  • Summary:

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

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

    see above

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

Appendix A Diagrams

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

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

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

    This is the same issue as issue 6066

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

Section 17

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

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

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

    see above

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

Section 8.3.3 Realization

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

    The text states, "A component realization is notated in the same way as the realization dependency, i.e. as a general dashed line with an open arrow-head." What is an open arrowhead. Compare and contrast that with the "stick arrowhead" described in the Presentation Options section of Class in Composite Structures (page 156). Stick arrowhead can be found 6 times in the spec, while open arrowhead can be found 4 times. They all appear to refer to the same notation. I recommend that you chose one term.

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

    see above

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

Section 8.3.1 Component

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

    Figure 89 and 90. The text states "A component is shown as a Classifier rectangle with the keyword «component». Optionally, in the right hand corner a component icon can be displayed." Some of the example components do not have the <<component>> included, just the icon is present. My reading of the text is that this is incorrect. The icon is optional but the <<component>> designation is required

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

    see above

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

Section 14.4 Diagrams

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

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

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

    No Data Available

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

Section 14.4 Diagrams

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

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

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

    No Data Available

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

Section 8.3.1 Component

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

    Figure 81 should have identifiers for the provided interfaces. Figure 83 is not consistent with section 7.15.3 in that it uses a realization instead of a dependency as described in the text related to Figure 62. The examples in this section are not cohesive. It is not clear how Figure 85 relates to the rest of the examples.

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

    see above

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

Section 14.3.14 Message

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

    The semantics section states, "There will normally be a return message from the called lifeline..." while the Notation section refers to "The reply message from a method has a dashed line." If the return message and the reply message are the same ting then only use one name. If they are differnt, then explain the difference

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

    see above

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

Section 10 Deployments

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

    Figure 130 and 131. If these are meant to be two representations of the same node, then make the contents the same or explain the differences. Figure 136 should be <<ExecutionEnvironment>> vice <<container>>. Either that or the text is incorrect and needs to be changed

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

    No Data Available

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

Section 8.1 Overview

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

    This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types.

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

    see above

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

Section 14.4 Diagrams (02)

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

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

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

    No Data Available

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

Section 9.4 Diagrams

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

    Table 6. The Collaboration and CollaborationOccurrence notation is incorrect

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

    see above

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

UML2 Super/Ports

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

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

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

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

    No Data Available

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

UML2 Super/Connector

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

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

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

    see above

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

UML 2 Super / Activities / association end naming

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

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

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

    See changes for 6678.

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

UML 2 Super / Activities / inconsistency in representing subsetting

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

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

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

    see above

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

UML 2 Super/Activities/assocition end specialization consistency

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

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

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

    see above

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

subsettedProperty->forAll(sp | isDerivedUnion) ?

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

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

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

    subsettedProperty->forAll(sp | isDerivedUnion) ?

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

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

    This is a duplicate of issue 6430

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

UML2 Super/Connector End

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

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

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

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

    No Data Available

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

UML 2 Super/Activities/invalid multiplicity 0

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

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

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

    see above

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

UML2 Super/Structured Classes

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

    03-08-02.pdf

    Figure 95 - the term

    {subsets redefinit ionContext}

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

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

    No Data Available

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

UML 2 Super/Activities/end naming consistency

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

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

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

    see above

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

Page 164 - there are two constraints sections for Connector

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

    Page 164 - there are two constraints sections for Connector

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

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

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

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 ( 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 ( Alan Moore)
  • Summary:

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

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

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

    No Data Available

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

UML2 Super/Composite Classes

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

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

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

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

    see above

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

section 9 (State Machines) of 3rd revision

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

    In section 9 (State Machines) of 3rd revision

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

    {redefines owner}

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

    {subsets owner}

    (also in mdl file)

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

    see above

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

UML 2 Super/Actions/PrimitiveFunction missing properties

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

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

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

    See resolution of 7405.

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

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 ( 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 ( 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 ( Jon 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 ( 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 ( 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 ( Jon 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 ( Jon 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 ( Jon 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( 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 ( J.D. Baker)
  • Summary:

    The Semantics discussion includes the statement
    An imported element can be further imported by other namespaces using either element or member imports.

    The phrase "member import" is not defined and does not appear anywhere else in the spec. What does it mean? Provide an example of member import.

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

    see above duplicate

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

UML 2 Issue: Include(s) and Extend(s)

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

    PROBLEM STATEMENT
    The notation for the Extend and Include relationships is a dashed arrow with
    open arrow and the keyword <<extend>> or <<include>> (Superstructure, pp.
    516, 518). Nevertheless, the notation examples given in pages 521, 523 and
    524 write "extends" and "includes", with an final "s". The other examples
    are allright.

    PROPOSED SOLUTION
    Fix the notation examples.

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

    see above

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

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 ( J.D. Baker)
  • Summary:

    Table 4 - the Package Import dependency should be <<access>> not <<uses>>.

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

    see above

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

Section 7.15.3 Interfaces

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

    The text states "Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62)." Figure 62 has an association and a generalization relationship, not dependencies.

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

    This issue was resolved by the resolution to issue 6069.

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

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 ( J.D. Baker)
  • Summary:

    Figure 47. Some of the relationships appear to be generalization and some appear to be realization. It is not clear when Package Merge is useful or necessary. A more concrete example would help

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

    see above

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

Section 7.3.5 PackageImport

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

    This section is unique because it does not have a Notation section like all of the others

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

    No Data Available

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

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 ( 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 ( 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 ( Tim Weilkiens)
  • Summary:

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

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

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

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

    Is that true?

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

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

    see above

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

Token flow semantics: Implicit fork and join - UML2 Superstructure

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

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

    Is it the same semantic for object nodes?

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

    see above

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

Multiobject in UML2