Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

  • Acronym: UML
  • Issues Count: 492
  • 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
UML25-345 Location: 9.6.4 Notation p 128: Confusing indentation UML 2.4.1 UML 2.5 Resolved closed
UML25-684 Typo in Interaction Example UML 2.5b1 UML 2.5 Duplicate or Merged closed
UML25-682 InformationFlow cannot have an Activity as source or target UML 2.4.1 UML 2.5b1 Resolved closed
UML25-681 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 UML 2.5b1 Resolved closed
UML25-680 Profile::references_same_metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-679 Operation::isConsistentWith() UML 2.5b1 UML 2.5 Resolved closed
UML25-678 redefined states UML 2.5b1 UML 2.5 Resolved closed
UML25-677 Event pools for passive objects? UML 2.5b1 UML 2.5 Resolved closed
UML25-676 Who owns MessageEnds? UML 2.5b1 UML 2.5 Resolved closed
UML25-672 Problems with OCL definition of Package::makesVisible UML 2.5b1 UML 2.5 Resolved closed
UML25-671 an instance spec should be a legitimate value of a property typed by a classifier UML 2.4.1 UML 2.5 Resolved closed
UML25-668 A comment is a specialization of Element UML 2.4.1 UML 2.5 Resolved closed
UML25-667 Surplus classifier field serialized in Superstructure.xmi UML 2.4.1 UML 2.5 Resolved closed
UML25-670 Attribute is represented by Property UML 2.4.1 UML 2.5 Resolved closed
UML25-669 Operation "isConsistentWith" is not overridden for any RedefinableElement UML 2.4.1 UML 2.5 Resolved closed
UML25-664 Question About Arrows In Communication Diagramms UML 2.4.1 UML 2.5 Resolved closed
UML25-663 Constraint [1] uses undefined attribute "ownedAttribute UML 2.4.1 UML 2.5 Resolved closed
UML25-662 Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15 UML 2.4.1 UML 2.5 Resolved closed
UML25-665 missing words in section 14.1 UML 2.4.1 UML 2.5 Resolved closed
UML25-673 Incomplete sentence UML 2.5b1 UML 2.5 Resolved closed
UML25-666 DurationObservation#event should be ordered UML 2.4.1 UML 2.5 Resolved closed
UML25-661 LifeLine instead of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-607 UML 2 Super/Templates/Inconsistent organization UML 1.4.2 UML 2.5 Resolved closed
UML25-606 UML 2 Superstructure -Incompatible use of term link UML 1.4.2 UML 2.5 Resolved closed
UML25-604 UML 2.0 Issue: Semantics of Provided and Required Interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-603 CollaborationOccurence UML 2.0 UML 2.5 Resolved closed
UML25-609 Deployment (from ComponentDeployments, Nodes) UML 2.0 UML 2.5 Resolved closed
UML25-608 Dependency associations UML 2.0 UML 2.5 Resolved closed
UML25-615 9.3.11 Port (from Ports) UML 1.4.2 UML 2.5 Resolved closed
UML25-614 .3.44 Property (from Kernel) UML 1.4.2 UML 2.5 Resolved closed
UML25-610 UML2 super/CommonBehavior/Opaque behavior : bad OO modelling UML 1.4.2 UML 2.5 Resolved closed
UML25-611 7.3.24 Interface (from Interfaces) UML 1.4.2 UML 2.5 Resolved closed
UML25-605 UML 2 Superstructure - cross-hair notation for nested classes UML 1.4.2 UML 2.5 Resolved closed
UML25-612 9.3.6 Connector (from InternalStructures) UML 1.4.2 UML 2.5 Resolved closed
UML25-613 8.3.1 Component (from BasicComponents, PackagingComponents) UML 1.4.2 UML 2.5 Resolved closed
UML25-630 UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers UML 2.4.1 UML 2.5 Resolved closed
UML25-622 inconsistent Generalization subsections in spec format UML 1.4.2 UML 2.5 Resolved closed
UML25-621 notational standard for {subsets x} in textual contexts UML 1.4.2 UML 2.5 Resolved closed
UML25-629 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-628 Notation of enumeration literals UML 2.0 UML 2.5 Resolved closed
UML25-624 Associations section of InteractionUse UML 2.0 UML 2.5 Resolved closed
UML25-623 "Class" should read "Classifier" in Generalization subsection for Behaviore UML 1.4.2 UML 2.5 Resolved closed
UML25-620 15.3.14 Transition (from BehaviorStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-619 15.3.10 Region (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-627 Figure 307 and Figure 308 are exactly the same UML 2.0 UML 2.5 Resolved closed
UML25-626 UML2 Super / Templates / ordering of subExpressions UML 1.4.2 UML 2.5 Resolved closed
UML25-617 15.3.16 Vertex (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-616 Artifact (from Artifacts) UML 1.4.2 UML 2.5 Resolved closed
UML25-625 UML 2 Super/ Classes / issue with Property::isComposite UML 1.4.2 UML 2.5 Resolved closed
UML25-618 15.3.8 Pseudostate (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-675 Modeling sent messages in State Machines UML 2.3b1 UML 2.5 Resolved closed
UML25-674 TestIdentityAction for datatypes FUML 1.0b2 UML 2.5 Resolved closed
UML25-660 Behavior should be derived from Classifier, not Class UML 2.4.1 UML 2.5 Resolved closed
UML25-659 Package merge on Class metatype causes semantic issues - particularly with state machine context UML 2.4.1 UML 2.5 Resolved closed
UML25-648 Error in UML diagrams? UML 2.4.1 UML 2.5 Resolved closed
UML25-647 Suggestions for editorial changes UML 2.4.1 UML 2.5 Resolved closed
UML25-654 how to instantiate associations between stereotypes UML 2.4.1 UML 2.5 Resolved closed
UML25-653 Core package caption wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-658 Add an example for the lifeline head shape UML 2.4.1 UML 2.5 Resolved closed
UML25-657 color of the notation is specified UML 2.4.1 UML 2.5 Resolved closed
UML25-656 The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/" UML 2.4.1 UML 2.5 Resolved closed
UML25-655 Opposite ends of derived unions should be derived unions UML 2.4.1 UML 2.5 Resolved closed
UML25-651 Use of term "locus of control" UML 2.4.1 UML 2.5 Resolved closed
UML25-650 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-646 default is wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-645 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-649 Reference in index to item that does not exist in contents UML 2.4.1 UML 2.5 Resolved closed
UML25-652 incorrect upper value of coveredBy of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-632 ChangeEvent association mismatch UML 2.4.1 UML 2.5 Resolved closed
UML25-631 EnumerationLiterals in the XMI UML 2.4.1 UML 2.5 Resolved closed
UML25-635 "A_realization_abstraction_component" is useless UML 2.4.1 UML 2.5 Resolved closed
UML25-634 Subpart I and II are missing in Bookmarks UML 2.4.1 UML 2.5 Resolved closed
UML25-644 default value of ClassifierTemplateParameter#allowSubstitutable is "..." UML 2.4.1 UML 2.5 Resolved closed
UML25-643 Figure 15.2 does not include TransitionKind UML 2.4.1 UML 2.5 Resolved closed
UML25-640 role "interval" appears "interva" UML 2.4.1 UML 2.5 Resolved closed
UML25-639 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-642 misspelling: io-oargument UML 2.4.1 UML 2.5 Resolved closed
UML25-641 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-636 RedefinableElement (from Kernel) is preferable UML 2.4.1 UML 2.5 Resolved closed
UML25-633 UML Superstructure Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-637 poor figure resolution and a misspelling: fal...( false ) UML 2.4.1 UML 2.5 Resolved closed
UML25-638 {ordered} is rather far from +bodyOutput UML 2.4.1 UML 2.5 Resolved closed
UML25-601 UML 2 Super and Infra/ defualt property of Parameter::effect UML 1.4.2 UML 2.5 Resolved closed
UML25-602 Associations between interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-562 Section: 9.3.3 UML 2.0 UML 2.5 Resolved closed
UML25-561 At «implementation Class», what does "a child of instance" mean?! UML 2.0 UML 2.5 Resolved closed
UML25-559 three possibilities for aggregation kind at 7.11.2, but only two notations UML 2.0 UML 2.5 Resolved closed
UML25-558 Section: 7.11.2 UML 2.0 UML 2.5 Resolved closed
UML25-560 It is not clear what 'related to' means UML 2.0 UML 2.5 Resolved closed
UML25-499 Association notation for properties does not allow representation of aggregation UML 2.5b1 UML 2.5 Resolved closed
UML25-498 UML2.5 issue: incorrect use of oclKindOf()->notEmpty() UML 2.5b1 UML 2.5 Resolved closed
UML25-497 wrong multiplicity of redefining states UML 2.5b1 UML 2.5 Resolved closed
UML25-496 Keywords are inconsistently defined and applied UML 2.5b1 UML 2.5 Resolved closed
UML25-487 InformationFlow::sources_and_target_kind UML 2.5b1 UML 2.5 Resolved closed
UML25-494 UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype UML 2.5b1 UML 2.5 Resolved closed
UML25-493 UML 2.5 - clause 14 does not put Examples at the correct heading level UML 2.5b1 UML 2.5 Resolved closed
UML25-489 Table C.1 apply UML 2.5b1 UML 2.5 Resolved closed
UML25-488 Metaclass operations incomplete UML 2.5b1 UML 2.5 Resolved closed
UML25-492 UML2.5 issue: clause 10 Signal and Reception UML 2.5b1 UML 2.5 Resolved closed
UML25-491 Conflict in use of unlimited natural UML 2.4.1 UML 2.5 Resolved closed
UML25-495 UML 2.5: ActivityPartition::represents keywords UML 2.5b1 UML 2.5 Resolved closed
UML25-490 UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction UML 2.5b1 UML 2.5 Resolved closed
UML25-486 Classifier::hasVisibilityOf(...) UML 2.5b1 UML 2.5 Resolved closed
UML25-485 Two entries UML 2.5b1 UML 2.5 Resolved closed
UML25-519 About UseCase description UML 2.5b1 UML 2.5 Resolved closed
UML25-518 Annex B summary table UML 2.5b1 UML 2.5 Resolved closed
UML25-529 actors of a use case express the requirements of its subject(s) regarding its/their environment. UML 2.5b1 UML 2.5 Resolved closed
UML25-528 UML: Parameter Direction and Effect UML 2.5b1 UML 2.5 Resolved closed
UML25-523 UML 2.5 Issue: specification for qualified association ends is in wrong clause UML 2.5b1 UML 2.5 Resolved closed
UML25-522 UML 2.5 class_name UML 2.5b1 UML 2.5 Resolved closed
UML25-526 Event pools for passive objects UML 2.5b1 UML 2.5 Resolved closed
UML25-525 Behavior after exceptions are encountered UML 2.5b1 UML 2.5 Resolved closed
UML25-521 UseCases editorial change UML 2.5b1 UML 2.5 Resolved closed
UML25-520 The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice UML 2.5b1 UML 2.5 Resolved closed
UML25-517 Clarify that stereotypes can be applied to UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-516 UML2.5 clause 17 keyword inconsistency UML 2.5b1 UML 2.5 Resolved closed
UML25-524 Completion events disambiguation UML 2.5b1 UML 2.5 Resolved closed
UML25-527 UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction UML 2.5b1 UML 2.5 Resolved closed
UML25-530 UML 2.5 FTF Receptions may not have a method UML 2.5b1 UML 2.5 Resolved closed
UML25-414 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting UML 2.4.1 UML 2.5 Resolved closed
UML25-417 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject UML 2.4.1 UML 2.5 Resolved closed
UML25-416 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner UML 2.4.1 UML 2.5 Resolved closed
UML25-415 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with UML 2.4.1 UML 2.5 Resolved closed
UML25-420 18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true UML 2.4.1 UML 2.5 Resolved closed
UML25-419 18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy UML 2.4.1 UML 2.5 Resolved closed
UML25-418 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case UML 2.4.1 UML 2.5 Resolved closed
UML25-422 Location: 18.1.4 Notation P. 688 - Point to diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-421 18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner UML 2.4.1 UML 2.5 Resolved closed
UML25-574 State Machine Package--Compliance RAS 2.0b1 UML 2.5 Resolved closed
UML25-573 Actions need to be independent from Activities RAS 2.0b1 UML 2.5 Resolved closed
UML25-567 Concept of 'port side' not to be found in metamodel UML 2.0 UML 2.5 Resolved closed
UML25-566 Composite structures/contradictory constraint on connector RAS 2.0b1 UML 2.5 Resolved closed
UML25-568 UML 2 Super/Interfaces RAS 2.0b1 UML 2.5 Resolved closed
UML25-571 Issue in UML 2 CombinedFragment class RAS 2.0b1 UML 2.5 Resolved closed
UML25-570 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-565 Description text for CollaborationOccurrence unclear UML 2.0 UML 2.5 Resolved closed
UML25-564 Editrial error in Section: 9.3.4 ? UML 2.0 UML 2.5 Resolved closed
UML25-563 Association collaborationRole UML 2.0 UML 2.5 Resolved closed
UML25-569 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-572 Issue in UML 2 Gate class RAS 2.0b1 UML 2.5 Resolved closed
UML25-503 Interactions needs to fix Gate name Distinguishability rules UML 2.5b1 UML 2.5 Resolved closed
UML25-502 ActionInputPin notations missing UML 2.5b1 UML 2.5 Resolved closed
UML25-515 UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole UML 2.5b1 UML 2.5 Resolved closed
UML25-514 UML2.5's Connector role constraint excludes inherited roles UML 2.5b1 UML 2.5 Resolved closed
UML25-505 Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature UML 2.5b1 UML 2.5 Resolved closed
UML25-504 Classifier operation inherit(NamedElement[*]) : NamedElement[*] UML 2.5b1 UML 2.5 Resolved closed
UML25-511 Forked association notation ill-formed UML 2.5b1 UML 2.5 Resolved closed
UML25-501 UML 2.5 Beta 1 9.5.3 Qualifiers UML 2.5b1 UML 2.5 Resolved closed
UML25-500 Transition redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-513 parts should be allowed to show their interfaces UML 2.5b1 UML 2.5 Resolved closed
UML25-512 Behavior is not allowed to be source or target of an InformationFlow UML 2.4.1 UML 2.5 Resolved closed
UML25-510 UML 2.5 FTF] Editorial / §15.5.1 p429 UML 2.5b1 UML 2.5 Resolved closed
UML25-509 Inheriting Connectors UML 2.5b1 UML 2.5 Resolved closed
UML25-507 UML 2.5 FTF 14.2.3 Page 327 Typo UML 2.5b1 UML 2.5 Resolved closed
UML25-506 Incorrect text on state list notation interchange UML 2.5b1 UML 2.5 Resolved closed
UML25-508 UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput UML 2.5b1 UML 2.5 Resolved closed
UML25-582 UML 2 Super/Components/missing description of Connector::contract UML 1.4.2 UML 2.5 Resolved closed
UML25-581 UML 2 Super/Interactions/notation for accessing a static feature UML 1.4.2 UML 2.5 Resolved closed
UML25-584 Missing notation for Behaviors in a BehavioredClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-583 Name without a colon for Property in Composite Structures UML 1.4.2 UML 2.5 Resolved closed
UML25-586 Profiles in Compliance Level 1? UML 1.4.2 UML 2.5 Resolved closed
UML25-585 Redundant parameter specifications for Operation and Behavior UML 1.4.2 UML 2.5 Resolved closed
UML25-576 There is no "precise mapping UML 2.0 UML 2.5 Resolved closed
UML25-579 UML 2 Super/Activities/Class-Activity association missing UML 1.4.2 UML 2.5 Resolved closed
UML25-578 UML2 super&infra/Profiles/ownership of Image UML 1.4.2 UML 2.5 Resolved closed
UML25-588 Figures 103 and 121 use <> dependencies UML 1.4.2 UML 2.5 Resolved closed
UML25-587 . <> on Usage UML 1.4.2 UML 2.5 Resolved closed
UML25-580 UML 2 Super/Templates/Template substitution symbol problematic UML 1.4.2 UML 2.5 Resolved closed
UML25-577 Port should specialize featuringClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-575 Semantics section of StructuralFeature UML 2.0 UML 2.5 Resolved closed
UML25-538 Clarification of use of BNF for textual notations UML 2.5b1 UML 2.5 Resolved closed
UML25-537 ActivityParameterNode notation UML 2.5b1 UML 2.5 Resolved closed
UML25-539 Avoid covariant parameters in metamodel operation redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-536 The resolution to Issue 18528 contains incorrect OCL and operation names UML 2.5b1 UML 2.5 Resolved closed
UML25-535 The resolution to issue 18415 contains invalid OCL UML 2.5b1 UML 2.5 Resolved closed
UML25-546 Wording corrections in Behavior Diagrams and Activity Diagram Labels UML 2.5b1 UML 2.5 Resolved closed
UML25-545 Labels for generalization sets in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-541 Classifier and state annotations in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-540 Dashed interaction lifelines in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-532 Action operation redefinition is invalid UML 2.5b1 UML 2.5 Resolved closed
UML25-531 Association::endType() is inconsistent UML 2.5b1 UML 2.5 Resolved closed
UML25-534 Improve documentation of how derived properties are calculated UML 2.5b1 UML 2.5 Resolved closed
UML25-533 The resolution to 18697 contains errors UML 2.5b1 UML 2.5 Resolved closed
UML25-544 Template parameter rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-543 Ownership of property qualifier rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-542 Dependencies with more than two ends in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-432 Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9 UML 2.4.1 UML 2.5 Resolved closed
UML25-431 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-424 Location: 18.1.4 Notation P. 688 - Point to diagram (03) UML 2.4.1 UML 2.5 Resolved closed
UML25-423 Location: 18.1.4 Notation P. 688 - Point to diagram (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-429 Location: 18.1.4 Notation P. 688 - Point to diagram (08) UML 2.4.1 UML 2.5 Resolved closed
UML25-428 Location: 18.1.4 Notation P. 688 - Point to diagram (07) UML 2.4.1 UML 2.5 Resolved closed
UML25-427 Location: 18.1.4 Notation P. 688 - Point to diagram (06) UML 2.4.1 UML 2.5 Resolved closed
UML25-426 Location: 18.1.4 Notation P. 688 - Point to diagram (05) UML 2.4.1 UML 2.5 Resolved closed
UML25-430 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem» UML 2.4.1 UML 2.5 Resolved closed
UML25-436 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-435 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-425 Location: 18.1.4 Notation P. 688 - Point to diagram (04) UML 2.4.1 UML 2.5 Resolved closed
UML25-433 Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-434 Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG UML 2.4.1 UML 2.5 Resolved closed
UML25-483 UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope" UML 2.5b1 UML 2.5 Resolved closed
UML25-482 Fixed-point issues with the definition of default values for literals UML 2.5b1 UML 2.5 Resolved closed
UML25-475 Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical. UML 2.5b1 UML 2.5 Resolved closed
UML25-474 UML association semantics vis-a-vis Interfaces (and other types of classifiers) UML 2.5b1 UML 2.5 Resolved closed
UML25-473 confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”. UML 2.5b1 UML 2.5 Resolved closed
UML25-470 Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi UML 2.4.1 UML 2.5 Resolved closed
UML25-469 ConnectableElement-end" has @isOrdered='true' UML 2.4.1 UML 2.5 Resolved closed
UML25-472 The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance UML 2.5b1 UML 2.5 Resolved closed
UML25-471 UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications UML 2.5b1 UML 2.5 Resolved closed
UML25-478 Notation for state machine specializations UML 2.5b1 UML 2.5 Resolved closed
UML25-477 UML2.5 issue : missing constraints on aggregation / composition UML 2.5b1 UML 2.5 Resolved closed
UML25-476 Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example UML 2.5b1 UML 2.5 Resolved closed
UML25-481 Error in Dependency notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-480 Error in diagram using StringExpressions UML 2.5b1 UML 2.5 Resolved closed
UML25-479 Inconsistent template binding notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-468 UML2.5: clarification about the semantics of redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-467 Lifeline has no type. UML 2.4.1 UML 2.5 Resolved closed
UML25-466 Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col UML 2.4.1 UML 2.5 Resolved closed
UML25-484 UML 2.5 issue; the word "individual" is incorrect in 9.8 UML 2.5b1 UML 2.5 Resolved closed
UML25-451 Location: B.4.4 State Shapes P. 752 - State List Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-450 Location: B.2.4 P. 739 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-441 Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754 UML 2.4.1 UML 2.5 Resolved closed
UML25-440 Location: 21.1 Summary P. 726 - Missing header UML 2.4.1 UML 2.5 Resolved closed
UML25-438 Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard UML 2.4.1 UML 2.5 Resolved closed
UML25-437 Location: 18.1.1 Summary p 685 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-445 Location: Table 21-1 String P. 726 UML 2.4.1 UML 2.5 Resolved closed
UML25-444 Location: Table 21-1 P. 726 - Title of table not great UML 2.4.1 UML 2.5 Resolved closed
UML25-443 Location: 21.2 Semantics P. 726 - Subsection title UML 2.4.1 UML 2.5 Resolved closed
UML25-442 Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation UML 2.4.1 UML 2.5 Resolved closed
UML25-448 Location: Figure 21-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-447 Location: Table 21-1 P. 726 - Row ordering UML 2.4.1 UML 2.5 Resolved closed
UML25-446 Location: Table 21-1 Unlimited Natural P. 726 - Infinity UML 2.4.1 UML 2.5 Resolved closed
UML25-439 Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types? UML 2.4.1 UML 2.5 Resolved closed
UML25-449 Location: B.2.3 P. 738 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-595 Active and passive UML 1.4.2 UML 2.5 Resolved closed
UML25-594 P.58 Missing closing bracket in second constraint UML 1.4.2 UML 2.5 Resolved closed
UML25-592 "required interface" UML 2.0 UML 2.5 Resolved closed
UML25-591 Compliance points - Diagram Interchange UML 1.4.2 UML 2.5 Resolved closed
UML25-596 UML 2 does not permit use of a state machine UML 2.0 UML 2.5 Resolved closed
UML25-598 included use case wrongly referred to as the including use case UML 1.4.2 UML 2.5 Resolved closed
UML25-597 check the BNF example given in the text UML 1.4.2 UML 2.5 Resolved closed
UML25-590 Bidirectional messages to a port object UML 1.4.2 UML 2.5 Resolved closed
UML25-589 Figures 120 and 121 UML 1.4.2 UML 2.5 Resolved closed
UML25-600 "role binding" UML 2.0 UML 2.5 Resolved closed
UML25-599 multiplicity of the "role:ConnectableElement" UML 2.0 UML 2.5 Resolved closed
UML25-593 P.35 Typo in OCL definition of isDistinguishableFrom query UML 1.4.2 UML 2.5 Resolved closed
UML25-553 misleading omission UML 2.5b1 UML 2.5 Resolved closed
UML25-552 Validation errors in UML metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-547 PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value UML 2.5b1 UML 2.5 Resolved closed
UML25-549 Assocation display options too narrow UML 2.5b1 UML 2.5 Resolved closed
UML25-548 Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI UML 2.5b1 UML 2.5 Resolved closed
UML25-551 UML 2.5 issue: subsettingContext() has incorrect logic UML 2.5b1 UML 2.5 Resolved closed
UML25-550 Headed composite and not ownedElement UML 2.5b1 UML 2.5 Resolved closed
UML25-554 Activity::structuredNode is incorrectly marked as readOnly = true UML 2.5b1 UML 2.5 Resolved closed
UML25-456 Location: Annex C Keywords p 777 - Capitalization of «trace» UML 2.4.1 UML 2.5 Resolved closed
UML25-455 Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex UML 2.4.1 UML 2.5 Resolved closed
UML25-453 Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval. UML 2.4.1 UML 2.5 Resolved closed
UML25-452 Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763 UML 2.4.1 UML 2.5 Resolved closed
UML25-458 Location: Table B.1 UML Keywords p 778 - Keywords should be in index UML 2.4.1 UML 2.5 Resolved closed
UML25-457 Location: Annex C Keywords p 777 - Capitalization of «create» UML 2.4.1 UML 2.5 Resolved closed
UML25-464 Location: Index p. 796 among others - Index items with only one page UML 2.4.1 UML 2.5 Resolved closed
UML25-463 Location: Index p 795 - Index of "is" UML 2.4.1 UML 2.5 Resolved closed
UML25-460 Location: Index UML 2.4.1 UML 2.5 Resolved closed
UML25-459 Location: Annex C Keywords P. 780 - Bizarre definition of statemachine UML 2.4.1 UML 2.5 Resolved closed
UML25-454 Location B.6 UMLStateShape statelist p 770 - StateList Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-462 Location: Index p 793 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-465 Location: Index Mis. - Missing terms in the Index UML 2.4.1 UML 2.5 Resolved closed
UML25-461 Type: Structural - Location Index p 790, 794, UML 2.4.1 UML 2.5 Resolved closed
UML25-394 Location: 15.5.1 - typo UML 2.4.1 UML 2.5 Resolved closed
UML25-393 Location: Figure 15.57 page 426 UML 2.4.1 UML 2.5 Resolved closed
UML25-399 Location: 17.2.3 Semantics Interaction Fragments p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-398 17.1.5 Interaction Diagram Variants p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-397 Location: p 484 - Exception store UML 2.4.1 UML 2.5 Resolved closed
UML25-396 Location: Figure 15-23 p.411 UML 2.4.1 UML 2.5 Resolved closed
UML25-391 Location: Figure 15-23 UML 2.4.1 UML 2.5 Resolved closed
UML25-390 Location: p. 357 StateMachine Redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-389 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-388 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-395 Location: Figure 15-63 UML 2.4.1 UML 2.5 Resolved closed
UML25-387 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-392 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 UML 2.5 Resolved closed
UML25-386 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-317 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-316 What is aggregation UML 2.4.1 UML 2.5 Resolved closed
UML25-311 inout parameters and effects UML 2.4.1 UML 2.5 Resolved closed
UML25-310 Effect Intent UML 2.4.1 UML 2.5 Resolved closed
UML25-308 Return Parameter order UML 2.4.1 UML 2.5 Resolved closed
UML25-307 Default value of readonly should be referenced UML 2.4.1 UML 2.5 Resolved closed
UML25-313 Parameter Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-312 isException and direction and effect UML 2.4.1 UML 2.5 Resolved closed
UML25-320 Location: 9.5.3 p 122 In the common case UML 2.4.1 UML 2.5 Resolved closed
UML25-319 Location: 9.5.3 p 121 Why not all empty UML 2.4.1 UML 2.5 Resolved closed
UML25-314 Use isReadOnly default UML 2.4.1 UML 2.5 Resolved closed
UML25-315 Redefinition does not allow for overloading UML 2.4.1 UML 2.5 Resolved closed
UML25-318 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-309 Return Parameter pronoun UML 2.4.1 UML 2.5 Resolved closed
UML25-223 Two categories is not enough UML 2.4.1 UML 2.5 Resolved closed
UML25-222 UML Semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-224 Semantics Areas section not clear UML 2.4.1 UML 2.5 Resolved closed
UML25-413 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined UML 2.4.1 UML 2.5 Resolved closed
UML25-412 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate UML 2.4.1 UML 2.5 Resolved closed
UML25-411 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory? UML 2.4.1 UML 2.5 Resolved closed
UML25-405 Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages UML 2.4.1 UML 2.5 Resolved closed
UML25-404 Pg. 613, Clause 17.3.4: Notation UML 2.4.1 UML 2.5 Resolved closed
UML25-403 Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5 UML 2.4.1 UML 2.5 Resolved closed
UML25-402 Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability UML 2.4.1 UML 2.5 Resolved closed
UML25-410 Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system UML 2.4.1 UML 2.5 Resolved closed
UML25-409 General value lifeline Row p 647 UML 2.4.1 UML 2.5 Resolved closed
UML25-408 Location: Table 17.6 entire table p 646 UML 2.4.1 UML 2.5 Resolved closed
UML25-401 Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5) UML 2.4.1 UML 2.5 Resolved closed
UML25-400 Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color UML 2.4.1 UML 2.5 Resolved closed
UML25-407 Location: LostMessage Row p 639 UML 2.4.1 UML 2.5 Resolved closed
UML25-406 Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-264 Default value for LiteralString UML 2.4.1 UML 2.5 Resolved closed
UML25-263 Optional String Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-256 Excessive null checks UML 2.4.1 UML 2.5 Resolved closed
UML25-255 Single and set of aren't really parallel UML 2.4.1 UML 2.5 Resolved closed
UML25-252 Missing a UML 2.4.1 UML 2.5 Resolved closed
UML25-251 inconsistent spacing on diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-260 TypedElement description could be expanded UML 2.4.1 UML 2.5 Resolved closed
UML25-259 It seems to me that a relationship requires a minimum of two relatedElements UML 2.4.1 UML 2.5 Resolved closed
UML25-254 Use of the diamond symbol (?)needs to be explained UML 2.4.1 UML 2.5 Resolved closed
UML25-253 Instantiate Dependency UML 2.4.1 UML 2.5 Resolved closed
UML25-261 Generalization Relationship to itself? UML 2.4.1 UML 2.5 Resolved closed
UML25-262 Negatively phrased sentence UML 2.4.1 UML 2.5 Resolved closed
UML25-258 Sentence difficult to read UML 2.4.1 UML 2.5 Resolved closed
UML25-257 allNamespace description doesn't match OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-338 Location p 152 Generalization Attributes: IsSubstitutable UML 2.4.1 UML 2.5 Resolved closed
UML25-340 Location p 153 complete_and_disjoint: Abstract Implication UML 2.4.1 UML 2.5 Resolved closed
UML25-339 Location p 153 complete_and_disjoint: Complete vs covering? UML 2.4.1 UML 2.5 Resolved closed
UML25-334 Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks UML 2.4.1 UML 2.5 Resolved closed
UML25-333 Location: p 145 (3X) Detail: simultaneously -- > concurrently UML 2.4.1 UML 2.5 Resolved closed
UML25-337 Location p 146 Classifier Description: isAbstract UML 2.4.1 UML 2.5 Resolved closed
UML25-336 Location p 145 Classifier Description: objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-343 Location p 162 two_parameter_sets: Why UML 2.4.1 UML 2.5 Resolved closed
UML25-342 Location p 157 isConsistentWith: missing rules UML 2.4.1 UML 2.5 Resolved closed
UML25-341 Location p 154 Association Ends: Instances of multiple classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-344 Location p 162 ParameterSet constraints input: Exceptions and parameterset UML 2.4.1 UML 2.5 Resolved closed
UML25-335 Location p 145 Classifier Description - objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-249 While-->And UML 2.4.1 UML 2.5 Resolved closed
UML25-248 Unclear description of multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-243 Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-242 ElementImport cannot be further imported UML 2.4.1 UML 2.5 Resolved closed
UML25-247 Confusing description of types UML 2.4.1 UML 2.5 Resolved closed
UML25-238 Note refers to an undiscussed concept UML 2.4.1 UML 2.5 Resolved closed
UML25-240 Packageable Elements and Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-239 Missing word UML 2.4.1 UML 2.5 Resolved closed
UML25-246 Missing TypedElement - use of the term constrained seems to be circular UML 2.4.1 UML 2.5 Resolved closed
UML25-245 Missing TypedElement UML 2.4.1 UML 2.5 Resolved closed
UML25-250 Missing OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-241 Packageable Elements and Imports (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-244 Incorrect text describing diagram elements UML 2.4.1 UML 2.5 Resolved closed
UML25-358 Location 13.1 Summary p 305 - Use of the word “emergent” UML 2.4.1 UML 2.5 Resolved closed
UML25-357 Operations p 245 (2X) typo UML 2.4.1 UML 2.5 Resolved closed
UML25-355 Location Figure 11-23 s p.217 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-354 Location Figure 11-22 s p.216 - Title doesn’t match contents UML 2.4.1 UML 2.5 Resolved closed
UML25-351 Location: Constraints p 193 - Missing constraint? UML 2.4.1 UML 2.5 Resolved closed
UML25-350 Location 10.4.4 Notations p.188 - Reception compartment UML 2.4.1 UML 2.5 Resolved closed
UML25-349 Location 10.3.3 Signals p.186 UML 2.4.1 UML 2.5 Resolved closed
UML25-348 10.2.4 Notation p 184. - Enumeration attributes and operations UML 2.4.1 UML 2.5 Resolved closed
UML25-346 Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals UML 2.4.1 UML 2.5 Resolved closed
UML25-347 Location: 10.2.4 Notation p 184 UML 2.4.1 UML 2.5 Resolved closed
UML25-353 Location Figure 11-21 s p.216 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-356 Location Figure 11-23 s p.217 - Instance/roll names (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-352 Location: Figure 11-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-281 Wrong Reference UML 2.4.1 UML 2.5 Resolved closed
UML25-280 missing headings UML 2.4.1 UML 2.5 Resolved closed
UML25-290 Min/Max UML 2.4.1 UML 2.5 Resolved closed
UML25-289 Two anonymous invariants UML 2.4.1 UML 2.5 Resolved closed
UML25-292 8.6 p 100 isCompatibleWith() ..save space UML 2.4.1 UML 2.5 Resolved closed
UML25-291 Save Space UML 2.4.1 UML 2.5 Resolved closed
UML25-288 result() error UML 2.4.1 UML 2.5 Resolved closed
UML25-287 French UML 2.4.1 UML 2.5 Resolved closed
UML25-284 Invariant name UML 2.4.1 UML 2.5 Resolved closed
UML25-283 Improve readability of constraint names UML 2.4.1 UML 2.5 Resolved closed
UML25-295 Association Descriptions not that useful UML 2.4.1 UML 2.5 Resolved closed
UML25-294 IsNull not Boolean UML 2.4.1 UML 2.5 Resolved closed
UML25-282 Duration Definition UML 2.4.1 UML 2.5 Resolved closed
UML25-286 Set--> List UML 2.4.1 UML 2.5 Resolved closed
UML25-285 Why is value optional UML 2.4.1 UML 2.5 Resolved closed
UML25-293 Turing Machine lurking paradox? UML 2.4.1 UML 2.5 Resolved closed
UML25-323 Location: 9.6.3 Operations p 127 Undefined ? UML 2.4.1 UML 2.5 Resolved closed
UML25-322 Location: 9.5.3 p 121 Can’t qualifiers be queries? UML 2.4.1 UML 2.5 Resolved closed
UML25-330 Location: 9.8.4 Notation p 141 UML 2.4.1 UML 2.5 Resolved closed
UML25-329 Location: 9.8.3 Semantics p 139 UML 2.4.1 UML 2.5 Resolved closed
UML25-326 Location: 9.6.4 Notation p 128 Is return a reserved parameter name? UML 2.4.1 UML 2.5 Resolved closed
UML25-325 Location: 9.6.4 Notation p 127 Simplify description of syntax UML 2.4.1 UML 2.5 Resolved closed
UML25-321 Location: 9.5.3 p 122 Qualifiers must be enumerated type UML 2.4.1 UML 2.5 Resolved closed
UML25-324 Location: 9.6.3 Operations p 127 UML 2.4.1 UML 2.5 Resolved closed
UML25-328 Location: 9.7.5 Examples p 135 Political Correctness UML 2.4.1 UML 2.5 Resolved closed
UML25-327 Location: 9.7.5 Examples p 134 Generalization Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-331 Location: 9.8.4 Notation p 141 representing the roles vs representing the instances UML 2.4.1 UML 2.5 Resolved closed
UML25-332 Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-237 Clarification of imports UML 2.4.1 UML 2.5 Resolved closed
UML25-236 Namespace Abstract Syntax incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-230 Add reference to association notation section UML 2.4.1 UML 2.5 Resolved closed
UML25-229 How does dot notation work UML 2.4.1 UML 2.5 Resolved closed
UML25-227 Extraneous Note UML 2.4.1 UML 2.5 Resolved closed
UML25-226 Sentence does not make sense UML 2.4.1 UML 2.5 Resolved closed
UML25-233 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-232 Root Abstract Syntax missing adornments/metamodel incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-234 Owning Rules UML 2.4.1 UML 2.5 Resolved closed
UML25-231 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-225 Figure 6.1 does not relate to rest of Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-235 Can Comments own comments? UML 2.4.1 UML 2.5 Resolved closed
UML25-228 What type of slash? UML 2.4.1 UML 2.5 Resolved closed
UML25-367 Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind UML 2.4.1 UML 2.5 Resolved closed
UML25-366 Location: Page 329 States - Stable UML 2.4.1 UML 2.5 Resolved closed
UML25-362 Location: Page 315 Association ends - Explain about having no nestedClassifier UML 2.4.1 UML 2.5 Resolved closed
UML25-361 Location: Page 313, 13.2.4 Notation relative UML 2.4.1 UML 2.5 Resolved closed
UML25-369 Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states UML 2.4.1 UML 2.5 Resolved closed
UML25-365 Location: Page 328 Regions 14.2.3 - Text about regions without initial state UML 2.4.1 UML 2.5 Resolved closed
UML25-371 Location: Page 346, State List Notations UML 2.4.1 UML 2.5 Resolved closed
UML25-370 Location: Page 341, State - More examples needed UML 2.4.1 UML 2.5 Resolved closed
UML25-368 Location: Page 338, Transition selection algorithm - Maximal Set UML 2.4.1 UML 2.5 Resolved closed
UML25-364 Location: 14.2.1 Summary - Behavior StateMachines for UseCases UML 2.4.1 UML 2.5 Resolved closed
UML25-363 Location: 14.1 Summary p 326 UML 2.4.1 UML 2.5 Resolved closed
UML25-360 Location Behavior Parameters p 307 - Streaming and Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-359 Location Behavior Parameters p 307 - Optional with default value UML 2.4.1 UML 2.5 Resolved closed
UML25-304 Alterative Scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-303 Multiplicity of 0..0 UML 2.4.1 UML 2.5 Resolved closed
UML25-301 Location p.112 (9.3 Classifier Templates) UML 2.4.1 UML 2.5 Resolved closed
UML25-300 Incompatible with SysML UML 2.4.1 UML 2.5 Resolved closed
UML25-297 the parent of a Classifier is not its owner.” UML 2.4.1 UML 2.5 Resolved closed
UML25-302 Location: p.116 (9.4.3 Semantics) UML 2.4.1 UML 2.5 Resolved closed
UML25-298 What is inherited or not UML 2.4.1 UML 2.5 Resolved closed
UML25-299 Inherited members UML 2.4.1 UML 2.5 Resolved closed
UML25-306 Redefinable Static attributes UML 2.4.1 UML 2.5 Resolved closed
UML25-305 Examples of alternative scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-296 Objects? UML 2.4.1 UML 2.5 Resolved closed
UML25-378 Location: p. 329 State Configurations UML 2.4.1 UML 2.5 Resolved closed
UML25-377 Location: p. 328 Regions - Resolve intentional ambiguity UML 2.4.1 UML 2.5 Resolved closed
UML25-373 Location: Transition , bottom of page 352 UML 2.4.1 UML 2.5 Resolved closed
UML25-372 Location: Page 347, 14.2.4 UML 2.4.1 UML 2.5 Resolved closed
UML25-376 Location: p 378 State Description - What is hidden? UML 2.4.1 UML 2.5 Resolved closed
UML25-375 Location: p 373 outgoing_from_initial - Limitations on guards UML 2.4.1 UML 2.5 Resolved closed
UML25-374 Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-382 Location: p. 333 FinalState UML 2.4.1 UML 2.5 Resolved closed
UML25-381 Location: p. 331 Exiting a State - Clarification of Exiting a State UML 2.4.1 UML 2.5 Resolved closed
UML25-385 Location: p. 337 2nd ¶ UML 2.4.1 UML 2.5 Resolved closed
UML25-384 Location: p. 336 Compound transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-383 Location: p. 333 Transitions - How do multiple triggers work? UML 2.4.1 UML 2.5 Resolved closed
UML25-379 Location: p. 330 Deferred Events - Value of Deferred Events UML 2.4.1 UML 2.5 Resolved closed
UML25-380 Location: p. 331 Explicit Entry - Clarification of Explicit Entry UML 2.4.1 UML 2.5 Resolved closed
UML25-268 Unlimited Natural UML 2.4.1 UML 2.5 Resolved closed
UML25-267 String concrete syntax is missing UML 2.4.1 UML 2.5 Resolved closed
UML25-270 BNF rules allow for a real 0 UML 2.4.1 UML 2.5 Resolved closed
UML25-269 Notation: Real UML 2.4.1 UML 2.5 Resolved closed
UML25-266 LiteralNull semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-265 Default value for LiteralReal UML 2.4.1 UML 2.5 Resolved closed
UML25-279 Always non-negative UML 2.4.1 UML 2.5 Resolved closed
UML25-278 Duration UML 2.4.1 UML 2.5 Resolved closed
UML25-274 set - > list UML 2.4.1 UML 2.5 Resolved closed
UML25-273 Plural headers when class name is singular UML 2.4.1 UML 2.5 Resolved closed
UML25-276 body text strings UML 2.4.1 UML 2.5 Resolved closed
UML25-275 sentence unclear UML 2.4.1 UML 2.5 Resolved closed
UML25-271 Past vs Present UML 2.4.1 UML 2.5 Resolved closed
UML25-277 String expression notation missing UML 2.4.1 UML 2.5 Resolved closed
UML25-272 {ordered} at wrong end UML 2.4.1 UML 2.5 Resolved closed
UML25-219 Incarnation ? UML 2.4.1 UML 2.5 Resolved closed
UML25-218 Show how UML is a MOF metamodel UML 2.4.1 UML 2.5 Resolved closed
UML25-214 Conformance definitions ? UML 2.4.1 UML 2.5 Resolved closed
UML25-213 Impact of merging profiles isn't small UML 2.4.1 UML 2.5 Resolved closed
UML25-217 Keyword Usage UML 2.4.1 UML 2.5 Resolved closed
UML25-216 ISO version of UML 2? UML 2.4.1 UML 2.5 Resolved closed
UML25-220 Within the System UML 2.4.1 UML 2.5 Resolved closed
UML25-212 Capture Submitters, Supporters, etc UML 2.4.1 UML 2.5 Resolved closed
UML25-221 Modeling Individuals UML 2.4.1 UML 2.5 Resolved closed
UML25-215 DI Conformance implies Model Interchange Conformance UML 2.4.1 UML 2.5 Resolved closed
UML25-191 Clarification on the semantics of Multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-190 Clarification on the semantics of UML UML 2.4.1 UML 2.5 Resolved closed
UML25-189 Conformance point UML 2.4.1 UML 2.5 Resolved closed
UML25-193 Clarification on the semantics of Properties UML 2.4.1 UML 2.5 Resolved closed
UML25-192 Clarification on the semantics of Parameters UML 2.4.1 UML 2.5 Resolved closed
UML25-197 Clarification on the semantics of Manifestation UML 2.4.1 UML 2.5 Resolved closed
UML25-196 Clarification on the aim of Collaborations UML 2.4.1 UML 2.5 Resolved closed
UML25-195 Clarification on the semantics of ports in Encapsulated Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-194 Clarification on the semantics of Connectors within Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-198 Declassifying of Annex D UML 2.4.1 UML 2.5 Resolved closed
UML25-200 Missing word in section 7.4.3, "Semantics" UML 2.5b1 UML 2.5 Resolved closed
UML25-199 Four typos UML 2.5b1 UML 2.5 Resolved closed
UML25-206 ElementImport semantics UML 2.5b1 UML 2.5 Resolved closed
UML25-205 Same name" vs. "indistinguishable name" UML 2.5b1 UML 2.5 Resolved closed
UML25-211 Missing Table of Figures, Table of Tables - Location: TOC p 10 UML 2.4.1 UML 2.5 Resolved closed
UML25-210 Minor vs Major revision UML 2.4.1 UML 2.5 Resolved closed
UML25-204 Further clarify Element ownership constrains UML 2.5b1 UML 2.5 Resolved closed
UML25-203 Semantic conformance implies Abstract Syntax conformance UML 2.5b1 UML 2.5 Resolved closed
UML25-207 isConsistentWith() definition broken UML 2.5b1 UML 2.5 Resolved closed
UML25-202 Suggested improvements to conformance section UML 2.5b1 UML 2.5 Resolved closed
UML25-209 Section 11.5. - Clause 11: Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-201 PDF links to Primitive Types don't work UML 2.5b1 UML 2.5 Resolved closed
UML25-208 Superfluous word on p309 UML 2.5b1 UML 2.5 Resolved closed

Issues Descriptions

Location: 9.6.4 Notation p 128: Confusing indentation

  • Key: UML25-345
  • Legacy Issue Number: 17930
  • Status: closed  
  • Source: Dassault Systemes ( Mr. James L. Logan III)
  • Summary:

    The line

    "[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]]"

    has its terms defined under the bulleted list after the first un-indented "where", except for "<parameter-list>".

    That term is defined one level too deep, where "<oper-property>" terms are defined.

    The bullet found there (i.e., "<parameter-list> is a list of Parameters of the Operation in the following format:") should become the third bullet in the first level of bullets.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:
  • Updated: Sun, 28 Feb 2016 17:14 GMT

Typo in Interaction Example

  • Key: UML25-684
  • Legacy Issue Number: 19348
  • Status: closed  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    v=mymsg(w=myout:16):96

    // this is a reply message assigning the return value 69 to 'v'

    Either the 96 needs to be a 69 or vice-versa but the two should match.

  • Reported: UML 2.5b1 — Sun, 20 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Thu, 12 Mar 2015 01:57 GMT

InformationFlow cannot have an Activity as source or target

  • Key: UML25-682
  • Legacy Issue Number: 18743
  • Status: closed  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    In section 17.2.1 InformationFlow (from InformationFlows) page 621, the first constraint states that "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact,
    Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except
    when its classifier is a relationship (i.e., it represents a link).". Why can't an Activity be the source or target of an InformationFlow, since it is a Behavior as an Use Case?

  • Reported: UML 2.4.1 — Wed, 29 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate, issue closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

  • Key: UML25-681
  • Legacy Issue Number: 17928
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate of 17927, withdrawn and closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

Profile::references_same_metamodel

  • Key: UML25-680
  • Legacy Issue Number: 18809
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Profile::references_same_metamodel

    All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

    inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()->

    union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

    Surely this OCL is completely wrong, both in its own right, and especially in the light of the following statement:

    Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

    I’m thinking the right logic would be something like this:

    (metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

    and

    metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18806 --withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Operation::isConsistentWith()

  • Key: UML25-679
  • Legacy Issue Number: 18807
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

    The current definition is this:

    isConsistentWith(redefinee : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

    pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

    let op : Operation = redefinee.oclAsType(Operation) in

    self.ownedParameter->size() = op.ownedParameter->size() and

    Sequence

    {1..self.ownedParameter->size()}

    ->

    forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

    What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

    The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

    There seem to me to be three approaches here.

    1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

    2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

    3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

    Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    issue withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

redefined states

  • Key: UML25-678
  • Legacy Issue Number: 18757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems State can be redefined in one subtype only, because of multiplicity 0..1 of the "state" (see picture attached).
    That prevents from creating two subclasses which redefine the same states in inherited statemachine and our customers report the problem.

    I think, multiplicity should be changed to *.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18455, issue closed by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Event pools for passive objects?

  • Key: UML25-677
  • Legacy Issue Number: 18755
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18754

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Who owns MessageEnds?

  • Key: UML25-676
  • Legacy Issue Number: 18734
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that the metamodel does not have any composite property typed by MessageEnd.

    Since MessageEnd is a kind of NamedElement, we'd need to have a composite association to subset A_ownedMember_namespace.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Problems with OCL definition of Package::makesVisible

  • Key: UML25-672
  • Legacy Issue Number: 19069
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
    I see problems with definition of Package::makesVisible - which is expressed in OCL.:

    makesVisible(el : NamedElement) : Boolean
    The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
    pre: member->includes(el)
    body: ownedMember->includes(el) or
    (elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
    (packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

    Actually those problems carry on from the previous versions of UML;
    but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
    I assumed this section is old/abandoned and did not pay much attention to it.

    But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
    But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
    If we are updating OCLs anyway, I think it would be a good time to also correct those.

    So here goes:

    --------------------------------------------------------------------------------
    Problem #1

    the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

    ei.importedElement = VisibilityKind::public

    The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
    I think this passage should be restated as follows:

    ei.visibility= VisibilityKind::public

    i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

    Also the whole case handling element imports could be rewritten to simplify it:
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
    This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
    checking whether imported element matches the element el.

    --------------------------------------------------------------------------------
    Problem #2
    the case handling package imports (line #3 of the body) is also borked:

    packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

    Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

    packageImport->select(visibility = VisibilityKind::public)
    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()
    here expression part

    importedPackage.member->includes(el)

    produces a boolean - whether element el is included among the members of the package being imported.
    So the result of the expression part

    ...>collect(importedPackage.member>includes(el))...
    is a collection of booleans (of the form:

    {false, false, true, false, true}

    ),
    where each boolean signifies whether element is among the members of each particular imported package.

    Then it makes no sense to test that for emptiness:

    ->notEmpty()
    this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
    So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

    I think this passage should be restated as follows:

    packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))
    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

    --------------------------------------------------------------------------------

    So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

    pre: member->includes(el)
    body:
    ownedMember->includes(el) or
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
    packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

  • Reported: UML 2.5b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

an instance spec should be a legitimate value of a property typed by a classifier

  • Key: UML25-671
  • Legacy Issue Number: 17565
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    To put it simply, I'm saying this:

    The spec should clearly state that an instance spec is a legitimate value
    of a property typed by a classifier.
    The spec should make sure that the abstract syntax operations &
    constraints involving all kinds of UML classifiers & instance
    specifications work according to the above.

    The UML spec tacitly agrees with this as shown in several examples:

    Figure 7.54 in UML 2.4.1, page 82.
    Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143

  • Reported: UML 2.4.1 — Mon, 27 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A legitimate value of a property (actually a Slot) is an InstanceValue, which is what is depicted by figures 9.32 and
    9.33.
    Disposition: Closed - No Change

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

A comment is a specialization of Element

  • Key: UML25-668
  • Legacy Issue Number: 17530
  • Status: closed  
  • Source: me.com ( Carlos Prado)
  • Summary:

    In the section diagram is specified that a Comment is a specialization of Element but in the definition of Comment says that Comment have no Generalizations

  • Reported: UML 2.4.1 — Thu, 26 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Surplus classifier field serialized in Superstructure.xmi

  • Key: UML25-667
  • Legacy Issue Number: 17507
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    I've encountered one slight problem in the superstructure XMI file of UML2.4.1 .

    I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here:
    http://www.omg.org/spec/UML/2.4.1/

    On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.:
    > <ownedLiteral xmi:type="uml:EnumerationLiteral"
    > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered"
    > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind">
    There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I
    think there will also be cases like this)

    Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and
    chapter 7.3.17
    (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is
    not derived).

    Since derived fields are not usually serialized by XMI production rules (unless this is overridden,
    which seems not to be the case),
    I think these fields should be cleaned out.

  • Reported: UML 2.4.1 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Attribute is represented by Property

  • Key: UML25-670
  • Legacy Issue Number: 17550
  • Status: closed  
  • Source: gmail.com ( Hongwei Ma)
  • Summary:

    In the "Description" section, it stated that "Attributes of a class are represented by instances of Property that are owned by the class".
    Expected:
    "Attributes of a class are represented by Properties that are owned by the class".

    In page 43: it is stated that "an association end owned by a class is also an attribute".

    In page 36, memberEnd: Property[2..*] indicated that association end is Property.

    In all, I think Attribute is Property, only if the Property is owned by a class.
    It is confusing to mention instance in this context.

  • Reported: UML 2.4.1 — Sat, 11 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Operation "isConsistentWith" is not overridden for any RedefinableElement

  • Key: UML25-669
  • Legacy Issue Number: 17547
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    The operation "isConsistentWith" is not overridden for any RedefinableElement in this chapter. Hence the contraint expression "A redefining element must be consistent with each redefined element." (from RedefinableElement) evaluates to false for any instance.

    Please add an operation for ObjectNode at least.

  • Reported: UML 2.4.1 — Thu, 9 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Question About Arrows In Communication Diagramms

  • Key: UML25-664
  • Legacy Issue Number: 17398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    wonder about the arrows used in communication diagramms (superstructure
    spec, Page 524).
    Do they indicate the type of message - as it is with sequence diagramms
    (sync, async) - or do they indicate the direction of message only.
    I didn't find a statement in the superstructure spec and several UML related
    books offered different oppinions.

  • Reported: UML 2.4.1 — Tue, 29 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Communication diagram can have replies shown, because it can represent any message. There is only the solid arrow
    style in communication diagrams.
    Disposition: Closed - No Change

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

Constraint [1] uses undefined attribute "ownedAttribute

  • Key: UML25-663
  • Legacy Issue Number: 17366
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    An Actor doesn't have an attribute named "ownedAttribute".

  • Reported: UML 2.4.1 — Mon, 14 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15

  • Key: UML25-662
  • Legacy Issue Number: 17333
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Figure 12.15 (on page 370) shows a DataStoreNode (which is a subclass of CentralBufferNode) that is conntected to an action ("Assign Employee").
    But in the description of CentralBufferNode (p. 361) it says: "They do not connect directly to actions".

  • Reported: UML 2.4.1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is obsolete. The description of CentralBufferNode in UML 2.5 no longer contains the sentence “They do
    not connect directly to actions.” (This sentence was intended to mean that ContralBufferNodes are not composed with
    Actions the way Pins are, not that they could not be connected by flows to Actions. But it was admittedly confusing.)
    Disposition: Closed - No Change

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

missing words in section 14.1

  • Key: UML25-665
  • Legacy Issue Number: 17461
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

    This sentence is apparently missing words:
    "through
    interactions in the form of <?????> (e.g., sequence diagrams or similar notations)"

  • Reported: UML 2.4.1 — Thu, 28 Jun 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is now clause 17.1.1 of UML 2.5. Change “through interactions in the form of (e.g., sequence diagrams
    or similar notations).” to “through interactions in the form of sequence diagrams or similar notations

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

Incomplete sentence

  • Key: UML25-673
  • Legacy Issue Number: 19419
  • Status: closed  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In Section 9.6.3 Operations block, there is an incomplete sentence in one of the paragraphs.
    "
    Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, s"

    As you can see the last sentence in the above paragraph is incomplete.

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

DurationObservation#event should be ordered

  • Key: UML25-666
  • Legacy Issue Number: 17466
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

    The UML spec says: "The value of firstEvent[i] is related to event[i]"

    So the "event" feature of DurationObservation should be ordered since the order is significant: we need to refer to it by index.

  • Reported: UML 2.4.1 — Thu, 5 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. While this is a metamodel change, it is necessary for the semantics to make sense.

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

LifeLine instead of Lifeline

  • Key: UML25-661
  • Legacy Issue Number: 17328
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    You wrote "lifeline: LifeLine[0..*]" at page 495 but you should write "lifeline: Lifeline[0..*]".
    The "L" must be in lowercase because it is the correct name of the class that represents a lifeline (as you can see at the 14.3.17 section and in the class diagram at page 475).

  • Reported: UML 2.4.1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2 Super/Templates/Inconsistent organization

  • Key: UML25-607
  • Legacy Issue Number: 7831
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

  • Reported: UML 1.4.2 — Fri, 1 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2 Superstructure -Incompatible use of term link

  • Key: UML25-606
  • Legacy Issue Number: 7825
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The Semantics of Association says:

    "An association declares that there can be links between instances of the
    associated types. 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."

    but in Semantics of Connector the spec states:

    "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 or slots, or because the
    communicating instances are the same instance."

    The small issue is that link is used in incompatible ways which is
    confusing. The bigger issue is that Connectors may be typed by Associations
    and even if there is no actual type, one is "inferred". I would have thought
    that an instance of a Connector (a link) typed by an Association would have
    to be an Association Instance; one possible interpretation of this is that
    an instance of a Connector is only an Association Instance if it has a
    "non-inferred" type, although the value of "inferring" a type seems dubious
    if that is the case. The spec should clarify the situation.

  • Reported: UML 1.4.2 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2.0 Issue: Semantics of Provided and Required Interfaces

  • Key: UML25-604
  • Legacy Issue Number: 7779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In your presentation in Bertinoro you had
    a figure representing the mapping of the classic 'lollipop-notation' for
    provided and required interfaces into stereotyped dependencies between
    the port and the interfaces. I would like to propose that a similar
    picture be included in the specification to make the intent of the
    specification clearer. A good place for this figure would probably be
    9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

  • Reported: UML 1.4.2 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

CollaborationOccurence

  • Key: UML25-603
  • Legacy Issue Number: 7778
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    The ability for a CollaborationOccurence to be owned by an operation is stated in the CollaborationOccurence semantics but doesn't appear in the metamodel (c.f. Figure 100). More I think that the constraints specified for a CollaborationOccurence should be clarified to to take into account that the owner may be an operation.

  • Reported: UML 2.0 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Deployment (from ComponentDeployments, Nodes)

  • Key: UML25-609
  • Legacy Issue Number: 7848
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    Deployment (from ComponentDeployments, Nodes): Associatons: • configuration : deploymentSpecification [*] The specification of properties that parameterize the deployment and execution of one or more Artifacts. This association is specialized from the ownedMember association. There is no "ownedMember" association in inheritance hierarchy of Deployment.

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Dependency associations

  • Key: UML25-608
  • Legacy Issue Number: 7847
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    I think, that Dependency associations must subset (or specialize?): Dependency::client - DirectedRelationship::source Dependency::supplier - DirectedRelationship::target

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

9.3.11 Port (from Ports)

  • Key: UML25-615
  • Legacy Issue Number: 7858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A. All associations here are defined without multiplicity

    the multiplicity is given in the syntax diagram as * so [*] should be added to the text spec.

    B. redefinedPort : Port – subsets Element.redefinedElement.
    Element does not have member ‘redefinedElement’, must changed to be RedefinableElement::redefinedElement or (better yet) Property::redefinedProperty

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

.3.44 Property (from Kernel)

  • Key: UML25-614
  • Legacy Issue Number: 7857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Attribute:

    isReadOnly : Boolean

    This is redundant. Superclass of Property – StructuralFeature (from Kernel) has the same attribute with same default value. I think member isReadOnly can be inherited from StructuralFeature, and no needs define it in the Property.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15781

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

UML2 super/CommonBehavior/Opaque behavior : bad OO modelling

  • Key: UML25-610
  • Legacy Issue Number: 7850
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    When we see the attributes of OpaqueBehavior :
    • body : String [1..*] Specifies the behavior in one or more languages.
    • language : String [*] Languages the body strings use in the same order as
    the body strings.

    We can state that this is bad modelling practice : two attributes are sets,
    which elements have to be related 2 by 2 according to an ordering rule. This
    is even bad database modeling practice (violation of the 1st normal form
    rule).

    Proposition :
    Create an additional class "Language expression", having 2 attributes :
    Language and Body, and relate it to "OpaqueBehavior" instead of these two
    guilty attributes.

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

    Discussion
    The proposed change may be better OO modeling practice, but it would cause a significant backward incompatibility
    for model interchange. Note that the patter of parallel body and language attributes is used not only for OpaqueBehavior,
    but also for OpaqueExpression and OpaqueAction. The cost of making such a change in all these cases does
    not seem worth the benefit of a marginal improvement in modeling practice.
    Disposition: Closed - No Change

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

7.3.24 Interface (from Interfaces)

  • Key: UML25-611
  • Legacy Issue Number: 7854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A.

    Association:

    redefinedInterface : Interface – subsets Element :: redefinedElement

    Element does not have member redefinedElement. Must be: “RedefinableElement :: redefinedElement”.
    Or better yet, change to “Classifier :: redefinedClassifier”.

    B.

    Association:

    ownedAttribute : Property – subsets Namespace.ownedMember and Classifier.feature

    instead of Classifier.feature, ownedAttribute subsets Classifier.attribute. See Figure 9 where Classifier.attribute:Property is annotated as

    {subsets feature}

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2 Superstructure - cross-hair notation for nested classes

  • Key: UML25-605
  • Legacy Issue Number: 7784
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The cross-hair notation is specified as an alternate notation for showing
    the containment of classifiers in packages, but there is no mention of the
    use of this notation for nesting classifiers within classes - this notation
    was present in UML 1.4 and so for backwards compatibility reasons should be
    in 2.0 also. I also note that the cross-hair notation does not appear in the
    diagrams section of Classes.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

9.3.6 Connector (from InternalStructures)

  • Key: UML25-612
  • Legacy Issue Number: 7855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association

    redefinedConnector : Connector [0..*] – subsets Element.redefinedElement

    Element has no redefinedElement association. Change to RedefinableElement::redefinedElement

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

8.3.1 Component (from BasicComponents, PackagingComponents)

  • Key: UML25-613
  • Legacy Issue Number: 7856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association:

    ownedMember : PackageableElement [*]

    Conflicts with Namespace :: ownedMember. Perhaps add a word about redefine?

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers

  • Key: UML25-630
  • Legacy Issue Number: 16581
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Superstructure 2.3 mentions (15.3.14, page 573) a constraint for transitions:

    “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial pseudo state).”

    I think this constraint is too limiting.

    First of all, it is not observed even in the specification:

    On page 546 it says about state lists (15.3.9, page 546):

    “Multiple trigger-free and effect-free transitions originating on a set of states and targeting a junction vertex with a single

    outgoing transition may be presented as a state symbol with a list of the state names and an outgoing transition symbol

    corresponding to the outgoing transition from the junction.”

    Conclusion:

    1) the transition from each of the states in the list cannot have a trigger

    2) the constraint says, that the transition from a junction vertex also cannot have a trigger

    ==> the transitions out of state lists cannot have triggers

    However In figure 15.27 and 15.28 such triggers are shown (e, f, logCard, logVerify).

    Second and more importantly, the described situation of “multiple transitions originating on a set of states and targeting a junction vertex” is quite common and therefore should be allowed, whether or not the modeler wants to use state lists.

    Suggestion

    Transitions from junction vertexes should be an exception to the constraint above. So the constraint on transitions needs to be reformulated:

    Page 573: “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial or of junction pseudo states).”

    Then another constraint needs to be added

    Page 573: “The outgoing transitions of a junction pseudo state may have triggers only, when the incoming transitions originate from states and don’t have triggers.”

  • Reported: UML 2.4.1 — Tue, 4 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Adding triggers to transitions emanating from junction points would contradict the fundamental run-to-completion
    semantics of UML. This would require the execution of a compound transition chain, which is executed in a single
    run-to-completion step by definition, to stop in “mid-stream” at the junction pseudostate to await the arrival of new
    events.
    There is nothing in UML preventing transitions emanating from different source states to converge on a common join
    point (that is what junction points are for), which I think is the capability that the submitter is really asking for. It
    is indeed a very common situation. These transitions may have different triggers or, quite often the same trigger.
    In the latter case, AND ONLY IN THAT CASE, it is possible to use the state-list notation. However, in that case,
    the common trigger is used for the originating “transition” that goes to the common junction point (“transition” is in
    quotes here, because it is really just a notational shortcut for the multiple transitions that share the same trigger but
    originate from different states). From there onwards, it is possible to have different outgoing transitions with different
    guards (but not different triggers) and different effect behaviors.
    Note that neither figure 15.27 nor figure 15.28 are examples of the case where a common junction point is the target
    of the “transition” originating from a state list (instead, they terminate on a State).
    Disposition: Closed - No Change

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

inconsistent Generalization subsections in spec format

  • Key: UML25-622
  • Legacy Issue Number: 7875
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reviewing of the new "generalization" subsections in the UML 2 spec, some are pointing down the inheritance hiearchy and some are pointing up.

    Section 6.5.1 Specification format says these sections are supposed to list the direct generalizations of a concept (see page 14, all the concepts "immediately above" in the hierarchy), yet I find many examples where metaclasses listed in Generalization subsections are the specializations of the concept.

    For example, Section 7.3.3 for Association correctly lists Classifier among its Generalizations, but 7.3.6 BehavioredClassifier(from Interfaces) lists BehavioredClassifier(from BasicBehaviors) thereby pointing down the hierarchy.

    Other examples are too numerous to list. The issue reported below may be another instance of this broader issue.

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

notational standard for {subsets x} in textual contexts

  • Key: UML25-621
  • Legacy Issue Number: 7865
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The text of the UML 2 Finalized Superstructure spec randomly uses dots and doubled-colons, as separator characters, in specifying the metaattribute of a metaassociation end,

    {subsets <x>}


    It also randomly uses or does not use (a) capitalization, as in 'Subsets' and 'subsets', and (b) curly braces. These issues may seem trivial to some human readers but are of consequence wrt any attempt to programmatically navigate structured text..

    Details:

    The dot sometimes used as a navigation path separator, as is correct for OCL, and in other contexts the UML namespace separator, the double-colon, is used.

    Instances of the usage of the dot are at 7.3.5 BehavioralFeature, Association, ownedParameter (which also shows random variation, in not including the curly braces that sometimes set off the subsets property in the textual spec), and of the doubled-colons, at 17.2.1 InformationFlow, Associations target:NamedElement[ ]

    {Subsets DirectedRelationship::target}

    which also shows the occasional use of the curly braces.

    It seems that, since subsets is a relationship between the sets of instances that can qualify for occupying an end of an association, the dot notation, which is used for instance navigation in OCL and in familiar OO programming languages, is correct.

    Another reason for thinking the dot is correct is that the namespace separator implies that the named association end is part of the namespace of the Classifier at the other end, and that seems to imply that the end is navigable. There are some instances in the spec where the namespace separator is used, but wrt a non-navigable end.

    Question:
    what is the "standard" notation in the context of text outside of diagrams?
    Proposal:
    Revise the notation section for Association to make it explicit that the notational standards given there apply in both diagrams and text, and revise the text for consistency. The problem may be that the notational standard does not say whether it applies to text, diagrams, or both.

  • Reported: UML 1.4.2 — Fri, 15 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)

  • Key: UML25-629
  • Legacy Issue Number: 7862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Attributes:

    /isComposite

    /isSimple

    /isSubmachineState

    defined without a type ( it must be Boolean).

    2. Associations:

    redefinedState : State [0..1]

    Must be subsets RedefinableElement::redefinedElement.

    3.

    region : Region [*] – subsets ownedMember

    Must be “subsets Namespace::ownedMember”.

    4.

    /redefinitionContext : Classifier [1]

    This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

    5.

    region : Region [0..1]

    Second member named ‘region’ with another multiplicity and different semantic.

    6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

  • Reported: XMI 1.0 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Notation of enumeration literals

  • Key: UML25-628
  • Legacy Issue Number: 7426
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Notation of enumeration literals The UML Superstructure spec often writes enumeration literal in OCL expressions as a hash mark (#) followed by the name of the enumeration literal, i.e. #public (p. 20) #protected (p. 27) #composite (p.80) #false (p. 215) #unordered (p. 216) #entryPoint (p. 469) #deepHistory (p. 474) etc. Sometimes it also includes enumeration literals consisting of a (fully qualified) enumeration name followed by '::' and the enumeration literal name, i.e. Aggregation::none (p. 69) According to the OCL 2.0 spec, the second notation is correct (see Sec 7.4.2 in the OCL 2.0 spec) Suggestion: replace all occurences of enumeration literal names with a leading '#' by the notation introduced in OCL 2.0.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Disposition: Merged with 18124

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

Associations section of InteractionUse

  • Key: UML25-624
  • Legacy Issue Number: 7879
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Associations section of InteractionUse: Type of argument must be Action instead of InputPin. Add Property string

    {ordered}

    .

  • Reported: UML 2.0 — Sun, 24 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

"Class" should read "Classifier" in Generalization subsection for Behaviore

  • Key: UML25-623
  • Legacy Issue Number: 7876
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference to the October 2005 UML 2 Superstructure Specification as delivered out of the FTF.

    Issue name: "Class" should read "Classifier" in Generalization subsection for BehavioredClassifier.

    Description:

    BehavioredClassifier text specification on page 468 lists generalization as Class (from Kernel)

    However, the syntax diagram Figure 311 on page 459 shows the generalization of BehavioredClassifer as Classifier(from Kernel)

    Figure 314 shows Class as a specialization, not a generalization, for Behaviored Classifier.

    I suspect 'Generalization Class (from Kernel)' on page 468 is an error in the text and it should read 'Generalization Classifier' (from Kernel).

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

15.3.14 Transition (from BehaviorStateMachines)

  • Key: UML25-620
  • Legacy Issue Number: 7864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (different multiplicity).

    2.

    container [1]

    Defined without type (but (wonder?) with multiplicity!). J

    3.

    Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

    But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

  • Reported: XMI 1.0 — Tue, 7 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

15.3.10 Region (from BehaviorStateMachines)

  • Key: UML25-619
  • Legacy Issue Number: 7863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.10 Region (from BehaviorStateMachines)

    Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Figure 307 and Figure 308 are exactly the same

  • Key: UML25-627
  • Legacy Issue Number: 7884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure 307 (Invocation Domain Model) and Figure 308 (Communication Domain Model) are exactly the same ("Copy&Paste error"). Communication Domain Model should be replaced

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

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

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

UML2 Super / Templates / ordering of subExpressions

  • Key: UML25-626
  • Legacy Issue Number: 7882
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StringExpression:subExpression should be ordered

  • Reported: UML 1.4.2 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, it seems that ordering was incorrectly applied to the opposite property StringExpression:: owning-
    Expression instead of StringExpression::subExpression. This should be corrected.

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

15.3.16 Vertex (from BehaviorStateMachines)

  • Key: UML25-617
  • Legacy Issue Number: 7860
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.16 Vertex (from BehaviorStateMachines)

    Associations:

    container : Region [0..1] – subsets Element::owner

    This is a mistake, because Element::owner is already subsetted in parent of Vertex – NamedElement::namespace.

    Must be “subsets NamedElement::namespace”

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Artifact (from Artifacts)

  • Key: UML25-616
  • Legacy Issue Number: 7859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    P#224 – Figure 127 – Artifact (from Artifacts)

    P#769 – Figure 467 – Artifact (from Artifacts)

    Must be “Artifact (from Artifacts, Nodes)” because there is no “Artifact (from Artifacts)” in this document.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2 Super/ Classes / issue with Property::isComposite

  • Key: UML25-625
  • Legacy Issue Number: 7881
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious inconcistency in the specification with respect to Property::isComposite.

    In the description of Association, it states that "Composition is represented by the isComposite attribute on the part end of the association being set to true".

    But in the discussion of structured classifier parts or the discussion of profile extensions it implies the opposite. isComposite should be true for the end that is owned by the whole.

    This will have a serious impact on interchange (among other things) if different implementations put the "black diamond" on different ends of the composition...

  • Reported: UML 1.4.2 — Tue, 26 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

15.3.8 Pseudostate (from BehaviorStateMachines)

  • Key: UML25-618
  • Legacy Issue Number: 7861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.8 Pseudostate (from BehaviorStateMachines)

    Associations:

    stateMachine : Statemachine [0..1] – subsets Element::owner

    Like above: must be “subsets Vertex::container”.
    Type of stateMachine must be StateMachine (letter ‘M’ must be capital).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Modeling sent messages in State Machines

  • Key: UML25-675
  • Legacy Issue Number: 15145
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Adrian Noguero)
  • Summary:

    Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port.
    I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference

  • Reported: UML 2.3b1 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is not entirely clear, but it would seem that the desired capability is available by using an InvocationAction
    with onPort, as now described more fully in the UML 2.5 beta specification in Subclause 16.3.3, under “Invocation
    Actions and Ports”.
    Disposition: Closed - No Change

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

TestIdentityAction for datatypes

  • Key: UML25-674
  • Legacy Issue Number: 14989
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In UML, TestIdentityAction does not currently apply to datatypes. The
    introduction and description of TestIdentityAction say
    "TestIdentifyAction is an action that tests if two values are identical
    objects. This action returns true if the two input values are the same
    identity, false if they are not." Data type values are not objects and
    do not have identity (that is, you cannot tell one data type value from
    another).

    If it is decided that the execution engine should not reflect the above
    semantics, the semantics of TestIdentityAction needs to be extended for
    unstructured datatype values to test whether the values are the same.
    For structured values, such as strings, the values and their contents
    would need to be the same, recursively if they contain more datatype
    values.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of TestIdentityAction in the UML 2.5 beta specification, in
    Subclause 16.4.3, under “Test Identity Actions”, covers the testing of instances of data types.
    Disposition: Closed - No Change

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

Behavior should be derived from Classifier, not Class

  • Key: UML25-660
  • Legacy Issue Number: 17289
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    My previous submission has been resolved. Apparently, the UML spec provides an exception clause in the definition of the /context field to allow the context classifier to propagate downward to sub state machines. I do not know how to find and close the original issue so I'm mentioning it here.

    That said, the semantic issue I raise I believe is still present and is illustrated precisely by the need for that exception clause in the /context field definition. I'd like to propose a much simpler solution.

    A UML Behavior describes the dynamic behavior of its context classifier. All attributes and operations that it class during its execution should come from the context classifier. There is no need for the Behavior to own attributes and operations on its own, and I would like to suggest deriving Behavior directly from Classifier rather than from Class in section 13.3.2. I have not investigated the full impact of such a change, but I believe it would not have any significant impact and would improve the semantic integrity of the model.

    A simple example is that a Behavior has a specification which could be, for example, a call to an Operation. Although the Operation belongs to a Class (its context), would would argue that the Operation is itself a Class?

  • Reported: UML 2.4.1 — Sun, 1 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The proposed change would actually have a significant impact on both the abstract syntax and semantics of Behavior.
    A Behavior may be standalone with no context classifier, in which case it may be useful for the Behavior to have its
    own structural and/or behavioral features. And, even if the Behavior has a context, the features of the Behavior may
    be different than those of the context classifier, relating, for example, to the execution of the Behavior itself rather than
    the state of the context object of the execution, particularly if the execution is asynchronous.
    Disposition: Closed - No Change

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

Package merge on Class metatype causes semantic issues - particularly with state machine context

  • Key: UML25-659
  • Legacy Issue Number: 17283
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    I recently wrote a code generator for my UML tool for state machines. One of the properties of a state machine is called /context, which is the Class that has the state machine as its Classifier Behavior (if any exists). When I created a submachine state, the /context field of the state machine inside the submachine state was listing the parent state machine as its /context, rather than the class owning the parent state machine. This does not make semantic sense, because the purpose of the context field is the allow the state machine to have access to the methods and data of the class that implements the state machine behavior.

    The UML spec says that to find the /context of a state machine, you must travel up the Owner tree until you hit the first Behaviored Classifier. My UML tool vendor pointed out to me that a State Machine is classified as a behaviored Classifier so it qualifies. That did not make sense to me because a State Machine is classified as a Behavior. How can a Behavior also be a class that owns a behavior?

    After checking the UML spec further, I discovered that a Behavior, and therefore a State Machine, is derived from Class (Kernel), which is not a Behaviored Classifier. However, after all the packages are merged, Class (Kernel) gets merged with Class (Communications), which is a Behaviored Classifier, and the merge rules allow the class
    hierarchy to be merged together. I confirmed this anomaly was present in the merged XMI files at OMG website.

    I believe this problem is unique to Class metatype. If you look at Annex F of the UML spec, it shows the complex class hierarchy associated with Classifiers from various packages prior to merging. There are three merge increments for Class in three different places on the tree. These are even called out explicitly in the diagram. You
    can see how the inheritance tree would be changed dramatically when these three Class increments are merged together. All other cases where the metatype increments are merged do not change the structure
    of the inheritance tree. The Class metatype is unique in this respect.

    I thought about a solution and I believe there is an easy fix to this problem. It requires replacing the Class (Communicatoins) increment with a new metatype called BehavioredClass, and replacing the Class (StructuredClasses) increment with the already existing
    EncapsulatedClassifier. After this change, a BehavioredClass would be both a Class (Kernel) and a BehavioredClassifier, as is already illustrated in 13.3.8 but would now be more intuitive. Component would now inherit from Class (Kernel) and EncapsulatedClassifier (Ports). Node would inherit directly from EncapsulatedClassifier, thus preserving the pre-merge idea that Node's should not have data and methods associated with them (as with Class (Kernel)). This is another currently odd outcome of merging the packages together.

    Because Class (Kernel) is a concrete metatype (and therefore shows up in modeling tools), you would need to make BehavioredClass concrete also. Modelers would have to expose it and I think this would be an improvement. I've always felt that active classes (like OS tasks) and
    non-active classes (data and methods only) are such distinct object types that they should have separate representations. The elimination of the Class (StructuredClasses) increment would also prevent the
    merge from adding ports to the generic concept of a Class, which is also desirable since ports are not useful without the ability to represent internal structure.

    After that modification, there are other modifications that would naturally follow. The one I can see is that the isActive attribute of Class would now be a derived attribute which is set to true for classes that inherit BehavioredClass and false otherwise. With this change, in the fully merged UML package, a StateMachine would be derived from Class with only the Kernel attributes. It would no longer falsely inherit from BehavioredClassifier. A whole bunch of other inherited properties that make no sense would also go away.

  • Reported: UML 2.4.1 — Thu, 29 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Error in UML diagrams?

  • Key: UML25-648
  • Legacy Issue Number: 16724
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    If I am not mistaken, there is an error in several UML diagrams.

    Let me start with page 14, figure 7.3: The name of the package on the left side is "Constructs", but it probably should read "Core", shouldn't it?

    This UML diagram seems to be depicted several times in the document cited, which is why the situation is the same in the following places: page 27, second figure; page 29, figure 9.1; page 91, figure 10.1; page 103, figure 11.1.

    Also, on page 162, section 11.9.2, subsection titled "Notation", second bullet point, it reads: "If the members of the package are shown within the large rectangle, then the name of the package should be placed within the tab." This would have to be implemented in the UML diagram(s) referred to above (now, the name "Constructs", that is to be corrected by "Core", is within the rectangle instead of within the tab).

    I would be very glad to receive some feedback on my remarks.

  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Suggestions for editorial changes

  • Key: UML25-647
  • Legacy Issue Number: 16723
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    Reading the document cited, I noticed some editorial errors. Thus, below you will find some suggestions for editorial changes.

    • Page 23, Section 8.3.2, first sentence: Instead of "are enumerated", it should probably read "is enumerated".
    • Page 48, section 9.8.3, subsection titled "Associations": Instead of "owning expression. Subsets", it should probably read "owning expression subsets".
    • Page 96, section 10.2.1, subsection titled "Semantics", second paragraph, first sentence: Instead of "features on another class", it should probably read "features of another class".
    • Page 98, section 10.2.5, subsection titled "Attributes", last bullet point, last sentence: Instead of "Default value", it should read "The default value".
    • Page 111, section 11.3.1, first paragraph, second and third sentences: A space character is missing between the two sentences.
    • Page 113, section 11.3.1, subsection titled "Semantics", sixth paragraph, first sentence: Instead of "characterized", it should read "characterizes".
    • Page 151, section 11.7.5, subsection titled "Examples": Instead of "imported WebShop", it should read "imported to WebShop".
    • Page 154, section 11.8.2, subsection titled "Constraints". Instead of "n operation", it should read "An operation".
    • Page 173, section 12, second paragraph, fifth paragraph: Instead of "profile?s", it should read "profile's".
    • Page 173, section 12, first numbered paragraph, last sentence: Instead of "more constraining", it should read "more constraining than".
    • Page 178, section 12.1.2, subsection titled "Semantics", first paragraph, last sentence: Instead of "at most", it should (probably?) read "at least".
    • Page 186, section 12.1.7, subsection titled "Semantics", last paragraph on page, last sentence: Instead of "and or", it should read "and/or".
    • Page 191, section 12.1.8, subsection titled "Semantics", first paragraph, fourth and fifth sentences: There seems to be a mistake on the boundary between the two sentences ("all its nested and imported."); probably, something is missing at the end of the fourth sentence after "imported".
    • Page 194, section 12.1.9, subsection titled "Semantics", third paragraph on page, second sentence: Instead of "theses stereotypes", it should read "these sstereotypes".
    • Page 194, section 12.1.9, subsection titled "Notation", third paragraph, first sentence: Instead of "stereotype?s", it should read "stereotype's".
    • Page 195, section 12.1.9, subsection titled "Presentation Options", first sentence on page: Instead of "may shown", it should read "may be shown".
    • Page 196, section 12.1.9, subsection titled "Examples", last paragraph on page, second sentence: Before "isRequired", opening quotation marks are missing.
  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

how to instantiate associations between stereotypes

  • Key: UML25-654
  • Legacy Issue Number: 17160
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML says: ” Stereotypes can participate in binary associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel.”

    How are instances of these stereotypes and associations to be serialized?

    For example, look at SysML1.3 in which the stereotype ValueType has an association named A_valueType_unit to the stereotype Unit.

    How is a SysML 1.3 model supposed to instantiate this? There will be an element representing the stereotype instance of this form:

    <sysml:ValueType xmi:id="id1" base_DataType="id2" unit="id3"/>

    What should id3 be the identity of? Presumably the target stereotype instance? Or the model element to which the target stereotype instance is applied?

    Is such an association allowed to be a composition? If so what would be the deletion semantics?

    Also, would we really expect to see any elements of this form?

    <sysml: A_valueType_unit xmi:id="id4" valueType="id1" unit="id5"/>?

    The following sentence: “For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass” appears to imply that we would never see such an element, but I don’t know of any statement to confirm this

  • Reported: UML 2.4.1 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify non-trivial aspects of associations defined in the context of a profile:
    • Serializing instances of associations is optional for XMI.
    • Associations can be composite or not.
    • Clarify the kinds of Types allowed to be defined or imported in a Profile.
    • Instances of stereotypes are owned by the link instance of the composite association corresponding to
    the mapping of the stereotype extension.
    • Fix the incorrect reference to section 14.3 of the MOF Core spec to 14.4 instead.
    Note that clause 12 lacks a notation for instances of Profile-defined Classes, DataTypes and Associations.
    Specifying such notation is a separate issue.

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

Core package caption wrong

  • Key: UML25-653
  • Legacy Issue Number: 17131
  • Status: closed  
  • Source: gmail.com ( Jair Humberto)
  • Summary:

    The caption of the first package(left) of the figure 7.3 is not wrong? The correct should not be Core(instead Construct)? That figure had me confused at the beginning

  • Reported: UML 2.4.1 — Thu, 16 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Add an example for the lifeline head shape

  • Key: UML25-658
  • Legacy Issue Number: 17268
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    It is written that the Lifeline head has a shape that is based on the classifier for the part that this lifeline represents.

    I think you want to tell that we can have a "stick man", if the lifeline represents an Actor.

    It should be good to show an example for a lifeline that represents an Actor (it was the case in UML 1.3 at page 343, Figure 3-48).

  • Reported: UML 2.4.1 — Thu, 22 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 11068

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

color of the notation is specified

  • Key: UML25-657
  • Legacy Issue Number: 17266
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the UML spec there are several places where the color of the notation is specified. For example, the composition diamond is specified as black, the state machines junction ball is specified as black, and the lost/found message is specified as black, and the information identifier is a black triangle.

    Similarly there are few cases where white and grey are specified.

    This is overly limiting, some tools use a solid color for the items specified as black, or let the user select the color (usually selecting the same as the line color). It would not be good to limit the representation to only black color, as that would invalidate most PowerPoint and several tools.

    Please change the color black to “solid” or “filled with the line color” and change “white” to “hollow” or “un-filled”.

    For grey/gray it should be “a distinguishable value between the solid and the hollow”

  • Reported: UML 2.4.1 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Put some clarification into “How to read this specification”.

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

The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/"

  • Key: UML25-656
  • Legacy Issue Number: 17202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I probably discovered a little error in the UML 2.4.1 Superstructure Specification on page 109 in section “Associations” (from Chapter “7.3.38 Package (from Kernel)”):

    The property “packagedElement: PackageableElement [*]” is not a derived property and should therefore not be prefixed with a ‘/’.

  • Reported: UML 2.4.1 — Tue, 28 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Opposite ends of derived unions should be derived unions

  • Key: UML25-655
  • Legacy Issue Number: 17172
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Action::inputPin and Action::outputPin are both derived unions. Both also have opposite association owned ends that are not derived. While I don't think the metamodel is actually incorrect, those owned ends are implicitly derived unions too. So I think it would make more sense to make that explicit.

    I've just picked two examples, however I believe there are more in the specification.

  • Reported: UML 2.4.1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The FTF agrees that the other ends ought to be derived unions. Because all cases of this are associationowned
    ends, this does not affect serialization. There are ten cases of this in the metamodel, which are the
    opposite ends for:
    DirectedRelationship::source
    DirectedRelationship::target
    Classifier::attribute
    StructuredClassifier::role
    Action::input
    Action::output
    RedefinableElement::redefinedElement
    RedefinableElement::redefinitionContext
    Namespace::member
    Relationship::relatedElement

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

Use of term "locus of control"

  • Key: UML25-651
  • Legacy Issue Number: 16946
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    In the semantics of activity, it is written "A token contains an object, datum, or locus of control, and is present in the activity diagram at a particular node." The term "locus of control" seems strange, and I think it should be "focus of control".

  • Reported: UML 2.4.1 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-650
  • Legacy Issue Number: 16875
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

default is wrong

  • Key: UML25-646
  • Legacy Issue Number: 16656
  • Status: closed  
  • Source: gmail.com ( Ooki Kawai)
  • Summary:

    Section [notation] there is a wrong description. [* default is

    {incomplete, disjoint}

    ] is wrong, isn't it? [* default is

    {incomplete, overlapping}

    ] is correct, maybe. Because, [Attributes] says isDisjoint that's default value is false

  • Reported: UML 2.4.1 — Wed, 9 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-645
  • Legacy Issue Number: 16651
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Reference in index to item that does not exist in contents

  • Key: UML25-649
  • Legacy Issue Number: 16725
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    In the internet I found a reference to something called a "SynchState" for state machines. I searched the UM Superstructure but didn't find this defined there, although there is an index entry for it.
    Either the index entry is irrelevant or the state was omitted from the document

  • Reported: UML 2.4.1 — Sun, 27 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

incorrect upper value of coveredBy of Lifeline

  • Key: UML25-652
  • Legacy Issue Number: 17127
  • Status: closed  
  • Source: web.de ( Matthias Schoettle)
  • Summary:

    "coveredBy : InteractionFragment" is stated with a multiplicity of "[0..1]" although in the comment it says "References the InteractionFragments" and the machine readable XMI file of the superstructure has "*" as the value of the upper value of the coveredBy attribute.

  • Reported: UML 2.4.1 — Fri, 10 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

ChangeEvent association mismatch

  • Key: UML25-632
  • Legacy Issue Number: 16590
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    ChangeEvent has defined association changeExpression:Expression[1], but the figure 13.12 depicts the association toward UML::Classes::Kernel::ValueSpecification.

  • Reported: UML 2.4.1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

EnumerationLiterals in the XMI

  • Key: UML25-631
  • Legacy Issue Number: 16584
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

    Even if not derived it would be the inverse of the owning composition so should not be serialized.

  • Reported: UML 2.4.1 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

"A_realization_abstraction_component" is useless

  • Key: UML25-635
  • Legacy Issue Number: 16635
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 8.2, A_realization_abstraction_component appears over Component - ComponentRealization composition line. But this name (association name?) is not used anywhere.

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Subpart I and II are missing in Bookmarks

  • Key: UML25-634
  • Legacy Issue Number: 16634
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Adobe Acrobat Reader, there are no "Subpart I" and "Subpart II" whereas there are "Subpart III" and "Subpart IV" .
    This seems inconsistent

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

default value of ClassifierTemplateParameter#allowSubstitutable is "..."

  • Key: UML25-644
  • Legacy Issue Number: 16650
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 17.13, the default value of ClassifierTemplateParameter#allowSubstitution is truncated to "...".

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Figure 15.2 does not include TransitionKind

  • Key: UML25-643
  • Legacy Issue Number: 16647
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    enumeration TransitionKind should appear in Figure 15.2.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

role "interval" appears "interva"

  • Key: UML25-640
  • Legacy Issue Number: 16644
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    Two association ends "interval" are hidden by class "Interval" and the last letters ("l") are not displayed.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-639
  • Legacy Issue Number: 16643
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    "nonuni..." must be appeared as "nonunique"

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

misspelling: io-oargument

  • Key: UML25-642
  • Legacy Issue Number: 16646
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    It seems that "io-oargument" is misspelling of "io-argument".

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-641
  • Legacy Issue Number: 16645
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    "nonuni..." must be appeared as "nonunique"

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

RedefinableElement (from Kernel) is preferable

  • Key: UML25-636
  • Legacy Issue Number: 16638
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 12.4, RedefinableElement has no note "(from Kernel)". I think all classes that do not belong to BasicActivities should be noted as "(from SomePackage)" within class compartment.

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML Superstructure Specification

  • Key: UML25-633
  • Legacy Issue Number: 16596
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Abstraction class has defined association "mappings" of type Expression, but on page 35, figure 7.15 depicts Abstraction with the association of type OpaqueExpression.

  • Reported: UML 2.4.1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

poor figure resolution and a misspelling: fal...( false )

  • Key: UML25-637
  • Legacy Issue Number: 16639
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    Figure 12.21 blurs. In additon, the default value of LoopNode#isTestedFirst looks "fal...". (I suppose "false").

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

{ordered} is rather far from +bodyOutput

  • Key: UML25-638
  • Legacy Issue Number: 16642
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 12.22, there is "

    {ordered}" near role "+clause". I think {ordered}

    must be located near +bodyOutput, rather than +clause.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

UML 2 Super and Infra/ defualt property of Parameter::effect

  • Key: UML25-601
  • Legacy Issue Number: 7758
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I think it makes sense that the default value of Parameter::effect be 'read' (currently it is not specified).

  • Reported: UML 1.4.2 — Sun, 19 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    There is no need for any default value because Parameter::effect is 0..1.
    Disposition: Closed - No Change

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

Associations between interfaces

  • Key: UML25-602
  • Legacy Issue Number: 7777
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows
    an association between example interfaces IAlarm, ISensor, and has this
    caption:

    IAlarm is the required interface for any classifier implementing
    Isensor; conversely, Isensor is the required interface for any
    classifier implementing IAlarm.

    The text description says:

    A set of interfaces constituting a protocol may be depicted as
    interfaces with associations between them

    Is this just notation, or are associations really in the model?

    • If it is just notation, what is the model?
    • If it is the model, isn't it overly restrictive? The modeler's
      intention might be that these are both required interfaces,
      declaring that the two support classes will include an association
      between them. I thought interface were extended in UML 2 to include
      associations generally.
  • Reported: UML 1.4.2 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Section: 9.3.3

  • Key: UML25-562
  • Legacy Issue Number: 7415
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances (its roles)," Roles aren't instances, are they? Does this want to say something like: A collaboration is a kind of classifier and defines a set of roles to be played by cooperating instances, ... Well, probably not. Perhaps: A collaboration is represented as a kind of classifier and defines a set of cooperating entities (its roles) to be played by instances, ...

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

At «implementation Class», what does "a child of instance" mean?!

  • Key: UML25-561
  • Legacy Issue Number: 7411
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    At «implementation Class», what does "a child of instance" mean?!

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the offending phrase.

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

three possibilities for aggregation kind at 7.11.2, but only two notations

  • Key: UML25-559
  • Legacy Issue Number: 7409
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three possibilities for aggregation kind at 7.11.2, but only two notations at 7.11.3.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Section: 7.11.2

  • Key: UML25-558
  • Legacy Issue Number: 7408
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "The interaction of association specialization with association end redefinition and subsetting is not defined." Is that as good as we can do?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The quoted text no longer appears in the spec. There is now an explanation of this interaction.
    Disposition: Closed - No Change

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

It is not clear what 'related to' means

  • Key: UML25-560
  • Legacy Issue Number: 7410
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association" It is not clear what 'related to' means. The text ought to spell out what this relationship is, exactly.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Association notation for properties does not allow representation of aggregation

  • Key: UML25-499
  • Legacy Issue Number: 18466
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.5 issue.

    There is a sentence in 9.5.4: “In a Classifier, an attribute may also be shown using association notation, with no adornments at the tail of the arrow.” This does not allow the use of diamond notation to represent properties that are aggregations or compositions.

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is independent of issue 15237, which complains about the very existence of this notation. If the notation
    is to remain, at least it needs to be comprehensibly defined.

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

UML2.5 issue: incorrect use of oclKindOf()->notEmpty()

  • Key: UML25-498
  • Legacy Issue Number: 18465
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is a systematic error in the OCL in Clause 17. There are many erroneous expressions of the form x.oclIsKindOf(T)->notEmpty(). These are apparently intended to mean x.oclIsKindOf(T), i.e. a Boolean-valued test that x has the type T or a subtype.

    The fact that the ->notEmpty() happens to pass the syntax checking is an unfortunate and misleading “feature” of OCL. Semantically, all of these expressions in their current form will evaluate to true, whatever their arguments.

    I found these constraints all to have the problem:

    all_lifelines

    interaction_uses_share_lifeline

    selector_int_or_string

    sending_receiving_message_event

    signature_is_signal

    signature_is_operation_request

    signature_is_operation_reply

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the OCL productions to replace:
    x.oclIsKindOf(T)->notEmpty()
    by:
    x.oclIsKindOf(T)

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

wrong multiplicity of redefining states

  • Key: UML25-497
  • Legacy Issue Number: 18455
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML spec, Figure 15.3 shows that multiplicity of redefining state is 0..1 which automatically means that it is impossible to have two or more subclasses which redefine the same state in their statemachines.

    It should be fixed to state [0..*] I believe

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the appropriate association end multiplicities from [0..1] to [0..*].

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

Keywords are inconsistently defined and applied

  • Key: UML25-496
  • Legacy Issue Number: 18454
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The word “keyword” is used inconsistently throughout the spec. It is defined in Annex C, which clearly says that keywords are always enclosed in guillemets, and lists the keywords that appear in the spec. Non-stereotype keyword are currently all defined starting with lower case, while standard stereotypes (also listed in Annex C and counting as keywords) use upper case.

    However:

    1. Several keywords defined in the spec are missing from Annex C: bind, collaboration, complete, disjoint, parallel, iterative, stream and flow.

    2. Several references in the spec to standard stereotypes use lower case and should use upper: derive, refine, trace

    3. In 7.7.5 instantiate is described and lower-cased as a keyword when it should be referred to as a standard stereotype in upper case

    4. 9.2.4 states that the standard notation for classifiers “shows the metaclass in guillemets”. This is not true: almost all classifiers define a lower-case keyword for their notation, such as interface; sometimes the keyword is different from the metaclass name, e.g. primitive.

    5. Notwithstanding the above, the notations for Collaboration, Class and StateMachine explicitly and inconsistently use the metaclass name with uppercase. In the case of Collaboration (11.7.4) and Class (11.4.4), Annex C is missing the keyword; in the case of StateMachine, Annex C shows it as statemachine.

    6. Some words are described as keywords when they are not. Clause 13: all, at, after, when; clause 14: via, protocol; clause 17: sd, self, out, strict

    7. Annex C itself uses the phrase ‘the keyword “trace”’ when it should surely say ‘the keyword «Trace»’.

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are many problems with keywords in Annex C and throughout the spec.
    (1) can be resolved by including appropriate definitions in Annex C.
    (2) can be resolved by correcting the references where they occur.
    For (3) a separate issue will be raised against clause 7.
    (4) can be resolved by altering 9.2.4 to refer to the keyword rather than the metaclass.
    (5) can be resolved by correcting the references to refer to the lower case name. (6) can be resolved by either rewriting to avoid the need for any terminology, or by using other terminology:
    “textual annotation” when the word is in curly brackets. Note that the BNF convention is to specify terminal
    symbols using single quotes; we should do the same in the specification text.
    (7) can be resolved as suggested.
    There are several words listed in the table in Annex C that are not keywords. Especially, compartment
    headers are not keywords (as they do not appear in guillemets) and should be removed from the table. This
    is a change from earlier versions of UML which were unclear and inconsistent about compartment naming.
    The notation placement “between braces” is contradictory with “Keywords are always enclosed in guillemets”.
    There are several related issues that can be merged with this one: 18113 is covered by 2. 18114 points out
    that «create»is a keyword as well as a standard stereotype. In fact «create»is not introduced anywhere in
    the spec as a keyword, and its definition as given in Annex C does not make sense because it cannot be
    represented in the abstract syntax. So the keyword can be deleted from the table. 11683 is rendered obsolete
    by the fact that

    {abstract}

    is correctly no longer described as a keyword.
    9125 is resolved by the points above.
    15756 is resolved by (1).
    15419 is resolved in the same way as 18114.
    Note also that issue 18112 removes all standard stereotypes from Annex C, so they are no longer defined as
    keywords.
    The resolution also corrects miscellaneous errors in Table C.1.

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

InformationFlow::sources_and_target_kind

  • Key: UML25-487
  • Legacy Issue Number: 18415
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The OCL doesn't match the description - no check is made of the
    InstanceSpecification classifier. (This constraint could probably
    be split in two and the type test separated as an operation.)

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note this change resolves both issues 18415 (which corrects the OCL) and 18690 (which adds Behaviors to
    the list of allowed types). The latter is merged with 18415 since both affect the same text allowing for a less
    confusing statement of their combined resolutions.
    In contrast to the 18415 issue summary, the OCL does check for InstanceSpecification, but it doesn’t not
    do so completely. The check that a source or target that is an InstanceSpecification is not a link is missing.
    These checks are added in the update OCL below.

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

UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype

  • Key: UML25-494
  • Legacy Issue Number: 18450
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In 7.7.5 «instantiate» is described and lower-cased as though it were a keyword. It sort of implies that Instantiate is a subclass of Dependency.

    In fact «Instantiate» is a standard stereotype. It should be referred to using upper case, and the text should explain that it is a standard stereotype applied to a Usage. The figure and caption will need changing.

    (Note: this example is also the topic of issue 17804, which is a separate matter about the direction of the arrow.)

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

UML 2.5 - clause 14 does not put Examples at the correct heading level

  • Key: UML25-493
  • Legacy Issue Number: 18448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    All the other clauses have Examples at the same level as Notation, Semantics etc. Clause 14 does not do this.

    14.3.4 defines the notation

    {final}

    in the Examples section: notation should be defined in the Notation section and exemplified in the Examples section.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12380

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

Table C.1 apply

  • Key: UML25-489
  • Legacy Issue Number: 18417
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of apply refer to 'importedProfile'. There is no
    such property. I'm not entirely sure why there's any OCL at all
    as the keyword is just used with the ProfileApplication diagram
    edge itself.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18124

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

Metaclass operations incomplete

  • Key: UML25-488
  • Legacy Issue Number: 18416
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The operations listed for each metaclass should give the uniqueness
    and ordering of all their parameters, including return type. For
    example, NamedElement::getAllNamespaces() is actually ordered. In
    addition, operation redefinitions should be given, for example,
    Package::mustBeOwned().

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Enhance the generator to produce annotations such as ordered, nonunique for all operation parameters and
    results with non-default values for isOrdered and isUnique in the generated Classifier Descriptions.
    Enhance the generator to produce annotations such as redefines op() for all operation redefinitions in the
    generated Classifier Descriptions.

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

UML2.5 issue: clause 10 Signal and Reception

  • Key: UML25-492
  • Legacy Issue Number: 18444
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The sentence in 10.3.3 “The receiving object handles Signals as specified by its Receptions” should read “The receiving object handles Signals as specified by clause 13.3”. The current sentence seems to imply that a Reception is needed to receive a Signal which is actually not the case,

  • Reported: UML 2.5b1 — Tue, 12 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    do as proposed

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

Conflict in use of unlimited natural

  • Key: UML25-491
  • Legacy Issue Number: 18442
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Section 7.3.32 states in its Notation subsection that an asterisk denotes "unlimited (and not infinity)". Section 7.3.33 states that an asterisk represents "the unlimited (or infinite) upper bound". That one is infinite and the other not seems a contradiction

  • Reported: UML 2.4.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18096

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

UML 2.5: ActivityPartition::represents keywords

  • Key: UML25-495
  • Legacy Issue Number: 18452
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The keywords «attribute» and «class» are part of the notation for ActivityPartition (examples in 15.70 and 15.72) but are not specified in the notation and should be. They do appear in Annex C.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation used in the example diagrams in Figures 15.70 and 15.72 is not consistent with the notation
    as specified in Subclause 15.6.4, which defines no such keywords. The figures also use underlining of
    ActivityPartition names, which is not specified, either.

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

UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction

  • Key: UML25-490
  • Legacy Issue Number: 18419
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    First sentence of fourth paragraph says:

    The invalid set of traces is associated only with the use of a Negative CombinedInteraction.

    But it ought to say:

    The invalid set of traces is associated only with the use of a Negative CombinedFragment.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Apply the solution proposed in the issue’s summary.

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

Classifier::hasVisibilityOf(...)

  • Key: UML25-486
  • Legacy Issue Number: 18414
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::hasVisibilityOf(...)
    The description doesn't match the OCL.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18177

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

Two entries

  • Key: UML25-485
  • Legacy Issue Number: 18408
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.4.1 and UML 2.5 beta1 specs incorrectly show TWO entry behaviors on state, when only one is allowed in metamodel.
    Figure 14.5 State with compartments

  • Reported: UML 2.5b1 — Mon, 4 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 16111

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

About UseCase description

  • Key: UML25-519
  • Legacy Issue Number: 18726
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of a UseCase is: “A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.”.

    However, UseCase may have no subjects. What happen in that case?

  • Reported: UML 2.5b1 — Tue, 21 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clause 18 is inconsistent in using “subject” in the singular in many places. Clarify that a UseCase may refer
    to many subjects or none.

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

Annex B summary table

  • Key: UML25-518
  • Legacy Issue Number: 18717
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is addressed by adding a table to the end of Annex B. This table shows example UML notations,
    and how they are represented in DI. The table refers the clauses and their figures, as well as Annex B clauses.

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

actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Key: UML25-529
  • Legacy Issue Number: 18760
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Quoted from §18.1.3, p686: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging
    signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an
    associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.”

    There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Reported: UML 2.5b1 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the contentious sentence (not actually mentioned in the issue, but the earlier sentence in 18.1.1 which
    talks about the “needs” of Actors) which adds no value to the spec.

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

UML: Parameter Direction and Effect

  • Key: UML25-528
  • Legacy Issue Number: 18759
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The rules on Parameter Direction and Effect, seem overly weak.

    It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

    It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

    And Conrad says:
    Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

    But Ed Seidewitz says
    The object passed out in on inout parameter doesn't have to be the same one that was passed in.

    For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

    The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

    Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

    So, we have at least different suggestions for changes to this material.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17891

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

UML 2.5 Issue: specification for qualified association ends is in wrong clause

  • Key: UML25-523
  • Legacy Issue Number: 18750
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Move the text fragments to the right place. The comment about unique ends has already been taken into
    account in 11.5.3.

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

UML 2.5 class_name

  • Key: UML25-522
  • Legacy Issue Number: 18748
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement. This is the only place in the spec where <class_name> appears. <class-name> appears in the text following the BNF. <class_name> in the BNF should be changed to <class-name>.

    Recommend that we add the following statement to the BNF

    <class-name>::=<Variable> | <Parameter> | <Property>

  • Reported: UML 2.5b1 — Mon, 3 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Interactions working group agreed during the Berlin meeting that class_name is not optimal. In fact,
    the non-terminal symbol class_name does not reflect what it actually represents, i.e., the name of the Type
    that the ConnectableElement, which is represented by the Lifeline, is typed with.
    In addition, the font style of the non-terminal symbols has to be set to italics.

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

Event pools for passive objects

  • Key: UML25-526
  • Legacy Issue Number: 18754
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Currently, the only constraint related to Class:isActive is the passive_class constraint that “Only an active Class may
    own Receptions and have a classifierBehavior.” This means that a passive class may still have ownedBehaviors (including
    methods of operations), and these may service the event pool of instances of the class. (Note also that a passive
    object may receive Signal instances into its event pool, even though its Class does not have receptions.)
    Disposition: Closed - No Change

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

Behavior after exceptions are encountered

  • Key: UML25-525
  • Legacy Issue Number: 18753
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities.

    So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception? For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is referencing the following sentence in Subclause 13.2.3: “A FunctionBehavior may raise exceptions
    for certain input values, in which case the computation is abandoned.” It is rather odd to only mention
    exceptions in the specific case of FunctionBehaviors, since exceptions can potentially be raised by any kind
    of Behavior. This would be better explained more generally.

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

UseCases editorial change

  • Key: UML25-521
  • Legacy Issue Number: 18730
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”, “extending” should read “extended”.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    indeed it should

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

The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice

  • Key: UML25-520
  • Legacy Issue Number: 18727
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
    For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:

    // difference in the parameter direction
    op1(String)
    op1():String

    // difference in the parameter effect
    op2(update String)
    op2(delete String)

    // difference in the parameter exception
    op3(Throwable)
    op3() throws Throwable

    // difference in the parameter collection characteristics
    op4(Set(String))
    op4(String[1])

    This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)

    This can be easily fixed.

    In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:

    ...>isUnique(ownedParameter>collect(type))

    With:

    …>isUnique(ownedParameter>collect(p|Tuple

    {name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper}

    ))

    Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

  • Reported: UML 2.5b1 — Wed, 22 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Clarify that stereotypes can be applied to UML DI

  • Key: UML25-517
  • Legacy Issue Number: 18715
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 – that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

  • Reported: UML 2.5b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    clarify as suggested

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

