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-623 "Class" should read "Classifier" in Generalization subsection for Behaviore UML 1.4.2 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-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-618 15.3.8 Pseudostate (from BehaviorStateMachines) 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-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-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-625 UML 2 Super/ Classes / issue with Property::isComposite UML 1.4.2 UML 2.5 Resolved closed
UML25-624 Associations section of InteractionUse UML 2.0 UML 2.5 Resolved closed
UML25-616 Artifact (from Artifacts) UML 1.4.2 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-613 8.3.1 Component (from BasicComponents, PackagingComponents) 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-667 Surplus classifier field serialized in Superstructure.xmi UML 2.4.1 UML 2.5 Resolved closed
UML25-666 DurationObservation#event should be ordered 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-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-661 LifeLine instead of Lifeline UML 2.4.1 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-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-673 Incomplete sentence 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-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-668 A comment is a specialization of Element UML 2.4.1 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-602 Associations between interfaces UML 1.4.2 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-611 7.3.24 Interface (from Interfaces) 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-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-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-605 UML 2 Superstructure - cross-hair notation for nested classes UML 1.4.2 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-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-652 incorrect upper value of coveredBy of Lifeline 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-631 EnumerationLiterals in the XMI UML 2.4.1 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-649 Reference in index to item that does not exist in contents 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-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-644 default value of ClassifierTemplateParameter#allowSubstitutable is "..." 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-636 RedefinableElement (from Kernel) is preferable 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-633 UML Superstructure Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-632 ChangeEvent association mismatch 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-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-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-638 {ordered} is rather far from +bodyOutput UML 2.4.1 UML 2.5 Resolved closed
UML25-587 . <> on Usage 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-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-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-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-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-596 UML 2 does not permit use of a state machine UML 2.0 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-593 P.35 Typo in OCL definition of isDistinguishableFrom query 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-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-588 Figures 103 and 121 use <> dependencies 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-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-577 Port should specialize featuringClassifier 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-575 Semantics section of StructuralFeature UML 2.0 UML 2.5 Resolved closed
UML25-574 State Machine Package--Compliance RAS 2.0b1 UML 2.5 Resolved closed
UML25-560 It is not clear what 'related to' means 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-573 Actions need to be independent from Activities 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-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-569 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-568 UML 2 Super/Interfaces 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-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-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-542 Dependencies with more than two ends 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-539 Avoid covariant parameters in metamodel operation redefinition UML 2.5b1 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-536 The resolution to Issue 18528 contains incorrect OCL and operation names 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-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-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-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-547 PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value 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-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-535 The resolution to issue 18415 contains invalid OCL 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-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-530 UML 2.5 FTF Receptions may not have a method 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-504 Classifier operation inherit(NamedElement[*]) : NamedElement[*] UML 2.5b1 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-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-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-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-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-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-513 parts should be allowed to show their interfaces UML 2.5b1 UML 2.5 Resolved closed
UML25-528 UML: Parameter Direction and Effect 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-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-524 Completion events disambiguation 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-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-512 Behavior is not allowed to be source or target of an InformationFlow UML 2.4.1 UML 2.5 Resolved closed
UML25-511 Forked association notation ill-formed UML 2.5b1 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-508 UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput 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-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-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-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-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-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-495 UML 2.5: ActivityPartition::represents keywords 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-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-490 UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction 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-487 InformationFlow::sources_and_target_kind 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-484 UML 2.5 issue; the word "individual" is incorrect in 9.8 UML 2.5b1 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-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-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-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-465 Location: Index Mis. - Missing terms in the Index 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-462 Location: Index p 793 - emergent behavior 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-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-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-431 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity 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-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-425 Location: 18.1.4 Notation P. 688 - Point to diagram (04) 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-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-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-455 Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex 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-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-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-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-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-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-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-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-434 Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG 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-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-449 Location: B.2.3 P. 738 - confusing model and diagram 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-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-461 Type: Structural - Location Index p 790, 794, 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-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-456 Location: Annex C Keywords p 777 - Capitalization of «trace» 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-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-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-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-374 Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions 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-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-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-368 Location: Page 338, Transition selection algorithm - Maximal Set 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-381 Location: p. 331 Exiting a State - Clarification of Exiting a State 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-379 Location: p. 330 Deferred Events - Value of Deferred Events 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-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-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-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-338 Location p 152 Generalization Attributes: IsSubstitutable 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-402 Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability 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-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-366 Location: Page 329 States - Stable 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-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-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-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-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-347 Location: 10.2.4 Notation p 184 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-344 Location p 162 ParameterSet constraints input: Exceptions and parameterset 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-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-392 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 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-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-356 Location Figure 11-23 s p.217 - Instance/roll names (02) 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-353 Location Figure 11-21 s p.216 - Instance/roll names 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-388 Location: p. 338 Transition execution sequence 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-386 Location: p. 337 Conflicting Transitions 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-382 Location: p. 333 FinalState 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-315 Redefinition does not allow for overloading UML 2.4.1 UML 2.5 Resolved closed
UML25-314 Use isReadOnly default 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-311 inout parameters and effects 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-302 Location: p.116 (9.4.3 Semantics) 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-299 Inherited members 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-297 the parent of a Classifier is not its owner.” 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-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-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-324 Location: 9.6.3 Operations p 127 UML 2.4.1 UML 2.5 Resolved closed
UML25-310 Effect Intent UML 2.4.1 UML 2.5 Resolved closed
UML25-309 Return Parameter pronoun 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-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-304 Alterative Scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-282 Duration Definition 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-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-277 String expression notation missing UML 2.4.1 UML 2.5 Resolved closed
UML25-276 body text strings 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-321 Location: 9.5.3 p 122 Qualifiers must be enumerated type 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-318 What is “Intentionally Not specified”? 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-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-332 Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior 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-330 Location: 9.8.4 Notation p 141 UML 2.4.1 UML 2.5 Resolved closed
UML25-289 Two anonymous invariants 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-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-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-296 Objects? 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-293 Turing Machine lurking paradox? 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-290 Min/Max 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-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-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-262 Negatively phrased sentence 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-260 TypedElement description could be expanded 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-225 Figure 6.1 does not relate to rest of Specification 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-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-275 sentence unclear 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-272 {ordered} at wrong end UML 2.4.1 UML 2.5 Resolved closed
UML25-271 Past vs Present 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-268 Unlimited Natural 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-250 Missing OCL 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-247 Confusing description of types 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-244 Incorrect text describing diagram elements 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-241 Packageable Elements and Imports (02) 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-238 Note refers to an undiscussed concept 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-235 Can Comments own comments? UML 2.4.1 UML 2.5 Resolved closed
UML25-234 Owning Rules 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-231 Owning Comments 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-228 What type of slash? 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-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-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-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-252 Missing a 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-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-215 DI Conformance implies Model Interchange Conformance 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-212 Capture Submitters, Supporters, etc UML 2.4.1 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-209 Section 11.5. - Clause 11: Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-208 Superfluous word on p309 UML 2.5b1 UML 2.5 Resolved closed
UML25-207 isConsistentWith() definition broken 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-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-202 Suggested improvements to conformance section UML 2.5b1 UML 2.5 Resolved closed
UML25-201 PDF links to Primitive Types don't work UML 2.5b1 UML 2.5 Resolved closed
UML25-200 Missing word in section 7.4.3, "Semantics" UML 2.5b1 UML 2.5 Resolved closed
UML25-221 Modeling Individuals UML 2.4.1 UML 2.5 Resolved closed
UML25-220 Within the System UML 2.4.1 UML 2.5 Resolved closed
UML25-219 Incarnation ? UML 2.4.1 UML 2.5 Resolved closed
UML25-199 Four typos UML 2.5b1 UML 2.5 Resolved closed
UML25-198 Declassifying of Annex D 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-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-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

Issues Descriptions

Location: 9.6.4 Notation p 128: Confusing indentation

  • Key: UML25-345
  • Legacy Issue Number: 17930
  • Status: closed  
  • Source: No Magic, Inc. ( Jim Logan)
  • 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 ( 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 ( 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: No Magic, Inc. ( 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 ( 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 ( Nicolas 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

"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

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

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

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

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

Figure 307 and Figure 308 are exactly the same

  • Key: UML25-627
  • Legacy Issue Number: 7884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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 ( 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

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

  • Key: UML25-625
  • Legacy Issue Number: 7881
  • Status: closed  
  • Source: Simula Research Laboratory ( 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

Associations section of InteractionUse

  • Key: UML25-624
  • Legacy Issue Number: 7879
  • Status: closed  
  • Source: oose Innovative Informatik eG ( 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

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

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

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

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

Surplus classifier field serialized in Superstructure.xmi

  • Key: UML25-667
  • Legacy Issue Number: 17507
  • Status: closed  
  • Source: No Magic, Inc. ( 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

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

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

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

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

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

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

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

Problems with OCL definition of Package::makesVisible

  • Key: UML25-672
  • Legacy Issue Number: 19069
  • Status: closed  
  • Source: No Magic, Inc. ( 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 ( Nicolas 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

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

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

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

Associations between interfaces

  • Key: UML25-602
  • Legacy Issue Number: 7777
  • Status: closed  
  • Source: NIST ( 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

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

  • Key: UML25-601
  • Legacy Issue Number: 7758
  • Status: closed  
  • Source: Simula Research Laboratory ( 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

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

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

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

UML 2 Super/Templates/Inconsistent organization

  • Key: UML25-607
  • Legacy Issue Number: 7831
  • Status: closed  
  • Source: Simula Research Laboratory ( 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 ( 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 Superstructure - cross-hair notation for nested classes

  • Key: UML25-605
  • Legacy Issue Number: 7784
  • Status: closed  
  • Source: The MathWorks ( 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

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

how to instantiate associations between stereotypes

  • Key: UML25-654
  • Legacy Issue Number: 17160
  • Status: closed  
  • Source: Model Driven Solutions ( 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

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

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

EnumerationLiterals in the XMI

  • Key: UML25-631
  • Legacy Issue Number: 16584
  • Status: closed  
  • Source: Adaptive ( 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

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

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

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

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

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

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

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

"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

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

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

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

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

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

{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

. <> on Usage

  • Key: UML25-587
  • Legacy Issue Number: 7644
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    1. <<create>> on Usage is defined in the standard stereotypes and in the
    retired stereotypes. It is used in Figure 103 and 121 of the FAS.

  • Reported: UML 1.4.2 — Fri, 20 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

Profiles in Compliance Level 1?

  • Key: UML25-586
  • Legacy Issue Number: 7627
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    It has been suggested that Profiles should be part of Compliance Level 1 (Basic Level) rather than part of Compliance Level 2 (Intermediate Level) as currently defined. The rationale is that it gives any UML user the ability to specialize UML. We already know from experience that UML is almost ALWAYS specialized when it is used – implicitly or explicitly. Given that, we might as well provide users at all levels with the ability to use profiles. I feel that this is a reasonable suggestion.

  • Reported: UML 1.4.2 — Tue, 10 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

Redundant parameter specifications for Operation and Behavior

  • Key: UML25-585
  • Legacy Issue Number: 7626
  • Status: closed  
  • Source: International Business Machines ( Jim Amsden)
  • Summary:

    A Behavior can be defined in the context of a BehavioredClassifier where it must have a specification BehavioralFeature which defines its parameters and return value. A Behavior may also stand alone in order to represent procedural-based models in which case the Behavior specifies its own parameters and return result.

    There is a constraint that specifies the parameters of a Behavior in the context of a BehavioredClassifier must match the parameters of its specification BehavioralFeature. However, parameter matching is not explicitly defined. Is it match in mode, name, type, multiplicity, constraints, etc., or just type?

    A better solution would be to disallow behavior parameters if the behavior has a specification. This would eliminate the need to redundantly specify the parameters for a behavior if it has a specification, and then enforce a constraint to have them match.

    Specifically:

    1. section 13.3.3, remove constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature.

    2. add a new (second) constraint: [2] A Behavior with a specification BehavioralFeature obtains its parameters from the BehavioralFeature and cannot specify its own parameters.

    3. add a new constraint: [3] A Behavior with a specification BehavioralFeature cannot have any redefinedBehaviors. The redefinitions come from the BehavioralFeature.

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

    Discussion
    The UML 2.5 specification is clear now (in 13.2.3, under “Behavioral Features and Methods”) that how the
    parameters of a method are matched to its specifying behavioral feature is intentionally not formalized, in
    order to allow for different possible approaches to this in different user models.
    Disposition: Closed - No Change

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

Missing notation for Behaviors in a BehavioredClassifier

  • Key: UML25-584
  • Legacy Issue Number: 7625
  • Status: closed  
  • Source: International Business Machines ( Jim Amsden)
  • Summary:

    There's no notation specified for showing the ownedBehaviors of a BehavioredClassifier. This could be done by using another compartment in the context classifier, but this is not mentioned, nor is the syntax for the behavior and its parameters specified that I could find.

  • Reported: UML 1.4.2 — Tue, 10 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

Name without a colon for Property in Composite Structures

  • Key: UML25-583
  • Legacy Issue Number: 7624
  • Status: closed  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    In Composite Structures, under 9.3.12 Property, the following
    paragraph under "Presentation Options" under "Notation" is
    inconsistent with the rest of UML in creating a special
    interpretation of a missing notation element:

    "A property symbol may be shown containing just a single name
    (without the colon) in its name string. This implies the
    definition of an anonymously named class nested within the
    namespace of the containing class. The part has this anonymous
    class as its type. Every occurrence of an anonymous class is
    different from any other occurrence. The anonymously defined
    class has the properties specified with the part symbol. It is
    allowed to show compartments defining attributes and operations
    of the anonymously named class."

    The simple omission of notation elements is part of the option
    in virtually all UML diagrams to elide elements that aren't
    relevant or are defined and shown on other diagram views.
    Implying something to be created by the absence of an
    element breaks from user expectations.

    In this case, the most natural expectation of a simple name on
    a property box, without any colon, is that the string is just
    the name of the part or property, and that the type for the
    name, ordinarily shown using a ":Type" string, has been omitted
    from the diagram.

    The simplest way to resolve this issue is just to remove this
    paragraph from the specification. The specification would then
    revert to the default interpretation of a missing notation
    element, which is just that it isn't shown on a particular
    diagram view, not that it doesn't exist.

    The application of Composite Structure diagrams to systems
    engineering, in response to the UML for Systems Engineering
    RFP, expects to use all the flexibility that UML provides to
    include or not include diagram elements on particular views
    of a complex system, to avoid cluttering the many partial
    views that might be needed. Resolution of this issue is
    essential to avoid having a different rule for a name without
    a colon in standard UML vs. its application to systems
    engineering.

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

    The BNF for Property does make the [’:’ <prop-type>] optional, so this is indeed an inconsistency in the
    spec. Delete the offending paragraph

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

UML 2 Super/Components/missing description of Connector::contract

  • Key: UML25-582
  • Legacy Issue Number: 7622
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    The association end Connector::contract, specified in figure 78 on page 135 is not documented in the description for Connector

  • Reported: UML 1.4.2 — Wed, 4 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

UML 2 Super/Interactions/notation for accessing a static feature

  • Key: UML25-581
  • Legacy Issue Number: 7621
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Context:

    Invoking static or class methods on classes is incredibly common. If you look at a typical Java or .NET app (or the libraries themselves), or even Smalltalk, between 5-10% of the calls are class method calls. If you reverse engineer any Java or C# code to a sequence diagram, one should be able to see what’s a class method call on class X, versus instance calls. When you creatively draw an interaction diagram, the reader (a human or tool) should be able to know when something is a static call on a class.

    There are literally thousands of class methods in the Java and .NET core libraries. Any significant java app makes thousands of calls to these many library class methods, in addition to hundreds or thousands of calls to app-defined class methods.

    Problem:

    This is basic stuff, but the interaction diagram notation is not clear on how to show this. Tool vendors need a solution ASAP; many are in beta, and want to know the “correct” way asap, during rev eng of java code to a seq dgm, to show such calls. E.g., given the basic java code that i show in the attached example picture, how to rev eng the code to a seq dgm.
    And my book, that teaches intro OOA/D, has to show the solution – i’ve got an aug 30 publishing deadline.

    UML 1 had a way to solve this in interaction diagrams, with underlined/not underlined labels in the boxes, where not underlined indicated it was a class, and thus a class method call. But of course, that convention doesn’t work with UML 2 lifeline boxes.

    The problem can probably be solved with the appropriate label in a lifeline box, and ensuring that the context composite structure diagram relates appropriately.

    Solution:

    I’ve asked this question to Jim Rumbuagh, who gave a “convention” solution i very much like, for the lifeline box label: “ClassName : Class ”

    e.g. “Font : Class”, “Collections : Class” or perhaps “Font : Type” if reverse engineering from C#.

    e.g.., going meta and viewing the class as an instance of class Class.

    In Java and Smalltalk (for example) all classes are indeed instances of class Class. In .NET, they are instances of class Type.

    Then the lifeline box still represents an instance (of class Class or Type or whatever), and the “class messages” are still instance messages.

    I attach a diagram that gives a sequence diagram example.

    And–and i consider this important–the solution should be obviously understandable and straightforward to a novice, as is Jim’s. It corresponds to an OO programmer’s mental model. I encourage the committee members to choose a solution that is simple and obvious, that maps straightforward to the language most OO developers are working in – Java or C#, not an obscure solution.

    An outstanding problem, with bigger ramifications, is the names “Font” and “Class” in the related context diagram. Where are they defined? Of course, most of these classes will be from the core Java or .NET libraries (each have about 20,000 classes). I propose being able to declare a convention something like “assume that in this composite structure diagram there is an implicit import of the classes needed from the java libraries (or other libraries).”

    Well, some convention like that is needed in any event, because we are frequently calling instance methods on instances of java library classes – in a typical java app, 30-50% of the calls are to objects from the library. You can’t expect (because it would be too fussy/awkward/unusable) a UML modeler working in Java to re-create or have to explicit import specific parts of the Java libraries (or various common 3rd party libraries) every time they want to refer to library objects – which is frequently.

    i attach a picture to illustrate.

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

    The issue here is to be able to describe calls on static methods.
    Static Operations are defined on Types, with the property “isStatic” declared as true.
    It needs to be clarified, that every connectable element can receive messages with signatures associated with
    its static operations.

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

"role binding"

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

    If a "role binding" is describe as a mapping between ConnectableElements, Collaboration::Classifier should derive from InternalStructure::StructuredClassifier rather than from Kernel::Classifier

  • Reported: UML 2.0 — Fri, 17 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

multiplicity of the "role:ConnectableElement"

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

    It's not clear whether the multiplicity of the "role:ConnectableElement" role multiplicity is [1] or [0..1]. I think it should be [1], as stated in the role description but figure 96 shows "0..1" and the ConnectorEnd constraints descriptions aren't clear on that point

  • Reported: UML 2.0 — Fri, 17 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

included use case wrongly referred to as the including use case

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

    Section 16.3.5 Include (from UseCases)

    The Semantics section for Inlcude, page 603 in the 042808.pdf convenience document, says "An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case."

    For "including" read "included (or addition) " and for "base" read "base (or including)".

    The parenthetical "addition" is needed because this is the term used in the abstract syntax, which does not have "included" as a rolename. Likewise, the abstract syntax does not recognize a role called "base use case" but calls it the "includingCase".

  • Reported: UML 1.4.2 — Tue, 7 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

check the BNF example given in the text

  • Key: UML25-597
  • Legacy Issue Number: 7676
  • Status: closed  
  • Source: Merrill Lynch ( Michael Anderson)
  • Summary:

    I'd check the BNF example given in the text. While an order designator can be used with the grammer shown, the uniqueness designator seems to just be hanging out in limbo.

  • Reported: UML 1.4.2 — Sun, 5 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 does not permit use of a state machine

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

    It appears UML 2 does not permit use of a state machine as a specification technique for a class. The support for use of a state machine to specify a method does not help: that state machine won't be a method. The support for use of a state machine to specify a classifier behavior does not help: since that state machine is not a specification of code that gets invoked when an object is created. Example: An architect specifies a state machine for a class. This is not the specification of a method, nor of an independent computation belonging to an object of that class, but of the overall behavior of an object of that class. That state machine responds to four events. As a refinement of that model, a tool or a designer generates four event taker method specifications, which together implement the specified state machine. Those methods are then hand coded according to that specification, or perhaps another tool generates the code for those methods. An object of this class "does nothing until it [one of its event taker methods] is invoked by some other object, then it does its thing, and then it returns and again does nothing." The behavior of that object is fully specified by this state machine. This state machine is not the specification of a method, nor is it the specification of a classifier behavior ("When an instance of a behaviored classifier is created, its classifier behavior is invoked."). But the opinion of experts, expressed in FTF discussions, is that these are the only two uses of a state machine permitted by the FAS. This state machine is not intended to "to describe or illustrate the behavior of an object." It is intended to fully specify that behavior. It is not a protocol state machine. Proposal: Specifically authorize this use of a state machine.

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

    Discussion
    A BehavioredClassifier in UML 2 can own any number of Behaviors via its BehavioredClassifier::Behavior link.
    These Behaviors can be of any type and can have any interpretation desired by the modeler (with the exception of
    the one designated as the “classifier Behavior”). Hence, there is nothing to prevent defining a state machine with the
    interpretation suggested by the submitter.
    Disposition: Closed - No Change

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

Active and passive

  • Key: UML25-595
  • Legacy Issue Number: 7673
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes:

    1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?)
    1a. Which may be single or possibly multiple (not sure if this is relevant)
    1b. Which may start automatically or may be explicitly started (but why whom??)

    2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke)

    3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive")

    4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary)

    Note that various combinations of these are possible, so an object could be both "active" and "passive".

    But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all?

    The current specification has a lousy definition of the terms, one that is circular.

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

    Discussion
    It may or may not be better to not use the phrases “active” and “passive”, but this is well established now in UML. The
    2.5 specification is clear that an “active” class is precisely one with “isActive=true”, and the OCL constraintsmake it
    clear what this entails. The other points discussed in the issue are also now more clearly addressed in the specification.
    Disposition: Closed - No Change

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

P.58 Missing closing bracket in second constraint

  • Key: UML25-594
  • Legacy Issue Number: 7669
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    Missing closing bracket in second constraint on P.58

    It reads:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1)

    )

    And should read:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1))

    )

  • Reported: UML 1.4.2 — Tue, 10 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

P.35 Typo in OCL definition of isDistinguishableFrom query

  • Key: UML25-593
  • Legacy Issue Number: 7668
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    There is a typo in the OCL definition of the isDistinguishableFrom query. The 2nd line of the definition states:

    isDistinguishable =

    This should read as:

    isDistinguishableFrom =

  • Reported: UML 1.4.2 — Tue, 10 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

"required interface"

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

    The concept of "required interface" is discussed but not clearly specified. 1. Shouldn't a specialized "Usage" be derived to model those related to interfaces? 2. May Classifier have required interfaces or only BehavioredClassifier? 3. A derived role or at least an OclHelper should be provided to get the required interfaces.

  • Reported: UML 2.0 — Thu, 2 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

Compliance points - Diagram Interchange

  • Key: UML25-591
  • Legacy Issue Number: 7651
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    From letters from Bran Selic and Pete Rivett I learn that the Superstructure
    FTF plans to revoke Diagram Interchange as a compliance point to UML 2
    compliance. As the Chair of the Diagram Interchange FTF I urge you to make
    compliance Diagram Interchange a necessity for full compliance.

    In all discussions I attended it was always pointed out that the ability to
    exchange UML diagrams compliant to a standard using XMI was the single most
    important issue missing in UML 1. The Diagram Interchange specification was
    specifically designed to solve this problem. It is of essence that Diagram
    Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2
    standard is drastically reduces in its value.

    The Diagram Interchange specification is of high quality. It is fully
    implemented by Gentleware to provide a reference, we have made cross checks
    with various other vendors that confirm high quality and interchangability.
    May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has
    implemented an XSLT transformation from XMI to SVG. It is available on his
    web site at www.jeckle.de.

  • Reported: UML 1.4.2 — Fri, 20 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

Bidirectional messages to a port object

  • Key: UML25-590
  • Legacy Issue Number: 7650
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    How do required and provided interfaces on a port support messages from
    both inside and outside the composite? Messages to a port object sent
    from the inside of the containing composite must be declared in the
    required interface of the port object, but usually messages sent to an
    object must also be declared in the provided interfaces. Is there a
    special case for ports? Didn't see anything in the spec explaining
    this.

  • Reported: UML 1.4.2 — Tue, 31 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

Figures 120 and 121

  • Key: UML25-589
  • Legacy Issue Number: 7646
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figures 120 and 121 underline the association names, which doesn't
    seem consistent with the notation for instances in Figure 21.

  • Reported: UML 1.4.2 — Fri, 20 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

Figures 103 and 121 use <> dependencies

  • Key: UML25-588
  • Legacy Issue Number: 7645
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figures 103 and 121 use <<create>> dependencies, which do not apply to
    the example. Standard stereotypes defines <<create>> for
    BehavioralFeature as:

    "Specifies that the designated feature creates an instance of
    the classifier to which the feature is attached. May be
    promoted to the Classifier containing the feature."

  • Reported: UML 1.4.2 — Fri, 20 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

UML 2 Super/Templates/Template substitution symbol problematic

  • Key: UML25-580
  • Legacy Issue Number: 7618
  • Status: closed  
  • Source: Simula Research Laboratory ( Bran Selic)
  • Summary:

    Templates use an arrow symbol inline with the text to show a binding of a template parameter

    Problem: typographic problem. the arrow symbol is not present in many common fonts (times, arial, Helvetica, …). Therefore, one must use another font for this character (e.g., ZapfDingbats). That will create some fuss at several levels, related to fonts, usability, and tools. It also creates more dependency on printing with commercial printers; if you’re a book author, you know that adding more fonts to a book is another source of error. Yes, solvable, but nice to simplify.

    Solution: use a simple symbol part of the basic character fonts (e.g., in Arial, …). I suggest ‘= ™

    Example: ArrayList<T = Person>

  • Reported: UML 1.4.2 — Tue, 3 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

UML 2 Super/Activities/Class-Activity association missing

  • Key: UML25-579
  • Legacy Issue Number: 7607
  • Status: closed  
  • Source: Thematix Partners LLC ( James Odell)
  • Summary:

    An activity diagram is a graphical form of method, however there is no way to assign them to a class that would contain such a method. This may be more general than activity diagrams. For example, the same could apply to sequence diagrams. Since organizing structure and behavior by class is a fundamental OO concept, we need to have a way to associate UML-expressed methods to the “organizing” class.

  • Reported: UML 1.4.2 — Fri, 30 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

UML2 super&infra/Profiles/ownership of Image

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

    In the current UML2metamodel, the ownership of the new Image metaclass is
    not specified.

  • Reported: UML 1.4.2 — Fri, 23 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

Port should specialize featuringClassifier

  • Key: UML25-577
  • Legacy Issue Number: 7567
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Apparently a structural feature can be on more than one classifier,
    because the multiplicity of /featuringClassifier is 1..*. Not all the
    subtypes of StructuralFeature narrow this to one, or change it to strong
    ownership (eg, Port).

    Is it intentional that structural feature have more than one
    featuringClassifier, and not be owned by that classifier? If not, Bran,
    please assign this to classes. Otherwise, it is problem for Ports as
    well.

  • Reported: UML 1.4.2 — Wed, 7 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

There is no "precise mapping

  • Key: UML25-576
  • Legacy Issue Number: 7559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The RFP requires that "Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. ... In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing OMG specifications." [5.1.6] "Since UML has a large installed user base all proposed changes should consider backward incompatibility issues." [6.2] "... gratuitous changes to the current UML specification are strongly discouraged." [6.3] "Wherever changes have adversely impacted backward compatibility with previous specifications, submissions shall provide rationales and change summaries along with their precise mappings." "Proposals shall minimize the impact on users of the current UML 1.x, XMI 1.x and MOF 1.x specifications, and shall provide a precise mapping between the current UML 1.x and the UML 2.0 metamodels." "Proposals shall identify language elements to be retired from the language ..." [6.5.1] UML 2 removes three essential elements of an existing OMG specification, the UML 1.5 action language: GroupAction, ConditionalAction and LoopAction. No reason is given. The UML 2 specification notes that "conditional nodes replace ConditionalAction from the UML 1.5 action model" but gives no rationale for this change. There is no mention of the removal of GroupAction and LoopAction. There is no "precise mapping between the current UML 1.x and the UML 2.0 metamodels" for GroupAction, ConditionalAction and LoopAction.

  • Reported: UML 2.0 — Wed, 23 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

Semantics section of StructuralFeature

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

    The Semantics section of StructuralFeature says "A structural feature specifies that instances of the featuring classifier have a slot..."
    That's wrong. It is instance specifications of the classifier that have slots, not instances.

  • Reported: UML 2.0 — Fri, 2 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

State Machine Package--Compliance

  • Key: UML25-574
  • Legacy Issue Number: 7555
  • Status: closed  
  • Source: Industrial Internet Consortium ( 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

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

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

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

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

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

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

UML 2 Super/Interfaces

  • Key: UML25-568
  • Legacy Issue Number: 7441
  • Status: closed  
  • Source: The MathWorks ( 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

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

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

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

Dependencies with more than two ends in UML DI

  • Key: UML25-542
  • Legacy Issue Number: 18818
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how dependency lines with more than two ends are modeled

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

    Clarify that a UMLShape is used as the central point of the arrows.

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

Classifier and state annotations in UML DI

  • Key: UML25-541
  • Legacy Issue Number: 18817
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how the

    {abstract}

    annotations in UMLClassifierShapes and the

    {extended}

    and

    {final}

    annotations in UMLStateShapes are modeled.

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

    Clarify that these are direct instances of UMLLabel containing the text as specified by UML

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

Dashed interaction lifelines in UML DI

  • Key: UML25-540
  • Legacy Issue Number: 18816
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Interaction lifelines can be dashed, but the model in Annex B cannot express this.

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

    Add property to UMLInteractionDiagram to specify whether lifelines are dashed

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

Avoid covariant parameters in metamodel operation redefinition

  • Key: UML25-539
  • Legacy Issue Number: 18810
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition. MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it. This can be done using a precondition that requires the parameter to be of the right type.

    Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

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

    The operations that do not have covariant parameters are isCompatibleWith(p), isDistinguishableFrom(n,
    ns), and isConsistentWith(redefinee).
    The implementations of isCompatibleWith explicitly check the type of the parameter as part of the test:
    p.oclisKindOf(self.oclType()).
    The implementations of isDistinguishableFrom explicitly check the type of the parameter.
    The implementations of isConsistentWith call isRedefinitionContextValid() as a precondition. The truth of
    this precondition is a consequence of well-formedness rules.
    Rather than using a precondition as suggested in the issue, it is safer to make the operations explicitly check
    the parameter type in their logic.

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

Clarification of use of BNF for textual notations

  • Key: UML25-538
  • Legacy Issue Number: 18802
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

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

    Make such a clarification in 6.4.1

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

ActivityParameterNode notation

  • Key: UML25-537
  • Legacy Issue Number: 18801
  • Status: closed  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.

    UML spec says:
    An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label.

    However, I can't find Parameter BNF.

    Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

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

    In 9.4.4 it says “There is no general notation for Parameter. Specific subclasses of BehavioralFeature define
    notation for their Parameters.”
    There are two subclasses of BehavioralFeature, Operation and Reception. Operation defines a notation for
    Parameter within its BNF. Reception says “Receptions are shown in the receptions compartment using the
    same notation as for Operations with the keyword «signal».”
    So there is only one notation for Parameter, and it should be defined there, so that ActivityParameterNode
    can refer to it.
    The notation for ParameterSet is incorrectly specified in the same way.
    This also resolves 17906.

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

The resolution to Issue 18528 contains incorrect OCL and operation names

  • Key: UML25-536
  • Legacy Issue Number: 18793
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment. Also the name getGateName() should be getName() throughout the revised text.

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

    Change the type of Gate::getOperand(), and fix the names

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

Activity::structuredNode is incorrectly marked as readOnly = true

  • Key: UML25-554
  • Legacy Issue Number: 18948
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Activity::structuredNode is incorrectly marked as readOnly = true

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

    This appears to be a throwback to 2.4, in which it was also marked as derived - it got marked as not derived
    by the resolution to urgent issue 16232. In 2.4 it was readonly and derived; in 2.4.1 it was neither (which
    means that readonly was removed when the issue was applied, even though the issue did not call for that);
    in 2.5 it has for some reason become readonly again. The only explanation I might offer for this is that
    somebody noticed while applying 16232 that readonly needed to be removed and did it, but this change did
    not get checked in.
    The resolution is to set readOnly to false. The only impact on the specification document is figure 16.45,
    which needs to be changed. The generated classifier descriptions do not contain the

    {readOnly}

    annotation

    • this is a separate issue which will need to be addressed in the future but is too disruptive to address at
      the time of writing. The consequence is that no change is needed to the generated classifier description for
      Activity::structuredNode.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

misleading omission

  • Key: UML25-553
  • Legacy Issue Number: 18947
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The text in 6.1 and Annex E describing the serialization compatibility between 2.4.1 and 2.5 omits to mention that the clientDependency attribute needs to be present in 2.4.1 and absent in 2.5 for all NamedElements that are the clients of a Dependency. This omission is misleading

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

    Include wording in 6.1 and Annex E to explain this change. Also point out that ordering may have been
    either added or removed from some properties for semantic consistency

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

Validation errors in UML metamodel

  • Key: UML25-552
  • Legacy Issue Number: 18873
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    A body condition is specified for operation '<<oMGIssueTag>> <Operation> clientDependency () : Dependency [0..*]', but it is not a query.

    A body condition is specified for operation '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean', but it is not a query.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / classifier : Classifier [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / memberNamespace : Namespace [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / relationship : Relationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]' is not read only.

    IRJA0273E "<Package> Activities" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> CommonBehavior" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> Deployments" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> InformationFlows" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers, <Package> UseCases."

    IRJA0273E "<Package> Interactions" has one or more package import cycles involving "<Package> Classification, <Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure."

    IRJA0273E "<Package> SimpleClassifiers" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> StateMachines" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> UML" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> UseCases" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> Values" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    Redefining element '<<oMGIssueTag>> <Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean' is not consistent with redefined element '<Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean'. UML::Interactions::Gate::isDistinguishableFrom Model Validation Problem

    Redefining element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean' is not consistent with redefined element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean'. UML::Activities::ActivityNode::isConsistentWith Model Validation Problem

    Redefining element '<Property> region : Region [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_region::region Model Validation Problem

    Redefining element '<Property> state : State [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_state::state Model Validation Problem

    Redefining element '<Property> structuredClassifier : StructuredClassifier [0..1]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]'. UML::StructuredClassifiers::A_ownedAttribute_structuredClassifier::structuredClassifier Model Validation Problem

    Redefining element '<Property> transition : Transition [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_transition::transition Model Validation Problem

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

    The operations with bodies definitely need to be marked as queries.
    The derived unions definitely need to be marked as readonly. Cyclic package imports are not invalid.
    Three of the redefinitions are in fact invalid:
    region : Region [0..*]’ is not consistent with redefinableElement : RedefinableElement [0..*]
    state : State [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement [0..*]
    transition : Transition [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement
    [0..*]’.
    They appear in figure 14.35. The navigable ends of these associations are derived to mean “the nearest
    containing”. The non-navigable ends should be subsets (e.g. “the subset of elements redefined in this
    context that happen to be states”), not redefinitions.
    The remainder are not errors.

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

UML 2.5 issue: subsettingContext() has incorrect logic

  • Key: UML25-551
  • Legacy Issue Number: 18859
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The current logic says

    if association <> null then association.endType->excluding(type)

    But if the association has many ends of the same type, this is the wrong logic. Note this is independent of the fact that endType is a set – if it were a bag or sequence all occurrences of the type would be removed.

    It needs to work directly with the memberEnds – remove the current property from the memberEnds and collect the remaining types.