UML2.5 clause 17 keyword inconsistency

  • Key: UML25-516
  • Legacy Issue Number: 18702
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords. These should be fixed in a similar manner to issue 18454.

  • Reported: UML 2.5b1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Completion events disambiguation

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

    Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction

  • Key: UML25-527
  • Legacy Issue Number: 18756
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends. For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9013

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

UML 2.5 FTF Receptions may not have a method

  • Key: UML25-530
  • Legacy Issue Number: 18777
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.

    context Reception
    inv: self.method->isEmpty()

    What do you think?

  • Reported: UML 2.5b1 — Wed, 12 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting

  • Key: UML25-414
  • Legacy Issue Number: 18049
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, or by pre-conditions and post-conditions...”

    [AC] The “or” in “ or by pre-conditions and post-conditions” is ambiguous, because it can be interpreted as an XOR, while it is not exclusive. In fact, but several lines below, it is correctly stated that “These descriptions can be combined”. I suggest to remove the “or”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject

  • Key: UML25-417
  • Legacy Issue Number: 18053
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. “

    [AC] In my opinion, this is ambiguous, and could be replaced with “in the sense that, in a specific modeling context, an instance of the Actor is not a part of the instance of the subject of an associated UseCase”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The offending sentence is unclear, and the concept of “external” is vague and dubious. Better clarity can be
    achieved by removing it altogether.

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner

  • Key: UML25-416
  • Legacy Issue Number: 18051
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Although the owning Classifier typically represents the subject to which the owned UseCases apply, this is not necessarily the case.”

    [AC] I would add: “as is shown in Figures 18.10 and 18.11”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with

  • Key: UML25-415
  • Legacy Issue Number: 18050
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in initiating the UseCase.”

    [AC] I would delete the term “initiating”, because it is wrong. Not only [may] a use case may be time-triggered, but the multiplicity may be >1 even if an instance of actor initiates the use case, then another instance is involved.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true

  • Key: UML25-420
  • Legacy Issue Number: 18058
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

    As it is unclear whether an omitted condition is true, clarify the situation by explicitly handing it. Replace the start of this paragraph with "If the condition of the Extend is missing or evaluates to true at the time the first ExtensionPoint is reached during the execution…”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal.

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy

  • Key: UML25-419
  • Legacy Issue Number: 18057
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Therefore, it is not easy to capture its structure accurately or generally by a formal model.”

    [AC] I would say “it is not possible”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the whole sentence, which adds no value to what can be deduced from the preceding sentence

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case

  • Key: UML25-418
  • Legacy Issue Number: 18055
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in a UseCase.”

    [AC] According to the metamodel, if I'm not wrong, this should be “in one or more UseCases”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.4 Notation P. 688 - Point to diagram

  • Key: UML25-422
  • Legacy Issue Number: 18063
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name (and associated keywords and stereotypes) in the top-left corner, with the UseCase ellipses visually located inside this rectangle.”
    [
    AC] I would add at the end “as shown in figure 18-2”.

    General note: the numeric ordering of figures should be aligned with the sequence in which they are referenced in the text.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal in the first paragraph of the issue, using text to clarify that the figure is an example, and
    explain what kind of subject is shown in the example.
    The numeric ordering of figures is by editorial policy the order in which they appear, and that will not be
    changed regardless of how they are referenced

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner

  • Key: UML25-421
  • Legacy Issue Number: 18061
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

    [AC] I would add at the end “(the includingCase)”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    accept the proposal

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

State Machine Package--Compliance

  • Key: UML25-574
  • Legacy Issue Number: 7555
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    Please accept the following as an Issue for the UML 2 FTF.

    State Machine Package--Compliance

    Compliance with the state machine package is too onerous for
    many vendors.

    There is no need-for many of us-to include choice points, entry
    points, and other elements.

    An suggested layering would consist of:
    Layer 1: Initial pseudo states, states, final states, events, transitions.
    Layer 2: Stuff required to support hierarchy
    Layer 3: Stuff required to support orthogonal regions.
    Layer 4: All the rest.

  • Reported: RAS 2.0b1 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Actions need to be independent from Activities

  • Key: UML25-573
  • Legacy Issue Number: 7552
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    If we take Activity as fundamental, and consider that we can't specify something that happens with Action alone, shouldn't we remove the first sentence of the second paragraph of 11 Actions : 11.1 Overview : Basic Concepts:

    "An action is the fundamental unit of behavior specification."

  • Reported: RAS 2.0b1 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    An action is fundamental in that the behavior of an Activity is built up from Actions. An Activity does
    not have any behavior on its own. Actions can also be used to specify behavior within the context of an
    Interaction.
    Disposition: Closed - No Change

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

Concept of 'port side' not to be found in metamodel

  • Key: UML25-567
  • Legacy Issue Number: 7435
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    the semantic variation point about port uses the concept of "port side" that I cannot find in the metamodel. May be it should be added?

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Composite structures/contradictory constraint on connector

  • Key: UML25-566
  • Legacy Issue Number: 7431
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    We read as a constraint for connector (composite structure)

    [2] If a connector is attached to a connectable element which has required
    interfaces, then the connectable elements attached
    to the other ends must realize interfaces that are compatible with these
    required interfaces.

    And Commponents::Connector provides the following constraint:
    [1] A delegation connector must only be defined between used Interfaces or
    Ports of the same kind, e.g. between two provided
    Ports or between two required Ports.

    Both are in contradiction.

    Proposed correction:

    Ditch CompositeStructure::Connector constraint [2]

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

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

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

UML 2 Super/Interfaces

  • Key: UML25-568
  • Legacy Issue Number: 7441
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02 Figure 63 - firstly there ar a couple of typoes. The interface
    stereotype on IAlarm is missing <<, and sensor should be ISensor. More
    serious are the implications of the caption - "IAlarm is the required
    interface for any classifier implementing Isensor;
    conversely, Isensor is the required interface for any classifier
    implementing
    IAlarm."

    To me the caption sounds wrong but at the very least more explanation is
    needed. Firstly, does having the association to the interface imply that a
    usage dependency is required to ISensor from any class that implements
    IAlarm? If so a constraint is needed to enforce that. Secondly, isn't such a
    usage dependency redundant, given that its existence is implied from the
    presence of the association?

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

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

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

Issue in UML 2 CombinedFragment class

  • Key: UML25-571
  • Legacy Issue Number: 7450
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to represent atomic message sending

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

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

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

Issue in UML 2 Message class

  • Key: UML25-570
  • Legacy Issue Number: 7449
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is possible that the sendEvent and the ReceiveEvent are on the same Lifeline but it is not possible to specify whether the sender will receive a copy of the Message.

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

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

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

Description text for CollaborationOccurrence unclear

  • Key: UML25-565
  • Legacy Issue Number: 7420
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The Description text for CollaborationOccurrence seems to be unclear about roles and the instances playing roles. For example, roles aren't involved in an occurrence, instances playing roles are. For another example, in the case of multiple occurrences of a given collaboration, the roles are the same, while the instances playing those roles may (or may not) differ.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Editrial error in Section: 9.3.4 ?

  • Key: UML25-564
  • Legacy Issue Number: 7419
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "Associated dependencies map features of the collaboration type to features in the classifier. These dependencies indicate which role in the classifier plays which role in the collaboration." seems to be an editorial error

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

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

Association collaborationRole

  • Key: UML25-563
  • Legacy Issue Number: 7416
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "Association collaborationRole: ConnectableElement References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration." Do they represent roles, or are they roles? If they represent roles, how do we learn which role a particular element represents?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Disposition: Merged with 18697

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

Issue in UML 2 Message class

  • Key: UML25-569
  • Legacy Issue Number: 7448
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    The signature of the Message class is said to be of type NamedElement but such class allows for instance to write the qualifiedName and the visibility (see p. 11) and we do not know exactly what these two features offer here.

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

    Discussion
    UML 2.5 message notation was clarified considerably.
    Disposition: Closed - No Change

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

Issue in UML 2 Gate class

  • Key: UML25-572
  • Legacy Issue Number: 7452
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to write which InteractionFragment is addressed with a formal Gate

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

    Discussion
    Already addressed by clarification of gate matching rules in UML 2.5
    Disposition: Closed - No Change

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

Interactions needs to fix Gate name Distinguishability rules

  • Key: UML25-503
  • Legacy Issue Number: 18528
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The isDistingishableFrom() operation of NamedElement needs to be
    overridden for Gate class to cover the case of when the gate is used as
    a formalGate of an Interaction. The association end formalGate subsets
    ownedElement, and since the Gate name attribute is optional, it is
    allowed to have two formal gates without an explicit name, but having
    derived names which are distinct.

    Even though the gate matching rules do not use this operation, we need
    to override it to avoid problems.

    In addition to this fix, there is a also need to add constraints to the
    gate names used for Gates for the gate matching rules to work properly.
    In particular, there are cases in use of gates which require distinction
    for the gate matching rules to work.

    Thus there is still a need to add new constraints on gate Names (explicit
    or derived).

    Because Gates which do not have an explicity name attribute have derived
    names, any constraint must include the possibility of these derived
    names.

    There is an explicit operation getGateName() on Gate class which returns
    the name of the gate which is to be used in the gate matching rules. If
    a gate does not have an explicit name attribute, a gate name is derived
    from the name of the message the gate is attached to , and the direction
    of the message with respect to the gate (e.g, foo_in, foo_out). The
    direction "in" or "out" is considered with respect to the outer perimeter
    of the interaction fragment that the gate is attached to.

    UML 2.5 added Gate matching rules in OCL, using this getGateName()
    operation, however there are currently no gate name distinguishably
    constraints in the spec. Two gates in the same container may have
    duplicate derived names, just because they are attached to two different
    messages, with the same direction, which happen to have the same name.
    There are cases when the gate matching rules will not work unless at
    least one of these gates needs includes an explicit name attribute value
    contrived to avoid the collision of the getGateNames() operation.

    The association end formalGates of Interaction subset ownedMember, and,
    as already stated above, we have to override the isDistinguisableFrom()
    operator for gate class. However, If there were two formal Gates with
    the same gate name in an interaction, the gate matching rules would
    become invalid.

    The association ends actualGates of InteractionUse, and cFragmentGates
    of CombinedFragment, both subset ownedElement, not ownedMember. So they
    no not need to obey the isDistinguisableFrom test. However, even though
    not required for the UML namespace Rules, actual Gates for an
    InteractionUse should have distinguishable gate names, in order for the
    gate matching rules to work.

    For the same reason, If a cFragmentGate is outside the CombinedFragment,
    then it must be distinguishable from other outer cFragmentGates of that
    same CombinedFragment.

    For the same reason, any two inner cFragmentGates associated with the
    same InteractionOperator of a CombinedFragment must have distinguished
    gate names.

    Thus we need to add a set of four constraints (one for each kind of gate)
    to the Gate clas